Change kluster to klaster mentioned in https://github.com/jk8s/sig-docs-id/issues/20 (#18130)
This commit is contained in:
irvifa
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
a7f6a78d55
commit
39fe327423
@@ -5,13 +5,13 @@ weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
Konsep _Cloud Controller Manager_/CCM (jangan tertukar dengan program biner kube-controller-manager) awalnya dibuat untuk memungkinkan kode vendor _cloud_ spesifik dan kode inti Kubernetes untuk berkembang secara independen satu sama lainnya. CCM berjalan bersama dengan komponen Master lainnya seperti Kubernetes Controller Manager, API Server, dan Scheduler. CCM juga dapat dijalankan sebagai Kubernetes Addon (tambahan fungsi terhadap Kubernetes), yang akan berjalan di atas kluster Kubernetes.
|
||||
Konsep _Cloud Controller Manager_/CCM (jangan tertukar dengan program biner kube-controller-manager) awalnya dibuat untuk memungkinkan kode vendor _cloud_ spesifik dan kode inti Kubernetes untuk berkembang secara independen satu sama lainnya. CCM berjalan bersama dengan komponen Master lainnya seperti Kubernetes Controller Manager, API Server, dan Scheduler. CCM juga dapat dijalankan sebagai Kubernetes Addon (tambahan fungsi terhadap Kubernetes), yang akan berjalan di atas klaster Kubernetes.
|
||||
|
||||
Desain CCM didasarkan pada mekanisme _plugin_ yang memungkinkan penyedia layanan _cloud_ untuk berintegrasi dengan Kubernetes dengan mudah dengan menggunakan _plugin_. Sudah ada rencana untuk pengenalan penyedia layanan _cloud_ baru pada Kubernetes, dan memindahkan penyedia layanan _cloud_ yang sudah ada dari model yang lama ke model CCM.
|
||||
|
||||
Dokumen ini mendiskusikan konsep di balik CCM dan mendetail fungsi-fungsinya.
|
||||
|
||||
Berikut adalah arsitektur sebuah kluster Kubernetes tanpa CCM:
|
||||
Berikut adalah arsitektur sebuah klaster Kubernetes tanpa CCM:
|
||||
|
||||
|
||||
|
||||
@@ -69,20 +69,20 @@ Kebanyakan fungsi CCM diturunkan dari KCM. Seperti yang telah disebutkan pada ba
|
||||
|
||||
#### Node Controller
|
||||
|
||||
Node Controller bertugas untuk menyiapkan sebuah node dengan cara mengambil informasi node-node yang berjalan di dalam kluster dari penyedia layanan _cloud_. Node Controller melakukan fungsi-fungsi berikut:
|
||||
Node Controller bertugas untuk menyiapkan sebuah node dengan cara mengambil informasi node-node yang berjalan di dalam klaster dari penyedia layanan _cloud_. Node Controller melakukan fungsi-fungsi berikut:
|
||||
|
||||
1. Menyiapkan sebuah node dengan memberi label _zone_/_region_ yang spesifik pada _cloud_.
|
||||
2. Menyiapkan sebuah node dengan informasi _instance_ yang spesifik _cloud_ , misalnya tipe dan ukurannya.
|
||||
3. Mendapatkan alamat jaringan dan _hostname_ milik node tersebut.
|
||||
4. Dalam hal sebuah node menjadi tidak responsif, memeriksa _cloud_ untuk melihat apakah node tersebut telah dihapus dari _cloud_. Juga, menghapus objek Node tersebut dari kluster Kubernetes, jika node tersebut telah dihapus dari _cloud_.
|
||||
4. Dalam hal sebuah node menjadi tidak responsif, memeriksa _cloud_ untuk melihat apakah node tersebut telah dihapus dari _cloud_. Juga, menghapus objek Node tersebut dari klaster Kubernetes, jika node tersebut telah dihapus dari _cloud_.
|
||||
|
||||
#### Route Controller
|
||||
|
||||
Route Controller bertugas mengkonfigurasi rute jaringan di dalam _cloud_ secara sesuai agar Container pada node-node yang berbeda di dalam kluster Kubernetes dapat berkomunikasi satu sama lain. Route Controller hanya berlaku untuk kluster yang berjalan pada Google Compute Engine (GCE) di penyedia layanan _cloud_ GCP.
|
||||
Route Controller bertugas mengkonfigurasi rute jaringan di dalam _cloud_ secara sesuai agar Container pada node-node yang berbeda di dalam klaster Kubernetes dapat berkomunikasi satu sama lain. Route Controller hanya berlaku untuk klaster yang berjalan pada Google Compute Engine (GCE) di penyedia layanan _cloud_ GCP.
|
||||
|
||||
#### Service Controller
|
||||
|
||||
Service Controller bertugas memantau terjadinya operasi `create`, `update`, dan `delete` pada Service. Berdasarkan keadaan terkini Service-service pada kluster Kubernetes, Service Controller mengkonfigurasi _load balancer_ spesifik _cloud_ (seperti ELB, Google LB, atau Oracle Cloud Infrastructure LB) agar sesuai dengan keadaan Service-service pada kluster Kubernetes. Sebagai tambahan, Service Controller juga memastikan bahwa _service backend_ (target dari _load balancer_ yang bersangkutan) dari _load balancer cloud_ tersebut berada dalam kondisi terkini.
|
||||
Service Controller bertugas memantau terjadinya operasi `create`, `update`, dan `delete` pada Service. Berdasarkan keadaan terkini Service-service pada klaster Kubernetes, Service Controller mengkonfigurasi _load balancer_ spesifik _cloud_ (seperti ELB, Google LB, atau Oracle Cloud Infrastructure LB) agar sesuai dengan keadaan Service-service pada klaster Kubernetes. Sebagai tambahan, Service Controller juga memastikan bahwa _service backend_ (target dari _load balancer_ yang bersangkutan) dari _load balancer cloud_ tersebut berada dalam kondisi terkini.
|
||||
|
||||
### 2. Kubelet
|
||||
|
||||
@@ -230,7 +230,7 @@ Penyedia layanan cloud berikut telah mengimplementasikan CCM:
|
||||
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
|
||||
* [Linode](https://github.com/linode/linode-cloud-controller-manager)
|
||||
|
||||
## Administrasi Kluster
|
||||
## Administrasi Klaster
|
||||
|
||||
Petunjuk lengkap untuk mengkonfigurasi dan menjalankan CCM disediakan [di sini](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager).
|
||||
|
||||
|
||||
@@ -6,23 +6,23 @@ weight: 20
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Dokumen ini menjelaskan tentang jalur-jalur komunikasi di antara kluster Kubernetes dan master yang sebenarnya hanya berhubungan dengan apiserver saja.
|
||||
Kenapa ada dokumen ini? Supaya kamu, para pengguna Kubernetes, punya gambaran bagaimana mengatur instalasi untuk memperketat konfigurasi jaringan di dalam kluster.
|
||||
Hal ini cukup penting, karena kluster bisa saja berjalan pada jaringan tak terpercaya (<i>untrusted network</i>), ataupun melalui alamat-alamat IP publik pada penyedia cloud.
|
||||
Dokumen ini menjelaskan tentang jalur-jalur komunikasi di antara klaster Kubernetes dan master yang sebenarnya hanya berhubungan dengan apiserver saja.
|
||||
Kenapa ada dokumen ini? Supaya kamu, para pengguna Kubernetes, punya gambaran bagaimana mengatur instalasi untuk memperketat konfigurasi jaringan di dalam klaster.
|
||||
Hal ini cukup penting, karena klaster bisa saja berjalan pada jaringan tak terpercaya (<i>untrusted network</i>), ataupun melalui alamat-alamat IP publik pada penyedia cloud.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Kluster menuju Master
|
||||
## Klaster menuju Master
|
||||
|
||||
Semua jalur komunikasi dari kluster menuju master diterminasi pada apiserver.
|
||||
Semua jalur komunikasi dari klaster menuju master diterminasi pada apiserver.
|
||||
Tidak ada komponen apapun di dalam master, selain apiserver, yang terekspos ke luar untuk diakses dari servis <i>remote</i>.
|
||||
Untuk instalasi kluster pada umumnya, apiserver diatur untuk <i>listen</i> ke koneksi <i>remote</i> melalui port HTTPS (443) yang aman, dengan satu atau beberapa metode [autentikasi](/docs/reference/access-authn-authz/authentication/) <i>client</i> yang telah terpasang.
|
||||
Untuk instalasi klaster pada umumnya, apiserver diatur untuk <i>listen</i> ke koneksi <i>remote</i> melalui port HTTPS (443) yang aman, dengan satu atau beberapa metode [autentikasi](/docs/reference/access-authn-authz/authentication/) <i>client</i> yang telah terpasang.
|
||||
Sebaiknya, satu atau beberapa metode [otorisasi](/docs/reference/access-authn-authz/authorization/) juga dipasang, terutama jika kamu memperbolehkan [permintaan anonim (<i>anonymous request</i>)](/docs/reference/access-authn-authz/authentication/#anonymous-requests) ataupun [service account token](/docs/reference/access-authn-authz/authentication/#service-account-tokens).
|
||||
|
||||
Node-node seharusnya disediakan dengan <i>public root certificate</i> untuk kluster, sehingga node-node tersebut bisa terhubung secara aman ke apiserver dengan kredensial <i>client</i> yang valid.
|
||||
Node-node seharusnya disediakan dengan <i>public root certificate</i> untuk klaster, sehingga node-node tersebut bisa terhubung secara aman ke apiserver dengan kredensial <i>client</i> yang valid.
|
||||
Contohnya, untuk instalasi GKE dengan standar konfigurasi, kredensial <i>client</i> harus diberikan kepada kubelet dalam bentuk <i>client certificate</i>.
|
||||
Lihat [menghidupkan TLS kubelet](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) untuk menyediakan <i>client certificate</i> untuk kubelet secara otomatis.
|
||||
|
||||
@@ -31,14 +31,14 @@ Dengan ini, Kubernetes memasukkan <i>public root certificate</i> dan <i>bearer t
|
||||
Kubernetes <i>service</i> (di dalam semua <i>namespace</i>) diatur dengan sebuah alamat IP virtual.
|
||||
Semua yang mengakses alamat IP ini akan dialihkan (melalui kube-proxy) menuju <i>endpoint</i> HTTPS dari apiserver.
|
||||
|
||||
Komponen-komponen master juga berkomunikasi dengan apiserver melalui port yang aman di dalam kluster.
|
||||
Akibatnya, untuk konfigurasi yang umum dan standar, semua koneksi dari kluster (node-node dan pod-pod yang berjalan di atas node tersebut) menuju master sudah terhubung dengan aman.
|
||||
Dan juga, kluster dan master bisa terhubung melalui jaringan publik dan/atau yang tak terpercaya (<i>untrusted</i>).
|
||||
Komponen-komponen master juga berkomunikasi dengan apiserver melalui port yang aman di dalam klaster.
|
||||
Akibatnya, untuk konfigurasi yang umum dan standar, semua koneksi dari klaster (node-node dan pod-pod yang berjalan di atas node tersebut) menuju master sudah terhubung dengan aman.
|
||||
Dan juga, klaster dan master bisa terhubung melalui jaringan publik dan/atau yang tak terpercaya (<i>untrusted</i>).
|
||||
|
||||
## Master menuju Kluster
|
||||
## Master menuju Klaster
|
||||
|
||||
Ada dua jalur komunikasi utama dari master (apiserver) menuju kluster.
|
||||
Pertama, dari apiserver ke <i>process</i> kubelet yang berjalan pada setiap node di dalam kluster.
|
||||
Ada dua jalur komunikasi utama dari master (apiserver) menuju klaster.
|
||||
Pertama, dari apiserver ke <i>process</i> kubelet yang berjalan pada setiap node di dalam klaster.
|
||||
Kedua, dari apiserver ke setiap node, pod, ataupun service melalui fungsi <i>proxy</i> pada apiserver.
|
||||
|
||||
### Apiserver menuju kubelet
|
||||
@@ -67,8 +67,8 @@ Koneksi ini **tidak aman** untuk dilalui pada jaringan publik dan/atau tak terpe
|
||||
|
||||
### Tunnel SSH
|
||||
|
||||
Kubernetes menyediakan tunnel SSH untuk mengamankan jalur komunikasi Master -> Kluster.
|
||||
Dengan ini, apiserver menginisiasi sebuah <i>tunnel</i> SSH untuk setiap node di dalam kluster (terhubung ke server SSH di port 22) dan membuat semua trafik menuju kubelet, node, pod, atau service dilewatkan melalui <i>tunnel</i> tesebut.
|
||||
Kubernetes menyediakan tunnel SSH untuk mengamankan jalur komunikasi Master -> Klaster.
|
||||
Dengan ini, apiserver menginisiasi sebuah <i>tunnel</i> SSH untuk setiap node di dalam klaster (terhubung ke server SSH di port 22) dan membuat semua trafik menuju kubelet, node, pod, atau service dilewatkan melalui <i>tunnel</i> tesebut.
|
||||
<i>Tunnel</i> ini memastikan trafik tidak terekspos keluar jaringan dimana node-node berada.
|
||||
|
||||
<i>Tunnel</i> SSH saat ini sudah usang (<i>deprecated</i>), jadi sebaiknya jangan digunakan, kecuali kamu tahu pasti apa yang kamu lakukan.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user