Translate kube architecture section to Indonesian (#13887)
* Translate kube architecture section to Indonesian * Translate nodes doc into Indonesian * Change autorisasi to otorisasi and some minor fixespull/13935/head
Giri Kuncoro
Kubernetes Prow Robot
parent
d643cf9e0f
commit
734eb9a086
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: "Arsitektur Kubernetes"
|
||||
weight: 30
|
||||
---
|
||||
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
---
|
||||
title: Komunikasi Master-Node
|
||||
content_template: templates/concept
|
||||
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.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Kluster menuju Master
|
||||
|
||||
Semua jalur komunikasi dari kluster 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.
|
||||
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.
|
||||
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.
|
||||
|
||||
Jika diperlukan, pod-pod dapat terhubung pada apiserver secara aman dengan menggunakan <i>service account</i>.
|
||||
Dengan ini, Kubernetes memasukkan <i>public root certificate</i> dan <i>bearer token</i> yang valid ke dalam pod, secara otomatis saat pod mulai dijalankan.
|
||||
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>).
|
||||
|
||||
## Master menuju Kluster
|
||||
|
||||
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.
|
||||
Kedua, dari apiserver ke setiap node, pod, ataupun service melalui fungsi <i>proxy</i> pada apiserver.
|
||||
|
||||
### Apiserver menuju kubelet
|
||||
|
||||
Koneksi dari apiserver menuju kubelet bertujuan untuk:
|
||||
|
||||
* Melihat log dari pod-pod.
|
||||
* Masuk ke dalam pod-pod yang sedang berjalan (<i>attach</i>).
|
||||
* Menyediakan fungsi port-forward dari kubelet.
|
||||
|
||||
Semua koneksi ini diterminasi pada <i>endpoint</i> HTTPS dari kubelet.
|
||||
Secara <i>default</i>, apiserver tidak melakukan verifikasi <i>serving certificate</i> dari kubelet, yang membuat koneksi terekspos pada serangan <i>man-in-the-middle</i>, dan juga **tidak aman** untuk terhubung melalui jaringan tak terpercaya (<i>untrusted</i>) dan/atau publik.
|
||||
|
||||
Untuk melakukan verifikasi koneksi ini, berikan <i>root certificate</i> pada apiserver melalui tanda `--kubelet-certificate-authority`, sehingga apiserver dapat memverifikasi <i>serving certificate</i> dari kubelet.
|
||||
|
||||
Cara lainnya, gunakan [tunnel SSH](/docs/concepts/architecture/master-node-communication/#ssh-tunnels) antara apiserver dan kubelet jika diperlukan, untuk menghindari komunikasi melalui jaringan tak terpercaya (<i>untrusted</i>) atau publik.
|
||||
|
||||
Terakhir, yang terpenting, aktifkan [autentikasi dan/atau otorisasi Kubelet](/docs/admin/kubelet-authentication-authorization/) untuk mengamankan API kubelet.
|
||||
|
||||
### Apiserver menuju Node, Pod, dan Service
|
||||
|
||||
Secara <i>default</i>, koneksi apiserver menuju node, pod atau service hanyalah melalui HTTP polos (<i>plain</i>), sehingga tidak ada autentikasi maupun enkripsi.
|
||||
Koneksi tersebut bisa diamankan melalui HTTPS dengan menambahkan `https:` pada URL API dengan nama dari node, pod, atau service.
|
||||
Namun, koneksi tidak tervalidasi dengan <i>certificate</i> yang disediakan oleh <i>endpoint</i> HTTPS maupun kredensial <i>client</i>, sehingga walaupun koneksi sudah terenkripsi, tidak ada yang menjamin integritasnya.
|
||||
Koneksi ini **tidak aman** untuk dilalui pada jaringan publik dan/atau tak terpercaya <i>untrusted</i>.
|
||||
|
||||
### 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.
|
||||
<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.
|
||||
Sebuah desain baru untuk mengganti kanal komunikasi ini sedang disiapkan.
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -0,0 +1,231 @@
|
|||
---
|
||||
title: Node
|
||||
content_template: templates/concept
|
||||
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.
|
||||
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).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Status Node
|
||||
|
||||
Sebuah status node berisikan informasi sebagai berikut:
|
||||
|
||||
* [Addresses](#addresses)
|
||||
* [Condition](#condition)
|
||||
* [Capacity](#capacity)
|
||||
* [Info](#info)
|
||||
|
||||
Masing-masing bagian dijelaskan secara rinci di bawah ini.
|
||||
|
||||
### Addresses
|
||||
|
||||
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.
|
||||
|
||||
|
||||
### Condition
|
||||
|
||||
<i>Field</i> `conditions` menjelaskan tentang status dari semua node yang sedang berjalan (`Running`).
|
||||
|
||||
| Kondisi Node | Penjelasan |
|
||||
|----------------|-------------|
|
||||
| `OutOfDisk` | `True` jika node sudah tidak punya cukup kapasitas disk untuk menjalankan pod baru, `False` jika sebaliknya |
|
||||
| `Ready` | `True` jika node sehat (<i>healthy</i>) dan siap untuk menerima pod, `False` jika node tidak lagi sehat (<i>unhealthy</i>) dan tidak siap menerima pod, serta `Unknown` jika kontroler node tidak menerima pesan di dalam `node-monitor-grace-period` (standarnya 40 detik) |
|
||||
| `MemoryPressure` | `True` jika memori pada node terkena tekanan (<i>pressure</i>) -- maksudnya, jika kapasitas memori node sudah di titik rendah; `False` untuk sebaliknya |
|
||||
| `PIDPressure` | `True` jika <i>process-process</i> mengalami tekanan (<i>pressure</i>) -- maksudnya, jika node menjalankan terlalu banyak <i>process</i>; `False` untuk sebaliknya |
|
||||
| `DiskPressure` | `True` jika ukuran disk mengalami tekanan (<i>pressure</i>) -- maksudnya, jika kapasitas disk sudah di titik rendah; `False` untuk sebaliknya |
|
||||
| `NetworkUnavailable` | `True` jika jaringan untuk node tidak dikonfigurasi dengan benar, `False` untuk sebaliknya |
|
||||
|
||||
<i>Condition</i> pada node direpresentasikan oleh suatu obyek JSON. Sebagai contoh, respon berikut ini menggambarkan node yang sedang sehat (<i>healthy</i>).
|
||||
|
||||
```json
|
||||
"conditions": [
|
||||
{
|
||||
"type": "Ready",
|
||||
"status": "True"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Jika status untuk `Ready condition` bernilai `Unknown` atau `False` untuk waktu yang lebih dari `pod-eviction-timeout`, tergantung bagaimana [kube-controller-manager](/docs/admin/kube-controller-manager/) dikonfigurasi, semua pod yang dijalankan pada node tersebut akan dihilangkan oleh Kontroler Node.
|
||||
Durasi <i>eviction timeout</i> yang standar adalah **lima menit**.
|
||||
Pada kasus tertentu ketika node terputus jaringannya, apiserver tidak dapat berkomunikasi dengan kubelet yang ada pada node.
|
||||
Keputusan untuk menghilangkan pod tidak dapat diberitahukan pada kubelet, sampai komunikasi dengan apiserver terhubung kembali.
|
||||
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.
|
||||
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>.
|
||||
Akibatnya, <i>scheduler</i> menghiraukan <i>conditions</i> ketika mempertimbangkan sebuah Node; <i>scheduler</i> akan melihat pada <i>taints</i> sebuah Node dan <i>tolerations</i> sebuah Pod.
|
||||
|
||||
Sekarang, para pengguna dapat memilih antara model <i>scheduling</i> yang lama dan model <i>scheduling</i> yang lebih fleksibel.
|
||||
Pada model yang lama, sebuah pod tidak memiliki <i>tolerations</i> apapun sampai mendapat giliran <i>schedule</i>. Namun, pod dapat dijalankan pada Node tertentu, dimana pod melakukan toleransi terhadap <i>taints</i> yang dimiliki oleh Node tersebut.
|
||||
|
||||
{{< caution >}}
|
||||
Mengaktifkan fitur ini menambahkan <i>delay</i> sedikit antara waktu saat suatu <i>condition</i> terlihat dan saat suatu <i>taint</i> dibuat. <i>Delay</i> ini biasanya kurang dari satu detik, tapi dapat menambahkan jumlah yang telah berhasil mendapat <i>schedule</i>, namun ditolak oleh kubelet untuk dijalankan.
|
||||
{{< /caution >}}
|
||||
|
||||
### Capacity
|
||||
|
||||
Menjelaskan tentang <i>resource-resource</i> yang ada pada node: CPU, memori, dan jumlah pod secara maksimal yang dapat dijalankan pada suatu node.
|
||||
|
||||
### Info
|
||||
|
||||
Informasi secara umum pada suatu node, seperti versi kernel, versi Kubernetes (versi kubelet dan kube-proxy), versi Docker (jika digunakan), nama OS.
|
||||
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.
|
||||
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:
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "Node",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "10.240.79.157",
|
||||
"labels": {
|
||||
"name": "my-first-k8s-node"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
{{< note >}}
|
||||
Kubernetes tetap menyimpan obyek untuk node yang tidak valid, dan terus memeriksa apakah node telah menjadi valid atau belum.
|
||||
Kamu harus secara eksplisit menghilangkan obyek Node tersebut untuk menghilangkan proses ini.
|
||||
{{< /note >}}
|
||||
|
||||
Saat ini, ada tiga komponen yang berinteraksi dengan antarmuka node di Kubernetes: kontroler node, kubelet, dan kubectl.
|
||||
|
||||
### Kontroler Node
|
||||
|
||||
Kontroler node adalah komponen master Kubernetes yang berfungsi untuk mengatur berbagai aspek dari node.
|
||||
|
||||
Kontroler node memiliki berbagai peran (<i>role</i>) dalam sebuah <i>lifecycle</i> node.
|
||||
Pertama, menetapkan blok CIDR pada node tersebut saat registrasi (jika CIDR <i>assignment</i> diaktifkan).
|
||||
|
||||
Kedua, terus memperbarui daftar internal node di dalam kontroler node, sesuai dengan daftar mesin yang tersedia di dalam penyedia layanan cloud.
|
||||
Ketika berjalan di dalam <i>environment</i> cloud, kapanpun saat sebuah node tidak lagi sehat (<i>unhealthy</i>), kontroler node bertanya pada penyedia cloud, apakah VM untuk node tersebut masihkah tersedia atau tidak.
|
||||
Jika sudah tidak tersedia, kontroler node menghilangkan node tersebut dari daftar node.
|
||||
|
||||
Ketiga, melakukan monitor terhadap kondisi kesehatan (<i>health</i>) node.
|
||||
Kontroler node bertanggung jawab untuk mengubah status `NodeReady condition` pada `NodeStatus` menjadi `ConditionUnknown`, ketika sebuah node terputus jaringannya (kontroler node tidak lagi mendapat <i>heartbeat</i> karena suatu hal, contohnya karena node tidak hidup), dan saat kemudian melakukan <i>eviction</i> terhadap semua pod yang ada pada node tersebut (melalui terminasi halus -- <i>graceful</i>) jika node masih terus terputus. (<i>Timeout</i> standar adalah 40 detik untuk mulai melaporkan `ConditionUnknown` dan 5 menit setelah itu untuk mulai melakukan <i>eviction</i> terhadap pod.)
|
||||
Kontroler node memeriksa <i>state</i> masing-masing node untuk durasi yang ditentukan oleh argumen `--node-monitor-period`.
|
||||
|
||||
Pada versi Kubernetes sebelum 1.13, `NodeStatus` adalah <i>heartbeat</i> yang diberikan oleh node.
|
||||
Setelah versi 1.13, fitur <i>node lease</i> diperkenalkan sebagai fitur alpha (fitur gate `NodeLease`,
|
||||
[KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)).
|
||||
Ketika fitur <i>node lease</i> diaktifasi, setiap node terhubung dengan obyek `Lease` di dalam <i>namespace</i> `kube-node-lease` yang terus diperbarui secara berkala.
|
||||
Kemudian, `NodeStatus` dan <i>node lease</i> keduanya dijadikan sebagai <i>heartbeat</i> dari node.
|
||||
Semua <i>node lease</i> diperbarui sesering mungkin, sedangkan `NodeStatus` dilaporkan dari node untuk master hanya ketika ada perubahan atau telah melewati periode waktu tertentu (<i>default</i>-nya 1 menit, lebih lama daripada <i>default timeout</i> node-node yang terputus jaringannya).
|
||||
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.
|
||||
|
||||
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 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).
|
||||
|
||||
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).
|
||||
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>.
|
||||
Sebagai tambahan, hal ini di-nonaktifkan secara <i>default</i> pada fitur alpha, kontroler node bertanggung jawab untuk menambahkan <i>taints</i> yang berhubungan dengan masalah pada node, seperti terputus atau `NotReady`.
|
||||
Lihat [dokumentasi ini](/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang <i>taints</i> `NoExecute` dan fitur alpha.
|
||||
|
||||
Mulai dari versi 1.8, kontroler node bisa diatur untuk bertanggung jawab pada pembuatan <i>taints</i> yang merepresentasikan node <i>condition</i>.
|
||||
Ini merupakan fitur alpha untuk versi 1.8.
|
||||
|
||||
### <i>Self-Registration</i> untuk Node
|
||||
|
||||
Ketika argumen `--register-node` pada kubelet bernilai <i>true</i> (<i>default</i>-nya), kubelet akan berusaha untuk registrasi dirinya melalui API server.
|
||||
Ini merupakan <i>pattern</i> yang disukai, digunakan oleh kebanyakan <i>distros</i>.
|
||||
|
||||
Kubelet memulai registrasi diri (<i>self-registration</i>) dengan opsi-opsi berikut:
|
||||
|
||||
- `--kubeconfig` - <i>Path</i> berisi kredensial-kredensial yang digunakan untuk registrasi diri pada apiserver.
|
||||
- `--cloud-provider` - Cara berbicara pada sebuah penyedia layanan cloud, baca tentang metadata-nya.
|
||||
- `--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-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.
|
||||
|
||||
Jika admin ingin untuk membuat obyek node secara manual, atur argument `--register-node=false` pada kubelet.
|
||||
|
||||
Admin dapat memodifikasi <i>resource-resource</i> node (terlepas dari `--register-node`).
|
||||
Modifikasi terdiri dari pengaturan label pada node dan membuat node tidak dapat di-<i>schedule</i>.
|
||||
|
||||
Label-label pada node digunakan oleh <i>selector</i> node untuk mengatur proses <i>schedule</i> untuk pod, misalnya, membatasi sebuah pod hanya boleh dijalankan pada node-node tertentu.
|
||||
|
||||
Menandai sebuah node untuk tidak dapat di-<i>schedule</i> mencegah pod baru untuk tidak di-<i>schedule</i> pada node, tanpa mempengaruhi pod-pod yang sudah berjalan pada node tersebut.
|
||||
Ini berguna sebagai langkah persiapan untuk melakukan <i>reboote</i> pada node.
|
||||
Sebagai contoh, untuk menandai sebuah node untuk tidak dapat di-<i>schedule</i>, jalankan perintah berikut:
|
||||
|
||||
```shell
|
||||
kubectl cordon $NODENAME
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Pod-pod yang dibuat oleh suatu kontroler DaemonSet menghiraukan <i>scheduler</i> Kubernetes dan mengabaikan tanda <i>unschedulable</i> pada node.
|
||||
Hal ini mengasumsikan bahwa <i>daemons</i> dimiliki oleh mesin, walaupun telah dilakukan <i>drain</i> pada aplikasi, saat melakukan persaiapan <i>reboot</i>.
|
||||
{{< /note >}}
|
||||
|
||||
### Kapasitas Node
|
||||
|
||||
Kapasitas node (jumlah CPU dan memori) adalah bagian dari obyek node.
|
||||
Pada umumnya, node-node melakukan registrasi diri dan melaporkan kapasitasnya saat obyek node dibuat.
|
||||
Jika kamu melakukan [administrasi node manual](#manual-node-administration), maka kamu perlu mengatur kapasitas node saat menambahkan node baru.
|
||||
|
||||
<i>Scheduler</i> Kubernetes memastikan kalau ada <i>resource</i> yang cukup untuk menjalankan semua pod di dalam sebuah node.
|
||||
Kubernetes memeriksa jumlah semua <i>request</i> untuk kontainer pada sebuah node tidak lebih besar daripada kapasitas node.
|
||||
Hal ini termasuk semua kontainer yang dijalankan oleh kubelet. Namun, ini tidak termasuk kontainer-kontainer yang dijalankan secara langsung oleh [runtime kontainer](/docs/concepts/overview/components/#node-components) ataupun <i>process</i> yang ada di luar kontainer.
|
||||
|
||||
Kalau kamu ingin secara eksplisit menyimpan <i>resource</i> cadangan untuk menjalankan <i>process-process</i> selain Pod, ikut tutorial [menyimpan resource cadangan untuk <i>system daemon</i>](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
|
||||
|
||||
|
||||
## Obyek API
|
||||
|
||||
Node adalah tingkatan tertinggi dari <i>resource</i> di dalam Kubernetes REST API.
|
||||
Penjelasan lebih detail tentang obyek API dapat dilihat pada: [Obyek Node API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
|
||||
|
||||
{{% /capture %}}
|
||||
Loading…
Reference in New Issue