Worker Node #

Worker Node adalah mesin pelaksana (executor) di dalam kluster Kubernetes. Jika Control Plane bertindak sebagai otak yang merancang strategi, maka Worker Node adalah otot yang bertugas melakukan pekerjaan fisik: menjalankan kontainer, mengelola perutean lalu lintas jaringan lokal, serta memelihara alokasi memori dan disk.

Memahami arsitektur internal dari Worker Node, serta bagaimana komponen-komponennya berinteraksi dengan kernel sistem operasi host, sangat penting untuk menjaga keandalan dan mendiagnosis masalah degradasi performa aplikasi di tingkat produksi.

Kubelet & Node Lease API: Efisiensi Detak Jantung Kluster #

Kubelet adalah perwakilan resmi Control Plane di setiap Worker Node. Tugas utamanya adalah memastikan seluruh kontainer di dalam node berjalan sesuai spesifikasi PodSpec yang dikirimkan oleh API Server.

Selain memantau spesifikasi Pod, Kubelet juga harus mengirimkan sinyal detak jantung (heartbeat) secara berkala (default setiap 10 detik) ke API Server untuk menyatakan bahwa node tersebut masih hidup dan dalam kondisi sehat.

Evolusi Heartbeat: Masalah Node Status Raksasa #

Pada versi Kubernetes terdahulu, Kubelet mengirimkan heartbeat dengan mengirimkan seluruh objek data status Node secara lengkap ke API Server. Objek Node ini sangat tebal (mencapai puluhan kilobyte) karena berisi informasi hardware, versi kernel, daftar image kontainer yang terunduh, serta kondisi RAM/disk.

Ketika kluster tumbuh menjadi ratusan node, ribuan request objek tebal ini membanjiri API Server setiap 10 detik, memicu kemacetan tulis pada database etcd dan menurunkan performa kluster.

Solusi Node Lease API #

Kubernetes memecahkan masalah ini dengan merilis Node Lease API.

Komunikasi Heartbeat Modern:
  
  [ Kubelet ] ─── kirim data kecil (Lease Object) setiap 10s ───> [ API Server ]
  [ Kubelet ] ─── kirim status lengkap (Node Object) hanya saat ada perubahan ───> [ API Server ]

• Lease Object: Sebuah objek berukuran sangat kecil (hanya beberapa byte) yang bertindak sebagai kartu absen. Kubelet memperbarui stempel waktu (timestamp) pada objek Lease ini setiap 10 detik. Jika etcd melihat stempel waktu diperbarui, node dianggap sehat.
• Node Object (Tebal): Kubelet hanya mengirimkan data status Node lengkap ketika terjadi perubahan fisik yang signifikan pada node (misalnya: ada disk yang penuh atau memori kritis).

Pendekatan ini memangkas beban lalu lintas API Server secara drastis, memungkinkan Kubernetes untuk menskalakan kluster hingga ribuan node tanpa kendala performa.

Jaringan Node: Komparasi Mode Kube-Proxy #

Kube-proxy adalah komponen jaringan yang berjalan di setiap node. Tugas utamanya adalah menerjemahkan konsep abstrak Service Kubernetes (alamat IP virtual stabil) menjadi aturan perutean lalu lintas jaringan riil di dalam mesin host.

Ada beberapa mode kerja Kube-proxy yang umum digunakan di industri:

Untuk lingkungan produksi dengan jumlah microservices berskala menengah ke atas, sangat direkomendasikan untuk mengonfigurasi Kube-proxy agar menggunakan mode IPVS atau mengadopsi teknologi CNI berbasis eBPF untuk meminimalkan overhead jaringan.

Container Runtime Interface (CRI) secara Mendalam #

Kubelet tidak memiliki kode internal untuk membuat atau menghentikan kontainer Docker. Kubelet mendelegasikan tugas tersebut ke mesin runtime eksternal melalui standar API terbuka yang disebut Container Runtime Interface (CRI).

Berikut adalah arsitektur aliran eksekusi CRI yang umum digunakan di produksi modern menggunakan containerd:

flowchart TD
    Kubelet["Kubelet"] -->|"gRPC (Local Domain Socket)"| CRIPlugin["containerd-cri plugin (Bagian dari containerd daemon)"]
    CRIPlugin --> ContainerdShim["containerd-shim (Satu proses shim per Pod untuk memisahkan lifecycle)"]
    ContainerdShim --> Runc["runc (Runtime tingkat rendah yang membuat namespace Linux & cgroups)"]
    Runc --> Container["Container Aplikasi (Berjalan secara fisik di kernel host)"]

Mengapa Perlu containerd-shim? #

Proses shim bertindak sebagai penjaga kontainer. Ketika containerd selesai meluncurkan kontainer aplikasi melalui runc, containerd dapat dimatikan atau di-upgrade versinya tanpa merusak atau merestart kontainer aplikasi yang sedang berjalan. Proses shim akan tetap memegang deskriptor file kontainer dan melaporkan statusnya kembali saat containerd aktif kembali.

Alokasi Memori, Disk Node, dan Kebijakan Eviction #

Node memiliki batas resource perangkat keras. Ketika aplikasi kita mengonsumsi memori atau disk hingga mendekati batas fisik node, Kubelet harus mengambil tindakan darurat untuk mencegah OS host crash. Proses ini disebut Node Eviction (Penggusuran Node).

Kubelet memantau batas kritis (eviction thresholds) berikut secara realtime:

• memory.available < 100Mi (RAM tersisa kritis).
• nodefs.available < 10% (Penyimpanan root filesystem kritis).
• imagefs.available < 15% (Penyimpanan khusus folder image Docker kritis).

Urutan Pembersihan Kubelet saat Resource Kritis: #

1. Garbage Collection (GC): Kubelet pertama kali akan mencoba membersihkan data transient: menghapus kontainer yang sudah mati dan menghapus image kontainer lama yang sudah tidak digunakan lagi oleh Pod aktif kluster.
2. Eviction Pod (Penggusuran): Jika GC tidak berhasil membebaskan resource di bawah ambang batas, Kubelet akan mulai mematikan Pod aplikasi secara paksa. Pod akan digusur berdasarkan prioritas kelas QoS (QoS BestEffort digusur pertama, disusul Burstable, dan terakhir Guaranteed).

ANTI-PATTERN: Mengonfigurasi Perangkat Keras Host Node secara Manual
// KITA MELAKUKAN:
- Melakukan SSH ke 20 worker node untuk menginstal utilitas log forwarding (Fluentd), 
  agen monitoring (Prometheus Node Exporter), atau memperbarui konfigurasi kernel host secara manual.
// KONSEKUENSI DI PRODUKSI:
- Drift Konfigurasi: Kondisi OS antar server lambat laun akan berbeda (*drift*), memicu bug 
  anomali yang sangat sulit di-debug.
- Node Baru Tidak Siap: Ketika Autoscaler meluncurkan node VM baru secara otomatis 
  karena traffic naik, node baru tersebut tidak membawa utilitas Fluentd/Prometheus 
  tersebut, merusak pipeline monitoring produksi kita.

✓ SOLUSI YANG BENAR:
- Gunakan manifes **DaemonSet** untuk mendeploy agen logging dan monitoring. DaemonSet menjamin 
  bahwa satu replika kontainer agen tersebut akan secara otomatis berjalan di setiap node 
  (termasuk node baru hasil autoscaling).
- Jika kontainer membutuhkan akses ke kernel host (seperti Node Exporter), aktifkan fitur 
  `privileged: true` dan `hostNetwork: true` pada spesifikasi kontainer di manifes YAML.
- Gunakan script *Cloud-Init* atau tool automasi (seperti Ansible/Terraform) untuk seluruh konfigurasi OS dasar host node.

Ringkasan #

• Otot Pelaksana Kluster — Worker Node bertugas menjalankan kontainer aplikasi riil dan mengelola perutean traffic lokal node.
• Node Lease API — Mengurangi beban API Server dengan mengganti pengiriman data status Node tebal menjadi update Lease Object kecil setiap 10 detik untuk heartbeat.
• Kube-Proxy IPVS Mode — Sangat direkomendasikan untuk produksi karena menawarkan performa pencarian aturan jaringan yang jauh lebih cepat dibanding mode iptables standard.
• Shim & Lifecycle Kontainer — containerd-shim bertindak sebagai penjaga kontainer, memungkinkan update runtime containerd tanpa menyebabkan downtime pada kontainer aplikasi.
• DaemonSet over Manual Config — Selalu gunakan objek DaemonSet untuk menjalankan agen sistem (logging/monitoring) di node produksi daripada menginstalnya secara manual via SSH.

← Sebelumnya: Control Plane   Berikutnya: API Server →