whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Remove trailing spaces from ID documents(#16742) (#16789)

Browse Source
This commit is contained in:
Yushiro FURUKAWA
2019-10-10 13:48:52 +09:00
committed by Kubernetes Prow Robot
parent 99619d3414
commit 520caa1264
51 changed files with 1250 additions and 1250 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/id/docs/concepts/configuration/assign-pod-node.md
+7 -7
View File
@@ -35,7 +35,7 @@ Kamu dapat memastikan perintah telah berhasil dengan menjalankan ulang perintah
### Langkah Dua: Menambahkan sebuah nodeSelector ke konfigurasi pod kamu
Ambil berkas konfigurasi pod manapun yang akan kamu jalankan, dan tambahkan sebuah bagian `nodeSelector` pada berkas tersebut, seperti berikut. Sebagai contoh, jika berikut ini adalah konfigurasi pod saya:
Ambil berkas konfigurasi pod manapun yang akan kamu jalankan, dan tambahkan sebuah bagian `nodeSelector` pada berkas tersebut, seperti berikut. Sebagai contoh, jika berikut ini adalah konfigurasi pod saya:
```yaml
apiVersion: v1
@@ -116,7 +116,7 @@ Aturan afinitas node tersebut menyatakan pod hanya bisa ditugaskan pada node den
Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu.
Jika kamu menyatakan `nodeSelector` dan `nodeAffinity`. *keduanya* harus dipenuhi agar pod dapat dijadwalkan pada node kandidat.
Jika kamu menyatakan `nodeSelector` dan `nodeAffinity`. *keduanya* harus dipenuhi agar pod dapat dijadwalkan pada node kandidat.
Jika kamu menyatakan beberapa `nodeSelectorTerms` yang terkait dengan tipe `nodeAffinity`, maka pod akan dijadwalkan pada node **jika salah satu** dari `nodeSelectorTerms` dapat terpenuhi.
@@ -132,7 +132,7 @@ Untuk informasi lebih lanjut tentang afinitas node kamu dapat melihat [design do
### Afinitas and anti-afinitas antar pod (fitur beta)
Afinitas and anti-afinitas antar pod diperkenalkan pada Kubernetes 1.4. Afinitas and anti-afinitas antar pod memungkinkan kamu untuk membatasi node yang memenuhi syarat untuk penjadwalan pod *berdasarkan label-label pada pod yang sudah berjalan pada node* daripada berdasarkan label-label pada node. Aturan tersebut berbentuk "pod ini harus (atau, dalam kasus
anti-afinitas, tidak boleh) berjalan dalam X jika X itu sudah menjalankan satu atau lebih pod yang memenuhi aturan Y". Y dinyatakan sebagai sebuah LabelSelector dengan daftar namespace terkait; tidak seperti node, karena pod are namespaced (maka dari itu label-label pada pod diberi namespace secara implisit), sebuah label selector di atas label-label pod harus menentukan namespace yang akan diterapkan selector. Secara konsep X adalah domain topologi seperti node, rack, zona penyedia cloud, daerah penyedia cloud, dll. Kamu dapat menyatakannya menggunakan `topologyKey` yang merupakan kunci untuk label node yang digunakan sistem untuk menunjukkan domain topologi tersebut, contohnya lihat kunci label yang terdaftar di atas pada bagian [Selingan: label node built-in](#interlude-built-in-node-labels).
anti-afinitas, tidak boleh) berjalan dalam X jika X itu sudah menjalankan satu atau lebih pod yang memenuhi aturan Y". Y dinyatakan sebagai sebuah LabelSelector dengan daftar namespace terkait; tidak seperti node, karena pod are namespaced (maka dari itu label-label pada pod diberi namespace secara implisit), sebuah label selector di atas label-label pod harus menentukan namespace yang akan diterapkan selector. Secara konsep X adalah domain topologi seperti node, rack, zona penyedia cloud, daerah penyedia cloud, dll. Kamu dapat menyatakannya menggunakan `topologyKey` yang merupakan kunci untuk label node yang digunakan sistem untuk menunjukkan domain topologi tersebut, contohnya lihat kunci label yang terdaftar di atas pada bagian [Selingan: label node built-in](#interlude-built-in-node-labels).
{{< note >}}
Afinitas and anti-afinitas antar pod membutuhkan jumlah pemrosesan yang substansial yang dapat memperlambat penjadwalan pada kluster berukuran besar secara signifikan. Kami tidak merekomendasikan penggunaan mereka pada kluster yang berukuran lebih besar dari beberapa ratus node.
@@ -159,14 +159,14 @@ maupun `preferredDuringSchedulingIgnoredDuringExecution`.
Operator yang sah untuk afinitas dan anti-afinitas pod adalah `In`, `NotIn`, `Exists`, `DoesNotExist`.
Pada dasarnya, `topologyKey` dapat berupa label-kunci apapun yang sah. Namun, untuk alasan performa dan keamanan, ada beberapa batasan untuk `topologyKey`:
Pada dasarnya, `topologyKey` dapat berupa label-kunci apapun yang sah. Namun, untuk alasan performa dan keamanan, ada beberapa batasan untuk `topologyKey`:
1. Untuk afinitas and anti-afinitas pod `requiredDuringSchedulingIgnoredDuringExecution`, `topologyKey` tidak boleh kosong.
2. Untuk anti-afinitas pod `requiredDuringSchedulingIgnoredDuringExecution`, pengontrol penerimaan `LimitPodHardAntiAffinityTopology` diperkenalkan untuk membatasi `topologyKey` pada `kubernetes.io/hostname`. Jika kamu menginginkan untuk membuatnya tersedia untuk topologi khusus, kamu dapat memodifikasi pengontrol penerimaan, atau cukup menonaktifkannya saja.
3. Untuk anti-afinitas pod `preferredDuringSchedulingIgnoredDuringExecution`, `topologyKey` yang kosong diinterpretasikan sebagai "semua topologi" ("semua topologi" sekarang dibatasi pada kombinasi dari `kubernetes.io/hostname`, `failure-domain.beta.kubernetes.io/zone` dan `failure-domain.beta.kubernetes.io/region`).
4. Kecuali untuk kasus-kasus di atas, `topologyKey` dapat berupa label-kunci apapun yang sah.
Sebagai tambahan untuk `labelSelector` and `topologyKey`, kamu secara opsional dapat menyatakan daftar `namespaces` dari namespaces yang akan digunakan untuk mencocokan `labelSelector` (daftar ini berjalan pada level definisi yang sama dengan `labelSelector` dan `topologyKey`)
Sebagai tambahan untuk `labelSelector` and `topologyKey`, kamu secara opsional dapat menyatakan daftar `namespaces` dari namespaces yang akan digunakan untuk mencocokan `labelSelector` (daftar ini berjalan pada level definisi yang sama dengan `labelSelector` dan `topologyKey`)
Jika dihilangkan atau kosong, daftar ini sesuai standar akan merujuk pada _namespace_ dari pod tempat definisi afinitas/anti-afinitas dinyatakan.
@@ -175,7 +175,7 @@ Semua `matchExpressions` berkaitan dengan afinitas and anti-afinitas `requiredDu
#### Penggunaan yang lebih praktikal
Afinitas and anti-afinitas antar pod dapat menjadi lebih berguna saat digunakan bersamaan dengan koleksi dengan level yang lebih tinggi seperti ReplicaSets, StatefulSets, Deployments, dll. Pengguna dapat dengan mudah mengkonfigurasi bahwa satu set workload harus
ditempatkan bersama dalam topologi yang didefinisikan sama, misalnya, node yang sama.
ditempatkan bersama dalam topologi yang didefinisikan sama, misalnya, node yang sama.
##### Selalu ditempatkan bersamaan pada node yang sama
@@ -280,7 +280,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3
Contoh di atas menggunakan aturan `PodAntiAffinity` dengan` topologyKey: "kubernetes.io/hostname"` untuk melakukan deploy kluster redis sehingga tidak ada dua instance terletak pada hos yang sama.
Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) untuk contoh dari konfigurasi StatefulSet dengan anti-afinitas untuk ketersediaan tinggi, menggunakan teknik yang sama.
Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) untuk contoh dari konfigurasi StatefulSet dengan anti-afinitas untuk ketersediaan tinggi, menggunakan teknik yang sama.
Untuk informasi lebih lanjut tentang afinitas/anti-afinitas antar pod, lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
content/id/docs/concepts/configuration/taint-and-toleration.md
+113 -113
View File
@@ -7,14 +7,14 @@ weight: 40
{{% capture overview %}}
Afinitas Node, seperti yang dideskripsikan [di sini](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
adalah salah satu properti dari Pod yang menyebabkan pod tersebut memiliki preferensi
untuk ditempatkan di sekelompok Node tertentu (preferensi ini dapat berupa _soft constraints_ atau
_hard constraints_ yang harus dipenuhi). _Taint_ merupakan kebalikan dari afinitas --
adalah salah satu properti dari Pod yang menyebabkan pod tersebut memiliki preferensi
untuk ditempatkan di sekelompok Node tertentu (preferensi ini dapat berupa _soft constraints_ atau
_hard constraints_ yang harus dipenuhi). _Taint_ merupakan kebalikan dari afinitas --
properti ini akan menyebabkan Pod memiliki preferensi untuk tidak ditempatkan pada sekelompok Node tertentu.
_Taint_ dan _toleration_ bekerja sama untuk memastikan Pod dijadwalkan pada Node
yang sesuai. Satu atau lebih _taint_ akan diterapkan pada suatu node; hal ini akan menyebabkan
node tidak akan menerima pod yang tidak mengikuti _taint_ yang sudah diterapkan.
_Taint_ dan _toleration_ bekerja sama untuk memastikan Pod dijadwalkan pada Node
yang sesuai. Satu atau lebih _taint_ akan diterapkan pada suatu node; hal ini akan menyebabkan
node tidak akan menerima pod yang tidak mengikuti _taint_ yang sudah diterapkan.
{{% /capture %}}
@@ -29,19 +29,19 @@ Misalnya,
kubectl taint nodes node1 key=value:NoSchedule
```
akan menerapkan _taint_ pada _node_ `node1`. _Taint_ tersebut memiliki _key_ `key`, _value_ `value`,
dan _effect_ _taint_ `NoSchedule`. Hal ini artinya pod yang ada tidak akan dapat dijadwalkan pada `node1`
akan menerapkan _taint_ pada _node_ `node1`. _Taint_ tersebut memiliki _key_ `key`, _value_ `value`,
dan _effect_ _taint_ `NoSchedule`. Hal ini artinya pod yang ada tidak akan dapat dijadwalkan pada `node1`
kecuali memiliki _taint_ yang sesuai.
Untuk menghilangkan _taint_ yang ditambahkan dengan perintah di atas, kamu dapat menggunakan
Untuk menghilangkan _taint_ yang ditambahkan dengan perintah di atas, kamu dapat menggunakan
perintah di bawah ini:
```shell
kubectl taint nodes node1 key:NoSchedule-
```
Kamu dapat memberikan spesifikasi _toleration_ untuk _pod_ pada bagian PodSpec.
Kedua _toleration_ yang diterapkan di bawa ini "sesuai" dengan _taint_ yang
_taint_ yang dibuat dengan perintah `kubectl taint` di atas, sehingga sebuah _pod_
Kamu dapat memberikan spesifikasi _toleration_ untuk _pod_ pada bagian PodSpec.
Kedua _toleration_ yang diterapkan di bawa ini "sesuai" dengan _taint_ yang
_taint_ yang dibuat dengan perintah `kubectl taint` di atas, sehingga sebuah _pod_
dengan _toleration_ yang sudah didefinisikan akan mampu di-_schedule_ ke node `node`:
```yaml
@@ -59,7 +59,7 @@ tolerations:
effect: "NoSchedule"
```
Sebuah _toleration_ "sesuai" dengan sebuah _taint_ jika _key_ dan efek yang
Sebuah _toleration_ "sesuai" dengan sebuah _taint_ jika _key_ dan efek yang
ditimbulkan sama:
* `operator` dianggap `Exists` (pada kasus dimana tidak ada `value` yang diberikan), atau
@@ -87,29 +87,29 @@ tolerations:
```
{{< /note >}}
Contoh yang diberikan di atas menggunakan `effect` untuk `NoSchedule`.
Contoh yang diberikan di atas menggunakan `effect` untuk `NoSchedule`.
Alternatif lain yang dapat digunakan adalah `effect` untuk `PreferNoSchedule`.
`PreferNoSchedule` merupakan "preferensi" yang lebih fleksibel dari `NoSchedule` --
sistem akan mencoba untuk tidak menempatkan pod yang tidak menoleransi _taint_
pada _node_, tapi hal ini bukan merupakan sesuatu yang harus dipenuhi. Jenis ketiga
`PreferNoSchedule` merupakan "preferensi" yang lebih fleksibel dari `NoSchedule` --
sistem akan mencoba untuk tidak menempatkan pod yang tidak menoleransi _taint_
pada _node_, tapi hal ini bukan merupakan sesuatu yang harus dipenuhi. Jenis ketiga
dari `effect` adalah `NoExecute`, akan dijelaskan selanjutnya.
Kamu dapat menerapkan beberapa _taint_ sekaligus pada _node_ atau
beberapa _toleration_ sekaligus pada sebuah _pod_. Mekanisme Kubernetes dapat
memproses beberapa _taint_ dan _toleration_ sekaligus sama halnya seperti sebuah
_filter_: memulai dengan _taint_ yang ada pada _node_, kemudian mengabaikan
_taint_ yang sesuai pada pod yang memiliki _toleration_ yang sesuai; kemudian
_taint_ yang diterapkan pada pod yang sudah disaring tadi akan menghasilkan suatu
Kamu dapat menerapkan beberapa _taint_ sekaligus pada _node_ atau
beberapa _toleration_ sekaligus pada sebuah _pod_. Mekanisme Kubernetes dapat
memproses beberapa _taint_ dan _toleration_ sekaligus sama halnya seperti sebuah
_filter_: memulai dengan _taint_ yang ada pada _node_, kemudian mengabaikan
_taint_ yang sesuai pada pod yang memiliki _toleration_ yang sesuai; kemudian
_taint_ yang diterapkan pada pod yang sudah disaring tadi akan menghasilkan suatu
_effect_ pada pod. Secara khusus:
* jika terdapat _taint_ yang tidak tersaring dengan _effect_ `NoSchedule` maka Kubernetes tidak akan menempatkan
* jika terdapat _taint_ yang tidak tersaring dengan _effect_ `NoSchedule` maka Kubernetes tidak akan menempatkan
_pod_ pada _node_ tersebut
* jika tidak terdapat _taint_ yang tidak tersaring dengan _effect_ `NoSchedule`
tapi terdapat setidaknya satu _taint_ yang tidak tersaring dengan
_effect_ `PreferNoSchedule` maka Kubernetes akan mencoba untuk tidak akan menempatkan
* jika tidak terdapat _taint_ yang tidak tersaring dengan _effect_ `NoSchedule`
tapi terdapat setidaknya satu _taint_ yang tidak tersaring dengan
_effect_ `PreferNoSchedule` maka Kubernetes akan mencoba untuk tidak akan menempatkan
_pod_ pada _node_ tersebut
* jika terdapat _taint_ yang tidak tersaring dengan _effect_ `NoExecute` maka _pod_ akan
berada dalam kondisi _evicted_ dari _node_ (jika _pod_ tersebut sudah terlanjur ditempatkan pada _node_
* jika terdapat _taint_ yang tidak tersaring dengan _effect_ `NoExecute` maka _pod_ akan
berada dalam kondisi _evicted_ dari _node_ (jika _pod_ tersebut sudah terlanjur ditempatkan pada _node_
tersebut), dan tidak akan di-_schedule_ lagi pada _node_ tersebut.
Sebagai contoh, bayangkan kamu memberikan _taint_ pada _node_ sebagai berikut:
@@ -134,17 +134,17 @@ tolerations:
effect: "NoExecute"
```
Pada kasus ini, _pod_ tidak akan di-_schedule_ pada _node_, karena tidak ada
_toleration_ yang sesuai dengan _taint_ ketiga. Akan tetapi, _pod_ yang sebelumnya
sudah dijalankan di _node_ dimana _taint_ ditambahkan akan tetap jalan, karena _taint_
Pada kasus ini, _pod_ tidak akan di-_schedule_ pada _node_, karena tidak ada
_toleration_ yang sesuai dengan _taint_ ketiga. Akan tetapi, _pod_ yang sebelumnya
sudah dijalankan di _node_ dimana _taint_ ditambahkan akan tetap jalan, karena _taint_
ketiga merupakan _taint_ yang tidak ditoleransi oleh _pod_.
Pada umumnya, jika sebuah _taint_ memiliki _effect_ `NoExecute` ditambahkan pada _node_,
maka semua pod yang tidak menoleransi _taint_ tersebut akan berada dalam _state_
_evicted_ secara langsung, dan semua _pod_ yang menoleransi _taint_ tersebut
tidak akan berjalan seperti biasanya (tidak dalam _state_ _evicted_). Meskipun demikian,
_toleration_ dengan _effect_ `NoExecute` dapat dispesfikasikan sebagai _field_ opsional
`tolerationSeconds` yang memberikan perintah berapa lama suatu _pod_ akan berada
Pada umumnya, jika sebuah _taint_ memiliki _effect_ `NoExecute` ditambahkan pada _node_,
maka semua pod yang tidak menoleransi _taint_ tersebut akan berada dalam _state_
_evicted_ secara langsung, dan semua _pod_ yang menoleransi _taint_ tersebut
tidak akan berjalan seperti biasanya (tidak dalam _state_ _evicted_). Meskipun demikian,
_toleration_ dengan _effect_ `NoExecute` dapat dispesfikasikan sebagai _field_ opsional
`tolerationSeconds` yang memberikan perintah berapa lama suatu _pod_ akan berada
pada _node_ apabila sebuah _taint_ ditambahkan. Contohnya:
```yaml
@@ -156,61 +156,61 @@ tolerations:
tolerationSeconds: 3600
```
ini berarti apabila sebuah _pod_ sedang dalam berada dalam _state_ _running_,
kemudian sebuah _taint_ yang sesuai ditambahkan pada _node_, maka _pod_ tersebut
akan tetap berada di dalam _node_ untuk periode 3600 detik sebelum _state_-nya
berubah menjadi _evicted_. Jika _taint_ dihapus sebelum periode tersebut, maka _pod_
ini berarti apabila sebuah _pod_ sedang dalam berada dalam _state_ _running_,
kemudian sebuah _taint_ yang sesuai ditambahkan pada _node_, maka _pod_ tersebut
akan tetap berada di dalam _node_ untuk periode 3600 detik sebelum _state_-nya
berubah menjadi _evicted_. Jika _taint_ dihapus sebelum periode tersebut, maka _pod_
tetap berjalan sebagaimana mestinya.
## Contoh Penggunaan
_Taint_ dan _toleration_ adalah mekanisme fleksibel yang digunakan untuk
memaksa _pod_ agar tidak dijadwalkan pada _node-node_ tertentu atau
_Taint_ dan _toleration_ adalah mekanisme fleksibel yang digunakan untuk
memaksa _pod_ agar tidak dijadwalkan pada _node-node_ tertentu atau
mengubah _state_ _pod_ menjadi _evicted_. Berikut adalah beberapa contoh penggunaannya:
* **Node-Node yang Sifatnya _Dedicated_**: Jika kamu ingin menggunakan
sekumpulan _node_ dengan penggunaan eksklusif dari sekumpulan pengguna,
kamu dapat menambahkan _taint_ pada _node-node_ tersebut (misalnya,
`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) dan kemudian
menambahkan _toleration_ yang sesuai pada _pod-pod_ yang berada di dalamnya (hal ini
dapat dilakukan dengan mudah dengan cara menulis
[_admission controller_](/docs/reference/access-authn-authz/admission-controllers/) yang
bersifat khusus). _Pod-pod_ dengan _toleration_ nantinya akan diperbolehkannya untuk menggunakan
_node_ yang sudah di-_taint_ (atau dengan kata lain didedikasikan penggunaannya) maupun
_node_ lain yang ada di dalam kluster. Jika kamu ingin mendedikasikan _node_ khusus
yang hanya digunakan oleh _pod-pod_ tadi serta memastikan _pod-pod_ tadi hanya menggunakan
_node_ yang didedikasikan, maka kamu harus menambahkan sebuah _label_ yang serupa dengan
_taint_ yang diberikan pada sekelompok _node_ (misalnya, `dedicated=groupName`), dan
_admission controller_ sebaiknya menambahkan afininitas _node_ untuk memastikan _pod-pod_
* **Node-Node yang Sifatnya _Dedicated_**: Jika kamu ingin menggunakan
sekumpulan _node_ dengan penggunaan eksklusif dari sekumpulan pengguna,
kamu dapat menambahkan _taint_ pada _node-node_ tersebut (misalnya,
`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) dan kemudian
menambahkan _toleration_ yang sesuai pada _pod-pod_ yang berada di dalamnya (hal ini
dapat dilakukan dengan mudah dengan cara menulis
[_admission controller_](/docs/reference/access-authn-authz/admission-controllers/) yang
bersifat khusus). _Pod-pod_ dengan _toleration_ nantinya akan diperbolehkannya untuk menggunakan
_node_ yang sudah di-_taint_ (atau dengan kata lain didedikasikan penggunaannya) maupun
_node_ lain yang ada di dalam kluster. Jika kamu ingin mendedikasikan _node_ khusus
yang hanya digunakan oleh _pod-pod_ tadi serta memastikan _pod-pod_ tadi hanya menggunakan
_node_ yang didedikasikan, maka kamu harus menambahkan sebuah _label_ yang serupa dengan
_taint_ yang diberikan pada sekelompok _node_ (misalnya, `dedicated=groupName`), dan
_admission controller_ sebaiknya menambahkan afininitas _node_ untuk memastikan _pod-pod_
tadi hanya dijadwalkan pada _node_ dengan _label_ `dedicated=groupName`.
* **Node-Node dengan Perangkat Keras Khusus**: Pada suatu kluster dimana
sebagian kecuali _node_ memiliki perangkat keras khusus (misalnya GPU), kita ingin
memastikan hanya _pod-pod_ yang membutuhkan GPU saja yang dijadwalkan di _node_ dengan GPU.
Hal ini dapat dilakukan dengan memberikan _taint_ pada _node_ yang memiliki perangkat keras
* **Node-Node dengan Perangkat Keras Khusus**: Pada suatu kluster dimana
sebagian kecuali _node_ memiliki perangkat keras khusus (misalnya GPU), kita ingin
memastikan hanya _pod-pod_ yang membutuhkan GPU saja yang dijadwalkan di _node_ dengan GPU.
Hal ini dapat dilakukan dengan memberikan _taint_ pada _node_ yang memiliki perangkat keras
khusus (misalnya, `kubectl taint nodes nodename special=true:NoSchedule` atau
`kubectl taint nodes nodename special=true:PreferNoSchedule`) serta menambahkan _toleration_
yang sesuai pada _pod_ yang menggunakan _node_ dengan perangkat keras khusus. Seperti halnya pada
kebutuhan _dedicated_ _node_, hal ini dapat dilakukan dengan mudah dengan cara menulis
[_admission controller_](/docs/reference/access-authn-authz/admission-controllers/) yang
bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
untuk merepresentasikan perangkat keras khusus, kemudian _taint_ _node_ dengan perangkat keras khusus
dengan nama _extended resource_ dan jalankan _admission controller_
[ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration).
Setelah itu, karena _node_ yang ada sudah di-_taint_, maka tidak akan ada _pod_ yang
tidak memiliki _toleration_ yang akan dijadwalkan pada _node_ tersebut_.
`kubectl taint nodes nodename special=true:PreferNoSchedule`) serta menambahkan _toleration_
yang sesuai pada _pod_ yang menggunakan _node_ dengan perangkat keras khusus. Seperti halnya pada
kebutuhan _dedicated_ _node_, hal ini dapat dilakukan dengan mudah dengan cara menulis
[_admission controller_](/docs/reference/access-authn-authz/admission-controllers/) yang
bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
untuk merepresentasikan perangkat keras khusus, kemudian _taint_ _node_ dengan perangkat keras khusus
dengan nama _extended resource_ dan jalankan _admission controller_
[ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration).
Setelah itu, karena _node_ yang ada sudah di-_taint_, maka tidak akan ada _pod_ yang
tidak memiliki _toleration_ yang akan dijadwalkan pada _node_ tersebut_.
Meskipun begitu, ketika kamu membuat suatu _pod_ yang membutuhkan _extended resource_,
maka _admission controller_ dari `ExtendedResourceToleration` akan mengoreksi
_toleration_ sehingga _pod_ tersebut dapat dijadwalkan pada _node_ dengan perangkat keras khusus.
maka _admission controller_ dari `ExtendedResourceToleration` akan mengoreksi
_toleration_ sehingga _pod_ tersebut dapat dijadwalkan pada _node_ dengan perangkat keras khusus.
Dengan demikian, kamu tidak perlu menambahkan _toleration_ secara manual pada pod yang ada.
* **_Eviction_ berbasis _Taint_ (fitur beta)**: Konfigurasi _eviction_ per _pod_
yang terjadi ketika _pod_ mengalami gangguan, hal ini akan dibahas lebih lanjut di bagian
* **_Eviction_ berbasis _Taint_ (fitur beta)**: Konfigurasi _eviction_ per _pod_
yang terjadi ketika _pod_ mengalami gangguan, hal ini akan dibahas lebih lanjut di bagian
selanjutnya.
## _Eviction_ berbasis _Taint_
## _Eviction_ berbasis _Taint_
Sebelumnya, kita sudah pernah membahas soal _effect_ _taint_ `NoExecute`,
Sebelumnya, kita sudah pernah membahas soal _effect_ _taint_ `NoExecute`,
yang memengaruhi _pod_ yang sudah dijalankan dengan cara sebagai berikut:
* _pod_ yang tidak menoleransi _taint_ akan segera diubah _state_-nya menjadi _evicted_
@@ -219,44 +219,44 @@ yang memengaruhi _pod_ yang sudah dijalankan dengan cara sebagai berikut:
* _pod_ yang menoleransi _taint_ yang menspesifikasikan `tolerationSeconds`
spesifikasi _toleration_ yang ada akan tetap berada di dalam _node_ hingga batas waktu tertentu
Sebagai tambahan, Kubernetes 1.6 memperkenalkan dukungan alfa untuk merepresentasikan
_node_ yang bermasalah. Dengan kata lain, _node controller_ akan secara otomatis memberikan _taint_
pada sebuah _node_ apabila _node_ tersebut memenuhi kriteria tertentu. Berikut merupakan _taint_
yang secara _default_ disediakan:
Sebagai tambahan, Kubernetes 1.6 memperkenalkan dukungan alfa untuk merepresentasikan
_node_ yang bermasalah. Dengan kata lain, _node controller_ akan secara otomatis memberikan _taint_
pada sebuah _node_ apabila _node_ tersebut memenuhi kriteria tertentu. Berikut merupakan _taint_
yang secara _default_ disediakan:
* `node.kubernetes.io/not-ready`: _Node_ berada dalam _state_ _not ready_. Hal ini terjadi apabila
* `node.kubernetes.io/not-ready`: _Node_ berada dalam _state_ _not ready_. Hal ini terjadi apabila
_value_ dari _NodeCondition_ `Ready` adalah "`False`".
* `node.kubernetes.io/unreachable`: _Node_ berada dalam _state_ _unreachable_ dari _node controller_
* `node.kubernetes.io/unreachable`: _Node_ berada dalam _state_ _unreachable_ dari _node controller_
Hal ini terjadi apabila _value_ dari _NodeCondition_ `Ready` adalah "`Unknown`".
* `node.kubernetes.io/out-of-disk`: _Node_ kehabisan kapasitas _disk_.
* `node.kubernetes.io/memory-pressure`: _Node_ berada diambang kapasitas memori.
* `node.kubernetes.io/disk-pressure`: _Node_ berada diambang kapasitas _disk_.
* `node.kubernetes.io/network-unavailable`: Jaringan pada _Node_ bersifat _unavailable_.
* `node.kubernetes.io/unschedulable`: _Node_ tidak dapat dijadwalkan.
* `node.cloudprovider.kubernetes.io/uninitialized`: Ketika _kubelet_ dijalankan dengan
penyedia layanan _cloud_ "eksternal", _taint_ ini akan diterapkan pada _node_ untuk menandai
_node_ tersebut tidak digunakan. Setelah kontroler dari _cloud-controller-manager_ melakukan
* `node.cloudprovider.kubernetes.io/uninitialized`: Ketika _kubelet_ dijalankan dengan
penyedia layanan _cloud_ "eksternal", _taint_ ini akan diterapkan pada _node_ untuk menandai
_node_ tersebut tidak digunakan. Setelah kontroler dari _cloud-controller-manager_ melakukan
inisiasi _node_ tersebut, maka _kubelet_ akan menghapus _taint_ yang ada.
Pada versi 1.13, fitur `TaintBasedEvictions` diubah menjadi beta dan diaktifkan secara _default_,
dengan demikian _taint-taint_ tersebut secara otomatis ditambahkan oleh _NodeController_ (atau _kubelet_)
dan logika normal untuk melakukan _eviction_ pada _pod_ dari suatu _node_ tertentu berdasarkan _value_
Pada versi 1.13, fitur `TaintBasedEvictions` diubah menjadi beta dan diaktifkan secara _default_,
dengan demikian _taint-taint_ tersebut secara otomatis ditambahkan oleh _NodeController_ (atau _kubelet_)
dan logika normal untuk melakukan _eviction_ pada _pod_ dari suatu _node_ tertentu berdasarkan _value_
dari _Ready_ yang ada pada _NodeCondition_ dinonaktifkan.
{{< note >}}
Untuk menjaga perilaku [_rate limiting_](/docs/concepts/architecture/nodes/) yang
ada pada _eviction_ _pod_ apabila _node_ mengalami masalah, sistem sebenarnya menambahkan
_taint_ dalam bentuk _rate limiter_. Hal ini mencegah _eviction_ besar-besaran pada _pod_
Untuk menjaga perilaku [_rate limiting_](/docs/concepts/architecture/nodes/) yang
ada pada _eviction_ _pod_ apabila _node_ mengalami masalah, sistem sebenarnya menambahkan
_taint_ dalam bentuk _rate limiter_. Hal ini mencegah _eviction_ besar-besaran pada _pod_
pada skenario dimana master menjadi terpisah dari _node_ lainnya.
{{< /note >}}
Fitur beta ini, bersamaan dengan `tolerationSeconds`, mengizinkan sebuah _pod_
untuk menspesifikasikan berapa lama _pod_ harus tetap sesuai dengan sebuah _node_
Fitur beta ini, bersamaan dengan `tolerationSeconds`, mengizinkan sebuah _pod_
untuk menspesifikasikan berapa lama _pod_ harus tetap sesuai dengan sebuah _node_
apabila _node_ tersebut bermasalah.
Misalnya, sebuah aplikasi dengan banyak _state_ lokal akan lebih baik untuk tetap
berada di suatu _node_ pada saat terjadi partisi jaringan, dengan harapan partisi jaringan
tersebut dapat diselesaikan dan mekanisme _eviction_ _pod_ tidak akan dilakukan.
Misalnya, sebuah aplikasi dengan banyak _state_ lokal akan lebih baik untuk tetap
berada di suatu _node_ pada saat terjadi partisi jaringan, dengan harapan partisi jaringan
tersebut dapat diselesaikan dan mekanisme _eviction_ _pod_ tidak akan dilakukan.
_Toleration_ yang ditambahkan akan berbentuk sebagai berikut:
```yaml
@@ -267,41 +267,41 @@ tolerations:
tolerationSeconds: 6000
```
Perhatikan bahwa Kubernetes secara otomatis menambahkan _toleration_ untuk
Perhatikan bahwa Kubernetes secara otomatis menambahkan _toleration_ untuk
`node.kubernetes.io/not-ready` dengan `tolerationSeconds=300`
kecuali konfigurasi lain disediakan oleh pengguna.
Kubernetes juga secara otomatis menambahkan _toleration_ untuk
Kubernetes juga secara otomatis menambahkan _toleration_ untuk
`node.kubernetes.io/unreachable` dengan `tolerationSeconds=300`
kecuali konfigurasi lain disediakan oleh pengguna.
_Toleration_ yang ditambahkan secara otomatis ini menjamin bahwa
perilaku _default_ dari suatu _pod_ adalah tetap bertahan selama 5 menit pada
_Toleration_ yang ditambahkan secara otomatis ini menjamin bahwa
perilaku _default_ dari suatu _pod_ adalah tetap bertahan selama 5 menit pada
_node_ apabila salah satu masalah terdeteksi.
Kedua _toleration_ _default_ tadi ditambahkan oleh [DefaultTolerationSeconds
_admission controller_](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds).
_Pod-pod_ pada [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_
_Pod-pod_ pada [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_
`NoExecute` untuk _taint_ tanpa `tolerationSeconds`:
* `node.kubernetes.io/unreachable`
* `node.kubernetes.io/not-ready`
Hal ini menjamin _pod-pod_ yang merupakan bagian dari DaemonSet tidak pernah berada di dalam
Hal ini menjamin _pod-pod_ yang merupakan bagian dari DaemonSet tidak pernah berada di dalam
_state_ _evicted_ apabila terjadi permasalahan pada _node_.
## _Taint_ pada _Node_ berdasarkan Kondisi Tertentu
Pada versi 1.12, fitur `TaintNodesByCondition` menjadi fitur beta, dengan demikian _lifecycle_
Pada versi 1.12, fitur `TaintNodesByCondition` menjadi fitur beta, dengan demikian _lifecycle_
dari kontroler _node_ akan secara otomatis menambahkan _taint_ sesuai dengan kondisi _node_.
Hal yang sama juga terjadi pada _scheduler_, _scheduler_ tidak bertugas memeriksa kondisi _node_
tetapi kondisi _taint_. Hal ini memastikan bahwa kondisi _node_ tidak memengaruhi apa
yang dijadwalkan di _node_. Pengguna dapat memilih untuk mengabaikan beberapa permasalahan yang
ada pada _node_ (yang direpresentasikan oleh kondisi _Node_) dengan menambahkan _toleration_ _Pod_ `NoSchedule`.
Sedangkan _taint_ dengan _effect_ `NoExecute` dikendalikan oleh `TaintBasedEviction` yang merupakan
Hal yang sama juga terjadi pada _scheduler_, _scheduler_ tidak bertugas memeriksa kondisi _node_
tetapi kondisi _taint_. Hal ini memastikan bahwa kondisi _node_ tidak memengaruhi apa
yang dijadwalkan di _node_. Pengguna dapat memilih untuk mengabaikan beberapa permasalahan yang
ada pada _node_ (yang direpresentasikan oleh kondisi _Node_) dengan menambahkan _toleration_ _Pod_ `NoSchedule`.
Sedangkan _taint_ dengan _effect_ `NoExecute` dikendalikan oleh `TaintBasedEviction` yang merupakan
fitur beta yang diaktifkan secara _default_ oleh Kubernetes sejak versi 1.13.
Sejak Kubernetes versi 1.8, kontroler DaemonSet akan secara otomatis
menambahkan _toleration_ `NoSchedule` pada semua _daemon_ untuk menjaga
Sejak Kubernetes versi 1.8, kontroler DaemonSet akan secara otomatis
menambahkan _toleration_ `NoSchedule` pada semua _daemon_ untuk menjaga
fungsionalitas DaemonSet.
* `node.kubernetes.io/memory-pressure`
@@ -310,5 +310,5 @@ fungsionalitas DaemonSet.
* `node.kubernetes.io/unschedulable` (versi 1.10 atau yang lebih baru)
* `node.kubernetes.io/network-unavailable` (hanya untuk jaringan _host_)
Menambahkan _toleration_ ini menjamin _backward compatibility_.
Menambahkan _toleration_ ini menjamin _backward compatibility_.
Kamu juga dapat menambahkan _toleration_ lain pada DaemonSet.