Worker Node #
Worker node adalah mesin tempat aplikasimu benar-benar berjalan. Sementara control plane membuat keputusan, worker node yang mengeksekusi — menjalankan container, mengelola jaringan lokal, dan melaporkan kondisi kembali ke control plane. Memahami komponen di dalam worker node membantu mendiagnosis masalah yang paling sering terjadi di level eksekusi aplikasi.
Komponen di Worker Node #
Setiap worker node menjalankan tiga komponen utama yang bekerja bersama:
Worker Node
┌──────────────────────────────────────────────────────┐
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ kubelet │ │
│ │ (agen utama — menerima instruksi dari │ │
│ │ control plane dan mengeksekusinya) │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────┐ ┌────────────────────────┐ │
│ │ kube-proxy │ │ Container Runtime │ │
│ │ (aturan jaringan)│ │ (menjalankan │ │
│ │ │ │ container) │ │
│ └───────────────────┘ └────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ Pod A Pod B Pod C │ │
│ │ [Container] [Container] [Container] │ │
│ │ [Container] │ │
│ └──────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────┘
Kubelet #
Kubelet adalah agen Kubernetes yang berjalan di setiap worker node. Ia adalah jembatan antara control plane dan runtime environment di node tersebut.
Cara Kubelet Bekerja #
Kubelet melakukan tiga hal utama secara terus-menerus:
1. Watch API Server untuk Pod assignment baru:
Kubelet membuka watch connection ke API Server
│
▼
API Server: "Ada Pod baru yang dijadwalkan ke node kamu"
│
▼
Kubelet membaca PodSpec:
- image apa yang perlu dijalankan?
- berapa resource yang diminta?
- volume apa yang perlu di-mount?
- environment variable apa?
│
▼
Kubelet menginstruksikan container runtime untuk menjalankan Pod
2. Memantau Pod yang berjalan:
Setiap beberapa detik, kubelet:
├── Periksa apakah container masih berjalan
├── Jalankan liveness probe jika dikonfigurasi
├── Jalankan readiness probe jika dikonfigurasi
└── Restart container jika liveness probe gagal
3. Melaporkan status ke API Server:
Setiap ~10 detik (heartbeat), kubelet mengirim ke API Server:
├── Kondisi node (Ready/NotReady, MemoryPressure, DiskPressure)
├── Status setiap Pod di node ini (Running, Failed, Succeeded)
├── Resource yang terpakai (CPU dan memory aktual)
└── Informasi kapasitas node
Jika API Server tidak menerima heartbeat dari sebuah node selama periode tertentu (default: 40 detik), API Server menandai node tersebut sebagai Unknown. Setelah 5 menit, Node Controller mulai memindahkan Pod dari node tersebut ke node yang sehat.
Static Pod #
Ada pengecualian menarik: static Pod. Ini adalah Pod yang dikonfigurasi langsung di kubelet melalui file di direktori tertentu (/etc/kubernetes/manifests/), bukan melalui API Server.
Static Pod: dikelola kubelet langsung, tanpa API Server
/etc/kubernetes/manifests/
├── etcd.yaml ← Etcd dijalankan sebagai static Pod
├── kube-apiserver.yaml ← API Server dijalankan sebagai static Pod
├── kube-scheduler.yaml
└── kube-controller-manager.yaml
Ini adalah cara control plane components dijalankan di banyak cluster — termasuk yang dibuat dengan kubeadm. Keuntungannya: komponen control plane bisa pulih secara otomatis jika crash, karena kubelet yang memantaunya.
kube-proxy #
kube-proxy bertanggung jawab untuk networking di level node — khususnya, memastikan traffic yang menuju sebuah Service diteruskan ke Pod yang tepat.
Cara kube-proxy Bekerja #
Ketika sebuah Service dibuat di Kubernetes, kube-proxy menambahkan aturan jaringan di setiap node untuk menangani traffic ke Service tersebut.
Service "payment-api" dibuat:
ClusterIP: 10.96.45.12
Port: 80
Selector: { app: payment }
Pod yang cocok:
Pod A: 192.168.1.10:8080
Pod B: 192.168.1.15:8080
Pod C: 192.168.1.22:8080
kube-proxy menulis aturan iptables di setiap node:
Traffic ke 10.96.45.12:80
→ randomly forward ke salah satu dari:
192.168.1.10:8080 (Pod A)
192.168.1.15:8080 (Pod B)
192.168.1.22:8080 (Pod C)
Ketika Pod baru ditambahkan atau Pod lama dihapus, kube-proxy memperbarui aturan di semua node secara otomatis.
Mode kube-proxy #
kube-proxy mendukung beberapa mode implementasi:
Mode iptables (default di kebanyakan cluster):
✓ Mature dan stabil
✓ Random load balancing
✗ Performa turun saat jumlah Service sangat banyak (ribuan)
✗ Rule update tidak atomik
Mode ipvs:
✓ Performa lebih baik untuk cluster besar
✓ Lebih banyak algoritma load balancing
✓ Rule update lebih efisien
✗ Butuh kernel module tambahan
✗ Kurang umum, debugging lebih kompleks
Untuk cluster dengan ratusan Service atau lebih, mode ipvs sangat direkomendasikan.
Container Runtime #
Container runtime adalah software yang benar-benar membuat dan menjalankan container. Kubernetes tidak peduli runtime apa yang digunakan — selama ia mengimplementasikan Container Runtime Interface (CRI).
CRI: Standar yang Memisahkan Kubernetes dari Runtime #
CRI adalah antarmuka gRPC yang mendefinisikan operasi-operasi yang bisa dilakukan Kubernetes ke runtime:
Operasi CRI yang digunakan kubelet:
RunPodSandbox → buat Pod network namespace
CreateContainer → buat container (belum dijalankan)
StartContainer → mulai menjalankan container
StopContainer → hentikan container
RemoveContainer → hapus container
ListContainers → daftar semua container yang berjalan
ContainerStatus → status container tertentu
ExecSync → jalankan perintah di dalam container
Runtime yang Didukung #
containerd — runtime yang paling umum di produksi modern. Ringan, fokus pada menjalankan container, dan merupakan bagian dari proyek Docker yang dipisahkan untuk digunakan langsung oleh Kubernetes.
Lapisan sebelum Kubernetes 1.24:
Kubernetes → dockershim → Docker → containerd → container
Lapisan setelah Kubernetes 1.24 (dockershim dihapus):
Kubernetes → containerd → container
→ Lebih simpel, lebih efisien
CRI-O — runtime yang didesain khusus untuk Kubernetes, sangat minimalis. Digunakan sebagai default di OpenShift (Red Hat Kubernetes distribution).
kata-containers — runtime yang menjalankan container di dalam VM ringan untuk isolasi yang lebih kuat. Digunakan untuk workload yang membutuhkan keamanan tinggi.
Bagaimana Worker Node Berinteraksi dengan Control Plane #
Semua komunikasi dari worker node ke control plane dilakukan melalui API Server, menggunakan TLS mutual authentication.
Arah komunikasi:
Kubelet → API Server:
├── Watch untuk Pod yang dijadwalkan ke node ini
├── Kirim heartbeat dan status node
└── Update status Pod (Running, Failed, dll)
API Server → Kubelet:
├── Eksekusi perintah kubectl exec
├── Streaming log kubectl logs
└── Port forwarding kubectl port-forward
kube-proxy → API Server:
└── Watch untuk perubahan Service dan Endpoint
Penting diperhatikan: API Server hanya memanggil kubelet untuk operasi interaktif seperti exec dan logs. Untuk operasi normal (scheduling, status update), kubelet yang aktif menghubungi API Server. Ini desain yang memudahkan worker node di belakang firewall.
Ringkasan #
- Kubelet adalah agen utama — ia watch API Server untuk instruksi baru, mengeksekusi Pod via container runtime, memantau kondisi, dan melaporkan status setiap ~10 detik.
- Static Pod untuk bootstrap control plane — komponen control plane seperti API Server dan etcd berjalan sebagai static Pod yang dikelola kubelet langsung, bukan melalui API.
- kube-proxy mengelola routing lokal — ia menulis aturan iptables/ipvs di setiap node agar traffic ke Service diteruskan ke Pod yang tepat.
- CRI memisahkan Kubernetes dari runtime — Kubernetes berkomunikasi via CRI gRPC interface; runtime bisa containerd, CRI-O, atau lainnya tanpa mengubah Kubernetes.
- dockershim sudah dihapus sejak 1.24 — Kubernetes tidak lagi mendukung Docker secara langsung; gunakan containerd atau CRI-O di cluster modern.
- Heartbeat 40 detik — jika API Server tidak menerima heartbeat selama 40 detik, node ditandai Unknown; setelah 5 menit Pod di-evict ke node lain.