Mempelajari Panduan Dasar Kubernetes

Konsep

Kubernetes v1.15 dokumentasi sudah tidak dirawat lagi. Versi yang kamu lihat ini hanyalah snapshot statis. Untuk dokumentasi terkini, lihat versi terkini.

Edit This Page

Node

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 dan diatur oleh komponen-komponen yang dimiliki oleh master. Servis-servis di dalam sebuah node terdiri dari runtime kontainer, kubelet dan kube-proxy. Untuk lebih detail, lihat dokumentasi desain arsitektur pada Node Kubernetes.

Status Node

Sebuah status node berisikan informasi sebagai berikut:

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.

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).

"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 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) 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 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.

Perhatian: 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.

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 dan 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:

{
  "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.

Catatan: 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.

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). 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 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:

Ketika mode otorisasi Node dan NodeRestriction admission plugin 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:

kubectl cordon $NODENAME
Catatan: 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.

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, 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 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.

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.

Masukan