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

Change kluster to klaster mentioned in https://github.com/jk8s/sig-docs-id/issues/20 (#18130)

Browse Source
This commit is contained in:
irvifa
2019-12-16 20:11:37 +07:00
committed by Kubernetes Prow Robot
parent a7f6a78d55
commit 39fe327423
65 changed files with 459 additions and 458 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/id/docs/concepts/architecture/nodes.md
+13 -13
View File
@@ -7,7 +7,7 @@ weight: 10
{{% capture overview %}}
Node merupakan sebuah mesin <i>worker</i> di dalam Kubernetes, yang sebelumnya dinamakan `minion`.
Sebuah node bisa berupa VM ataupun mesin fisik, tergantung dari kluster-nya.
Sebuah node bisa berupa VM ataupun mesin fisik, tergantung dari klaster-nya.
Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak [pod](/docs/concepts/workloads/pods/pod/) dan diatur oleh komponen-komponen yang dimiliki oleh master.
Servis-servis di dalam sebuah node terdiri dari [runtime kontainer](/docs/concepts/overview/components/#node-components), kubelet dan kube-proxy.
Untuk lebih detail, lihat dokumentasi desain arsitektur pada [Node Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node).
@@ -33,8 +33,8 @@ Masing-masing bagian dijelaskan secara rinci di bawah ini.
Penggunaan <i>field-field</i> ini bergantung pada penyedia layanan cloud ataupun konfigurasi bare metal yang kamu punya.
* HostName: Merupakan hostname yang dilaporkan oleh kernel node. Dapat diganti melalui parameter `--hostname-override` pada kubelet.
* ExternalIP: Biasanya merupakan alamat IP pada node yang punya <i>route</i> eksternal (bisa diakses dari luar kluster).
* InternalIP: Biasanya merupakan alamat IP pada node yang hanya punya <i>route</i> di dalam kluster.
* ExternalIP: Biasanya merupakan alamat IP pada node yang punya <i>route</i> eksternal (bisa diakses dari luar klaster).
* InternalIP: Biasanya merupakan alamat IP pada node yang hanya punya <i>route</i> di dalam klaster.
### Condition
@@ -68,8 +68,8 @@ Keputusan untuk menghilangkan pod tidak dapat diberitahukan pada kubelet, sampai
Sementara itu, pod-pod akan terus berjalan pada node yang sudah terputus, walaupun mendapati <i>schedule</i> untuk dihilangkan.
Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver.
Namun, pada versi 1.5 dan seterusnya, kontroler node tidak menghilangkan pod dengan paksa, sampai ada konfirmasi bahwa pod tersebut sudah berhenti jalan di dalam kluster.
Pada kasus dimana Kubernetes tidak bisa menarik kesimpulan bahwa ada node yang telah meninggalkan kluster, admin kluster mungkin perlu untuk menghilangkan node secara manual.
Namun, pada versi 1.5 dan seterusnya, kontroler node tidak menghilangkan pod dengan paksa, sampai ada konfirmasi bahwa pod tersebut sudah berhenti jalan di dalam klaster.
Pada kasus dimana Kubernetes tidak bisa menarik kesimpulan bahwa ada node yang telah meninggalkan klaster, admin klaster mungkin perlu untuk menghilangkan node secara manual.
Menghilangkan obyek node dari Kubernetes akan membuat semua pod yang berjalan pada node tersebut dihilangkan oleh apiserver, dan membebaskan nama-namanya agar bisa digunakan kembali.
Pada versi 1.12, fitur `TaintNodesByCondition` telah dipromosikan ke beta, sehingga kontroler <i>lifecycle</i> node secara otomatis membuat [taints](/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan <i>conditions</i>.
@@ -93,7 +93,7 @@ Informasi ini dikumpulkan oleh Kubelet di dalam node.
## Manajemen
Tidak seperti [pod](/docs/concepts/workloads/pods/pod/) dan [service](/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar kluster oleh penyedia layanan cloud, seperti Google Compute Engine, atau <i>pool</i> mesin fisik ataupun virtual (VM) yang kamu punya.
Tidak seperti [pod](/docs/concepts/workloads/pods/pod/) dan [service](/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau <i>pool</i> mesin fisik ataupun virtual (VM) yang kamu punya.
Jadi ketika Kubernetes membuat sebuah node, obyek yang merepresentasikan node tersebut akan dibuat.
Setelah pembuatan, Kubernetes memeriksa apakah node tersebut valid atau tidak.
Contohnya, jika kamu mencoba untuk membuat node dari konten berikut:
@@ -112,7 +112,7 @@ Contohnya, jika kamu mencoba untuk membuat node dari konten berikut:
```
Kubernetes membuat sebuah obyek node secara internal (representasinya), dan melakukan validasi terhadap node. Validasi dilakukan dengan memeriksa kondisi kesehatan node (<i>health checking</i>), berdasarkan <i>field</i> `metadata.name`. Jika node valid -- terjadi saat semua servis yang diperlukan sudah jalan -- maka node diperbolehkan untuk menjalankan sebuah pod.
Namun jika tidak valid, node tersebut akan dihiraukan untuk aktivitas apapun yang berhubungan dengan kluster, sampai telah menjadi valid.
Namun jika tidak valid, node tersebut akan dihiraukan untuk aktivitas apapun yang berhubungan dengan klaster, sampai telah menjadi valid.
{{< note >}}
Kubernetes tetap menyimpan obyek untuk node yang tidak valid, dan terus memeriksa apakah node telah menjadi valid atau belum.
@@ -145,21 +145,21 @@ Semua <i>node lease</i> diperbarui sesering mungkin, sedangkan `NodeStatus` dila
Karena <i>node lease</i> jauh lebih ringan daripada `NodeStatus`, fitur ini membuat <i>heartbeat</i> dari node jauh lebih murah secara signifikan dari sudut pandang skalabilitas dan performa.
Di Kubernetes 1.4, kami telah memperbarui <i>logic</i> dari kontroler node supaya lebih baik dalam menangani kasus saat banyak sekali node yang tidak bisa terhubung dengan master (contohnya, karena master punya masalah jaringan).
Mulai dari 1.4, kontroler node melihat <i>state</i> dari semua node di dalam kluster, saat memutuskan untuk melakukan <i>eviction</i> pada pod.
Mulai dari 1.4, kontroler node melihat <i>state</i> dari semua node di dalam klaster, saat memutuskan untuk melakukan <i>eviction</i> pada pod.
Pada kasus kebanyakan, kontroler node membatasi <i>rate eviction</i> menjadi `--node-eviction-rate` (<i>default</i>-nya 0.1) per detik.
Artinya, kontroler node tidak akan melakukan <i>eviction</i> pada pod lebih dari 1 node per 10 detik.
Perlakuan <i>eviction</i> pada node berubah ketika sebuah node menjadi tidak sehat (<i>unhealthy</i>) di dalam suatu zona <i>availability</i>.
Kontroler node memeriksa berapa persentase node di dalam zona tersebut yang tidak sehat (saat `NodeReady condition` menjadi `ConditionUnknown` atau `ConditionFalse`) pada saat yang bersamaan.
Jika persentase node yang tidak sehat bernilai `--unhealthy-zone-threshold` (<i>default</i>-nya 0.55), maka <i>rate eviction</i> berkurang: untuk ukuran kluster yang kecil (saat jumlahnya lebih kecil atau sama dengan jumlah node `--large-cluster-size-threshold` - <i>default</i>-nya 50), maka <i>eviction</i> akan berhenti dilakukan.
Jika persentase node yang tidak sehat bernilai `--unhealthy-zone-threshold` (<i>default</i>-nya 0.55), maka <i>rate eviction</i> berkurang: untuk ukuran klaster yang kecil (saat jumlahnya lebih kecil atau sama dengan jumlah node `--large-cluster-size-threshold` - <i>default</i>-nya 50), maka <i>eviction</i> akan berhenti dilakukan.
Jika masih besar jumlahnya, <i>rate eviction</i> dikurangi menjadi `--secondary-node-eviction-rate` (<i>default</i>-nya 0.01) per detik.
Alasan kenapa hal ini diimplementasi untuk setiap zona <i>availability</i> adalah karena satu zona bisa saja terputus dari master, saat yang lainnya masih terhubung.
Jika kluster tidak menjangkau banyak zona <i>availability</i> yang disediakan oleh penyedia cloud, maka hanya ada satu zona (untuk semua node di dalam kluster).
Jika klaster tidak menjangkau banyak zona <i>availability</i> yang disediakan oleh penyedia cloud, maka hanya ada satu zona (untuk semua node di dalam klaster).
Alasan utama untuk menyebarkan node pada banyak zona <i>availability</i> adalah supaya <i>workload</i> dapat dipindahkan ke zona sehat (<i>healthy</i>) saat suatu zona mati secara menyeluruh.
Kemudian, jika semua node di dalam suatu zona menjadi tidak sehat (<i>unhealthy</i>), maka kontroler node melakukan <i>eviction</i> pada <i>rate</i> normal `--node-eviction-rate`.
Kasus khusus, ketika seluruh zona tidak ada satupun sehat (tidak ada node yang sehat satupun di dalam kluster).
Kasus khusus, ketika seluruh zona tidak ada satupun sehat (tidak ada node yang sehat satupun di dalam klaster).
Pada kasus ini, kontroler node berasumsi ada masalah pada jaringan master, dan menghentikan semua <i>eviction</i> sampai jaringan terhubung kembali.
Mulai dari Kubernetes 1.6, kontroler node juga bertanggung jawab untuk melakukan <i>eviction</i> pada pod-pod yang berjalan di atas node dengan <i>taints</i> `NoExecute`, ketika pod-pod tersebut sudah tidak lagi <i>tolerate</i> terhadap <i>taints</i>.
@@ -181,14 +181,14 @@ Kubelet memulai registrasi diri (<i>self-registration</i>) dengan opsi-opsi beri
- `--register-node` - Registrasi secara otomatis pada API server.
- `--register-with-taints` - Registrasi node dengan daftar <i>taints</i> (dipisahkan oleh koma `<key>=<value>:<effect>`). No-op jika `register-node` bernilai <i>false</i>.
- `--node-ip` - Alamat IP dari node dimana kubelet berjalan.
- `--node-labels` - Label-label untuk ditambahkan saat melakukan registrasi untuk node di dalam kluster (lihat label yang dibatasi secara paksa oleh [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) untuk 1.13+).
- `--node-labels` - Label-label untuk ditambahkan saat melakukan registrasi untuk node di dalam klaster (lihat label yang dibatasi secara paksa oleh [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) untuk 1.13+).
- `--node-status-update-frequency` - Menentukan seberapa sering kubelet melaporkan status pada master.
Ketika mode [otorisasi Node](/docs/reference/access-authn-authz/node/) dan [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) diaktifkan, semua kubelet hanya punya otoritas untuk membuat/modifikasi <i>resource</i> Node masing-masing.
#### Administrasi Node secara Manual
Seorang admin kluster dapat membuat dan memodifikasi obyek node.
Seorang admin klaster dapat membuat dan memodifikasi obyek node.
Jika admin ingin untuk membuat obyek node secara manual, atur argument `--register-node=false` pada kubelet.