From 734eb9a086022e4ba8656eb21ecb747fd83b44dd Mon Sep 17 00:00:00 2001 From: Giri Kuncoro Date: Sun, 21 Apr 2019 14:59:45 +0530 Subject: [PATCH] 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 fixes --- .../id/docs/concepts/architecture/_index.md | 5 + .../architecture/master-node-communication.md | 77 ++++++ .../id/docs/concepts/architecture/nodes.md | 231 ++++++++++++++++++ 3 files changed, 313 insertions(+) create mode 100644 content/id/docs/concepts/architecture/_index.md create mode 100644 content/id/docs/concepts/architecture/master-node-communication.md create mode 100644 content/id/docs/concepts/architecture/nodes.md diff --git a/content/id/docs/concepts/architecture/_index.md b/content/id/docs/concepts/architecture/_index.md new file mode 100644 index 0000000000..6a5719c5ab --- /dev/null +++ b/content/id/docs/concepts/architecture/_index.md @@ -0,0 +1,5 @@ +--- +title: "Arsitektur Kubernetes" +weight: 30 +--- + diff --git a/content/id/docs/concepts/architecture/master-node-communication.md b/content/id/docs/concepts/architecture/master-node-communication.md new file mode 100644 index 0000000000..6c31bbf63f --- /dev/null +++ b/content/id/docs/concepts/architecture/master-node-communication.md @@ -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 (untrusted network), 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 remote. +Untuk instalasi kluster pada umumnya, apiserver diatur untuk listen ke koneksi remote melalui port HTTPS (443) yang aman, dengan satu atau beberapa metode [autentikasi](/docs/reference/access-authn-authz/authentication/) client yang telah terpasang. +Sebaiknya, satu atau beberapa metode [otorisasi](/docs/reference/access-authn-authz/authorization/) juga dipasang, terutama jika kamu memperbolehkan [permintaan anonim (anonymous request)](/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 public root certificate untuk kluster, sehingga node-node tersebut bisa terhubung secara aman ke apiserver dengan kredensial client yang valid. +Contohnya, untuk instalasi GKE dengan standar konfigurasi, kredensial client harus diberikan kepada kubelet dalam bentuk client certificate. +Lihat [menghidupkan TLS kubelet](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) untuk menyediakan client certificate untuk kubelet secara otomatis. + +Jika diperlukan, pod-pod dapat terhubung pada apiserver secara aman dengan menggunakan service account. +Dengan ini, Kubernetes memasukkan public root certificate dan bearer token yang valid ke dalam pod, secara otomatis saat pod mulai dijalankan. +Kubernetes service (di dalam semua namespace) diatur dengan sebuah alamat IP virtual. +Semua yang mengakses alamat IP ini akan dialihkan (melalui kube-proxy) menuju endpoint 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 (untrusted). + +## Master menuju Kluster + +Ada dua jalur komunikasi utama dari master (apiserver) menuju kluster. +Pertama, dari apiserver ke process kubelet yang berjalan pada setiap node di dalam kluster. +Kedua, dari apiserver ke setiap node, pod, ataupun service melalui fungsi proxy 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 (attach). + * Menyediakan fungsi port-forward dari kubelet. + +Semua koneksi ini diterminasi pada endpoint HTTPS dari kubelet. +Secara default, apiserver tidak melakukan verifikasi serving certificate dari kubelet, yang membuat koneksi terekspos pada serangan man-in-the-middle, dan juga **tidak aman** untuk terhubung melalui jaringan tak terpercaya (untrusted) dan/atau publik. + +Untuk melakukan verifikasi koneksi ini, berikan root certificate pada apiserver melalui tanda `--kubelet-certificate-authority`, sehingga apiserver dapat memverifikasi serving certificate 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 (untrusted) 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 default, koneksi apiserver menuju node, pod atau service hanyalah melalui HTTP polos (plain), 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 certificate yang disediakan oleh endpoint HTTPS maupun kredensial client, sehingga walaupun koneksi sudah terenkripsi, tidak ada yang menjamin integritasnya. +Koneksi ini **tidak aman** untuk dilalui pada jaringan publik dan/atau tak terpercaya untrusted. + +### Tunnel SSH + +Kubernetes menyediakan tunnel SSH untuk mengamankan jalur komunikasi Master -> Kluster. +Dengan ini, apiserver menginisiasi sebuah tunnel 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 tunnel tesebut. +Tunnel ini memastikan trafik tidak terekspos keluar jaringan dimana node-node berada. + +Tunnel SSH saat ini sudah usang (deprecated), jadi sebaiknya jangan digunakan, kecuali kamu tahu pasti apa yang kamu lakukan. +Sebuah desain baru untuk mengganti kanal komunikasi ini sedang disiapkan. + +{{% /capture %}} diff --git a/content/id/docs/concepts/architecture/nodes.md b/content/id/docs/concepts/architecture/nodes.md new file mode 100644 index 0000000000..fad8351cb8 --- /dev/null +++ b/content/id/docs/concepts/architecture/nodes.md @@ -0,0 +1,231 @@ +--- +title: Node +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +Node merupakan sebuah mesin worker 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 field-field 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 route eksternal (bisa diakses dari luar kluster). +* InternalIP: Biasanya merupakan alamat IP pada node yang hanya punya route di dalam kluster. + + +### Condition + +Field `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 (healthy) dan siap untuk menerima pod, `False` jika node tidak lagi sehat (unhealthy) 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 (pressure) -- maksudnya, jika kapasitas memori node sudah di titik rendah; `False` untuk sebaliknya | +| `PIDPressure` | `True` jika process-process mengalami tekanan (pressure) -- maksudnya, jika node menjalankan terlalu banyak process; `False` untuk sebaliknya | +| `DiskPressure` | `True` jika ukuran disk mengalami tekanan (pressure) -- maksudnya, jika kapasitas disk sudah di titik rendah; `False` untuk sebaliknya | +| `NetworkUnavailable` | `True` jika jaringan untuk node tidak dikonfigurasi dengan benar, `False` untuk sebaliknya | + +Condition pada node direpresentasikan oleh suatu obyek JSON. Sebagai contoh, respon berikut ini menggambarkan node yang sedang sehat (healthy). + +```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 eviction timeout 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 schedule 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 lifecycle node secara otomatis membuat [taints](/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan conditions. +Akibatnya, scheduler menghiraukan conditions ketika mempertimbangkan sebuah Node; scheduler akan melihat pada taints sebuah Node dan tolerations sebuah Pod. + +Sekarang, para pengguna dapat memilih antara model scheduling yang lama dan model scheduling yang lebih fleksibel. +Pada model yang lama, sebuah pod tidak memiliki tolerations apapun sampai mendapat giliran schedule. Namun, pod dapat dijalankan pada Node tertentu, dimana pod melakukan toleransi terhadap taints yang dimiliki oleh Node tersebut. + +{{< caution >}} +Mengaktifkan fitur ini menambahkan delay sedikit antara waktu saat suatu condition terlihat dan saat suatu taint dibuat. Delay ini biasanya kurang dari satu detik, tapi dapat menambahkan jumlah yang telah berhasil mendapat schedule, namun ditolak oleh kubelet untuk dijalankan. +{{< /caution >}} + +### Capacity + +Menjelaskan tentang resource-resource 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 pool 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 (health checking), berdasarkan field `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 (role) dalam sebuah lifecycle node. +Pertama, menetapkan blok CIDR pada node tersebut saat registrasi (jika CIDR assignment 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 environment cloud, kapanpun saat sebuah node tidak lagi sehat (unhealthy), 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 (health) node. +Kontroler node bertanggung jawab untuk mengubah status `NodeReady condition` pada `NodeStatus` menjadi `ConditionUnknown`, ketika sebuah node terputus jaringannya (kontroler node tidak lagi mendapat heartbeat karena suatu hal, contohnya karena node tidak hidup), dan saat kemudian melakukan eviction terhadap semua pod yang ada pada node tersebut (melalui terminasi halus -- graceful) jika node masih terus terputus. (Timeout standar adalah 40 detik untuk mulai melaporkan `ConditionUnknown` dan 5 menit setelah itu untuk mulai melakukan eviction terhadap pod.) +Kontroler node memeriksa state masing-masing node untuk durasi yang ditentukan oleh argumen `--node-monitor-period`. + +Pada versi Kubernetes sebelum 1.13, `NodeStatus` adalah heartbeat yang diberikan oleh node. +Setelah versi 1.13, fitur node lease 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 node lease diaktifasi, setiap node terhubung dengan obyek `Lease` di dalam namespace `kube-node-lease` yang terus diperbarui secara berkala. +Kemudian, `NodeStatus` dan node lease keduanya dijadikan sebagai heartbeat dari node. +Semua node lease diperbarui sesering mungkin, sedangkan `NodeStatus` dilaporkan dari node untuk master hanya ketika ada perubahan atau telah melewati periode waktu tertentu (default-nya 1 menit, lebih lama daripada default timeout node-node yang terputus jaringannya). +Karena node lease jauh lebih ringan daripada `NodeStatus`, fitur ini membuat heartbeat dari node jauh lebih murah secara signifikan dari sudut pandang skalabilitas dan performa. + +Di Kubernetes 1.4, kami telah memperbarui logic 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 state dari semua node di dalam kluster, saat memutuskan untuk melakukan eviction pada pod. + +Pada kasus kebanyakan, kontroler node membatasi rate eviction menjadi `--node-eviction-rate` (default-nya 0.1) per detik. +Artinya, kontroler node tidak akan melakukan eviction pada pod lebih dari 1 node per 10 detik. + +Perlakuan eviction pada node berubah ketika sebuah node menjadi tidak sehat (unhealthy) di dalam suatu zona availability. +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` (default-nya 0.55), maka rate eviction berkurang: untuk ukuran kluster yang kecil (saat jumlahnya lebih kecil atau sama dengan jumlah node `--large-cluster-size-threshold` - default-nya 50), maka eviction akan berhenti dilakukan. +Jika masih besar jumlahnya, rate eviction dikurangi menjadi `--secondary-node-eviction-rate` (default-nya 0.01) per detik. +Alasan kenapa hal ini diimplementasi untuk setiap zona availability adalah karena satu zona bisa saja terputus dari master, saat yang lainnya masih terhubung. +Jika kluster tidak menjangkau banyak zona availability yang disediakan oleh penyedia cloud, maka hanya ada satu zona (untuk semua node di dalam kluster). + +Alasan utama untuk menyebarkan node pada banyak zona availability adalah supaya workload dapat dipindahkan ke zona sehat (healthy) saat suatu zona mati secara menyeluruh. +Kemudian, jika semua node di dalam suatu zona menjadi tidak sehat (unhealthy), maka kontroler node melakukan eviction pada rate 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 eviction sampai jaringan terhubung kembali. + +Mulai dari Kubernetes 1.6, kontroler node juga bertanggung jawab untuk melakukan eviction pada pod-pod yang berjalan di atas node dengan taints `NoExecute`, ketika pod-pod tersebut sudah tidak lagi tolerate terhadap taints. +Sebagai tambahan, hal ini di-nonaktifkan secara default pada fitur alpha, kontroler node bertanggung jawab untuk menambahkan taints yang berhubungan dengan masalah pada node, seperti terputus atau `NotReady`. +Lihat [dokumentasi ini](/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang taints `NoExecute` dan fitur alpha. + +Mulai dari versi 1.8, kontroler node bisa diatur untuk bertanggung jawab pada pembuatan taints yang merepresentasikan node condition. +Ini merupakan fitur alpha untuk versi 1.8. + +### Self-Registration untuk Node + +Ketika argumen `--register-node` pada kubelet bernilai true (default-nya), kubelet akan berusaha untuk registrasi dirinya melalui API server. +Ini merupakan pattern yang disukai, digunakan oleh kebanyakan distros. + +Kubelet memulai registrasi diri (self-registration) dengan opsi-opsi berikut: + + - `--kubeconfig` - Path 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 taints (dipisahkan oleh koma `=:`). No-op jika `register-node` bernilai false. + - `--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 resource 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 resource-resource node (terlepas dari `--register-node`). +Modifikasi terdiri dari pengaturan label pada node dan membuat node tidak dapat di-schedule. + +Label-label pada node digunakan oleh selector node untuk mengatur proses schedule untuk pod, misalnya, membatasi sebuah pod hanya boleh dijalankan pada node-node tertentu. + +Menandai sebuah node untuk tidak dapat di-schedule mencegah pod baru untuk tidak di-schedule pada node, tanpa mempengaruhi pod-pod yang sudah berjalan pada node tersebut. +Ini berguna sebagai langkah persiapan untuk melakukan reboote pada node. +Sebagai contoh, untuk menandai sebuah node untuk tidak dapat di-schedule, jalankan perintah berikut: + +```shell +kubectl cordon $NODENAME +``` + +{{< note >}} +Pod-pod yang dibuat oleh suatu kontroler DaemonSet menghiraukan scheduler Kubernetes dan mengabaikan tanda unschedulable pada node. +Hal ini mengasumsikan bahwa daemons dimiliki oleh mesin, walaupun telah dilakukan drain pada aplikasi, saat melakukan persaiapan reboot. +{{< /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. + +Scheduler Kubernetes memastikan kalau ada resource yang cukup untuk menjalankan semua pod di dalam sebuah node. +Kubernetes memeriksa jumlah semua request 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 process yang ada di luar kontainer. + +Kalau kamu ingin secara eksplisit menyimpan resource cadangan untuk menjalankan process-process selain Pod, ikut tutorial [menyimpan resource cadangan untuk system daemon](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved). + + +## Obyek API + +Node adalah tingkatan tertinggi dari resource 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 %}}