Node #

Jika kluster adalah abstraksi dari satu unit komputer besar, maka Node adalah mesin-mesin fisik atau mesin virtual (Virtual Machine) individual yang menyusun kluster tersebut. Node bertindak sebagai unit komputasi riil tempat beban kerja aplikasi kita dijalankan.

Memahami arsitektur internal sebuah node, bagaimana ia berinteraksi dengan control plane, bagaimana resource dikelola, serta bagaimana melakukan pemeliharaan node secara aman adalah keahlian wajib bagi tim platform dan DevOps untuk menjaga kluster tetap stabil di skala produksi.

Dua Jenis Node dalam Kluster #

Berdasarkan tanggung jawabnya, mesin server di dalam kluster Kubernetes dibagi menjadi dua peran:

1. Control Plane Node #

Node yang didedikasikan khusus untuk menjalankan komponen kontrol kluster (kube-apiserver, etcd, kube-scheduler, kube-controller-manager). Node ini tidak boleh menjalankan beban kerja aplikasi pengguna agar resource-nya tidak terganggu. Di kluster produksi yang aman, control plane node diberi tanda khusus (Taint) agar scheduler tidak menempatkan Pod aplikasi biasa di sana.

2. Worker Node #

Node yang didedikasikan khusus untuk menjalankan beban kerja aplikasi riil (Pod). Node inilah yang memiliki kapasitas CPU dan RAM besar untuk melayani permintaan pengguna.

Anatomi Internal Worker Node #

Setiap Worker Node memiliki tiga komponen utama yang berjalan sebagai service sistem operasi host untuk mengelola kontainer:

1. Kubelet (Agen Kluster Utama) #

Kubelet adalah perwakilan resmi Control Plane di setiap node. Ia terus memantau instruksi dari API Server untuk memastikan kontainer di dalam node berjalan sesuai spesifikasi yang diminta.

flowchart TD
    A["Kubelet Polling ke API Server"] --> B["Terima PodSpec (Spesifikasi Pod baru/update)"]
    B --> C["Kubelet instruksikan Container Runtime (CRI)"]
    C --> D["CRI download image & jalankan container"]
    D --> E["Kubelet pantau kesehatan (Liveness & Readiness Probes)"]
    E --> F["Kubelet laporkan status node & Pod ke API Server"]
    F --> A

Kubelet bekerja dengan pola loop tertutup (reconciliation loop). Jika Kubelet mendeteksi kontainer di dalam Pod tidak berjalan padahal spesifikasi meminta ia berjalan, Kubelet akan langsung memerintahkan runtime untuk merestart kontainer tersebut secara lokal.

2. Kube-Proxy (Pengatur Jaringan Node) #

Kube-proxy berjalan di setiap node untuk memelihara aturan jaringan kluster (network rules). Aturan ini memungkinkan komunikasi jaringan ke Pod dari sesi di dalam maupun di luar kluster. Kube-proxy menulis aturan perutean pada level sistem operasi menggunakan dua mode utama:

• iptables Mode: Kube-proxy menulis aturan filter paket Linux standard. Cepat untuk kluster skala kecil, namun kinerjanya menurun drastis ketika jumlah Service kluster mencapai ribuan karena pencarian aturan bersifat linier.
• IPVS (IP Virtual Server) Mode: Menggunakan teknologi load balancing internal kernel Linux. Sangat efisien, memiliki algoritma load balancing yang lebih canggih (seperti least connection), dan kinerjanya tetap stabil bahkan pada kluster skala raksasa dengan puluhan ribu Service.

3. Container Runtime (Eksekutor Kontainer) #

Software yang bertugas untuk mengelola siklus hidup kontainer fisik (mengunduh image, menjalankan proses isolasi, menghentikan kontainer). Kubernetes tidak menjalankan kontainer secara langsung, melainkan melalui standar antarmuka Container Runtime Interface (CRI).

Sejak Docker didepresiasi dari core internal Kubernetes, industri bermigrasi menggunakan runtime yang lebih ramping dan dikhususkan untuk orkestrasi seperti containerd atau CRI-O.

Status, Kondisi, dan Kesehatan Node #

Kubernetes API Server secara berkala memantau kesehatan seluruh node melalui data heartbeat yang dikirimkan oleh kubelet. Kita dapat memantau status dasar node menggunakan perintah:

kubectl get nodes

Untuk melihat detail kesehatan dan kondisi internal node, gunakan perintah:

kubectl describe node <nama-node>

Di dalam output detail, terdapat blok Conditions yang memantau parameter kesehatan kritis berikut:

Kebijakan Penggusuran (Eviction) Pod #

Jika sebuah node berada dalam status NotReady atau mengalami tekanan resource (MemoryPressure / DiskPressure) dalam waktu yang cukup lama (default batas waktu toleransi adalah 5 menit), Controller Manager Kubernetes akan mengambil tindakan penggusuran. Seluruh Pod yang berjalan di node bermasalah tersebut akan ditandai untuk dihapus dan dijadwalkan ulang oleh Scheduler ke node lain yang masih sehat dan berstatus Ready.

Kapasitas Node: Capacity vs Allocatable #

Mesin node memiliki batas fisik resource (CPU dan RAM). Namun, kita tidak boleh menggunakan seluruh kapasitas fisik tersebut untuk menjalankan kontainer aplikasi. Jika seluruh RAM fisik habis dikonsumsi oleh aplikasi, sistem operasi host akan mengalami crash dan membawa mati seluruh node.

Kubernetes membagi kapasitas node menjadi dua kategori:

1. Capacity: Total resource fisik yang terbaca oleh sistem operasi.
2. Allocatable: Sisa resource yang aman dan benar-benar dapat dialokasikan oleh Scheduler untuk menjalankan Pod aplikasi.

Kubernetes menghitung nilai resource Allocatable menggunakan rumus berikut:

Allocatable = Capacity - [Kube-Reserved] - [System-Reserved] - [Eviction-Threshold]

• Kube-Reserved: Resource yang dipesan dan dikunci khusus untuk menjalankan agen Kubernetes internal di node (seperti Kubelet dan Kube-Proxy).
• System-Reserved: Resource yang dipesan untuk sistem operasi dasar host (seperti systemd, journald, SSH daemon).
• Eviction-Threshold: Batas memori kritis yang sengaja dikosongkan (misal: 100Mi RAM) sebagai zona aman agar node sempat menggusur kontainer sebelum RAM fisik benar-benar habis.

Scheduler Kubernetes hanya akan melihat kapasitas Allocatable saat menghitung apakah sebuah node sanggup menerima Pod baru berdasarkan nilai resource requests Pod tersebut.

Mengarahkan Pod: Kontrol Penjadwalan Node #

Kubernetes memberikan kontrol penuh kepada kita untuk menentukan di node mana sebuah aplikasi boleh dijalankan:

1. Node Selector (Sederhana) #

Membatasi penempatan Pod pada node yang memiliki label tertentu secara kaku.

# Contoh Node Selector Manifes Pod
spec:
  nodeSelector:
    disktype: ssd # Pod hanya akan dijalankan di node yang memiliki label disktype=ssd

2. Node Affinity (Ekspresif) #

Mekanisme penjadwalan yang lebih fleksibel dibanding selector. Mendukung aturan yang bersifat wajib (requiredDuringSchedulingIgnoredDuringExecution) maupun hanya berupa preferensi/prioritas (preferredDuringSchedulingIgnoredDuringExecution).

# Contoh Node Affinity Manifes Pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/zone
            operator: In
            values:
            - asia-southeast1-a

3. Taints & Tolerations (Proteksi Node) #

Berbeda dengan selector dan affinity yang menarik Pod ke node tertentu, Taints bertugas menjauhkan/menolak Pod dari node tertentu. Node yang diberi Taint tidak akan pernah menerima Pod apa pun, kecuali Pod tersebut memiliki Toleration yang cocok.

Contoh penggunaan di produksi: Node khusus database yang memiliki spesifikasi RAM sangat besar diberi Taint agar tidak ditempatkan Pod Frontend biasa milik tim developer.

Pemeliharaan Node: Cordon dan Drain secara Aman #

Ketika kita harus melakukan pemeliharaan server fisik (seperti menambah RAM, meng-upgrade OS kernel, atau mengganti perangkat keras), kita harus mengeluarkan node tersebut dari kluster secara aman tanpa menyebabkan gangguan layanan bagi pengguna.

Dua perintah kubectl penting untuk pemeliharaan node:

1. Cordon (Mengunci Node) #

Menandai node sebagai SchedulingDisabled. Pod yang ada di dalam node tetap berjalan normal, namun Scheduler dilarang keras menempatkan Pod baru ke node ini.

# Mengunci node agar tidak menerima Pod baru
kubectl cordon node-worker-2

2. Drain (Mengosongkan Node) #

Mengunci node sekaligus mengusir dan memindahkan seluruh Pod yang sedang berjalan di dalam node tersebut ke node sehat lainnya.

# Mengosongkan node untuk pemeliharaan
kubectl drain node-worker-2 --ignore-daemonsets --delete-emptydir-data

Setelah pemeliharaan selesai, kembalikan node ke kondisi aktif:

# Mengaktifkan kembali penjadwalan ke node
kubectl uncordon node-worker-2

ANTI-PATTERN: Menjalankan Drain pada Node dengan Aplikasi Single-Replica
// KITA MELAKUKAN:
- Mengeksekusi perintah `kubectl drain node-worker-2` untuk upgrade kernel OS host.
- Node tersebut ternyata sedang menjalankan Pod API Pembayaran yang hanya memiliki 1 replika (single-replica).
// KONSEKUENSI DI PRODUKSI:
- Pod dihapus dari node-worker-2. Selama masa tunggu pembuatan Pod baru di node lain 
  (proses inisialisasi jaringan, image pull, startup JVM), traffic transaksi pengguna 
  akan mengalami error 502 Bad Gateway. Downtime terdeteksi di sistem.

✓ SOLUSI YANG BENAR:
- Pastikan seluruh aplikasi produksi yang kritis dideploy menggunakan replika minimal N >= 2 di bawah Deployment.
- Konfigurasikan **Pod Disruption Budget (PDB)** untuk membatasi jumlah maksimum Pod yang boleh tidak tersedia secara bersamaan selama proses pemeliharaan.
- Periksa kesiapan sebelum drain: jalankan `kubectl get pods -o wide` untuk mendeteksi Pod single-replica yang terancam mati.

Ringkasan #

• Node adalah unit komputasi riil — berupa server fisik atau VM yang menjadi tempat eksekusi kontainer aplikasi kluster.
• Komponen Kunci Node — Kubelet bertindak sebagai agen pelapor status, Kube-proxy bertugas mengelola jaringan lokal node, dan Container Runtime bertugas mengeksekusi kontainer.
• Capacity vs Allocatable — Scheduler selalu merujuk pada kapasitas Allocatable (sisa RAM/CPU aman untuk aplikasi setelah dikurangi cadangan untuk agen Kubernetes dan OS).
• Kontrol Penjadwalan — Gunakan Node Selector dan Affinity untuk mengarahkan Pod ke node spesifik, serta Taints & Tolerations untuk memproteksi node dari aplikasi yang salah kamar.
• Prosedur Pemeliharaan Aman — Selalu gunakan kombinasi cordon untuk mengunci dan drain untuk mengosongkan node sebelum melakukan restart server demi menghindari downtime.

← Sebelumnya: Cluster   Berikutnya: Pod →