Cluster #

Cluster adalah unit fundamental Kubernetes — sekumpulan mesin yang bekerja bersama sebagai satu sistem terpadu. Saat kamu “menggunakan Kubernetes”, artinya kamu sedang bekerja di dalam sebuah cluster. Memahami apa yang menyusun sebuah cluster dan bagaimana bagian-bagiannya berinteraksi adalah fondasi untuk memahami semua konsep Kubernetes lainnya.

Apa Itu Cluster? #

Sebuah cluster Kubernetes terdiri dari satu atau lebih mesin yang dikelompokkan menjadi dua peran berbeda: Control Plane dan Worker Node.

Anatomi Cluster Kubernetes

┌─────────────────────────────────────────────────────┐
│                   Kubernetes Cluster                │
│                                                     │
│  ┌─────────────────────┐   ┌─────────────────────┐  │
│  │    Control Plane    │   │    Worker Node 1    │  │
│  │                     │   │                     │  │
│  │  ┌───────────────┐  │   │  ┌───────────────┐  │  │
│  │  │  API Server   │  │   │  │     Pod A     │  │  │
│  │  ├───────────────┤  │   │  ├───────────────┤  │  │
│  │  │   Scheduler   │  │   │  │     Pod B     │  │  │
│  │  ├───────────────┤  │   │  └───────────────┘  │  │
│  │  │  Controller   │  │   └─────────────────────┘  │
│  │  │   Manager     │  │                            │
│  │  ├───────────────┤  │   ┌─────────────────────┐  │
│  │  │     Etcd      │  │   │    Worker Node 2    │  │
│  │  └───────────────┘  │   │                     │  │
│  └─────────────────────┘   │  ┌───────────────┐  │  │
│                            │  │     Pod C     │  │  │
│                            │  └───────────────┘  │  │
│                            └─────────────────────┘  │
└─────────────────────────────────────────────────────┘

Control Plane adalah otak cluster. Ia menerima perintah dari pengguna (melalui kubectl atau API langsung), membuat keputusan scheduling, memantau kondisi cluster, dan mengambil tindakan korektif jika ada yang tidak sesuai dengan desired state.

Worker Node adalah otot cluster. Mesin-mesin inilah yang benar-benar menjalankan aplikasi dalam bentuk Pod. Setiap worker node menjalankan komponen kecil bernama kubelet yang berkomunikasi dengan control plane dan mengeksekusi instruksinya.

Cara Cluster Bekerja #

Interaksi dalam cluster mengikuti pola yang konsisten: semua komunikasi dilakukan melalui API Server di control plane. Tidak ada komponen yang berbicara langsung satu sama lain — semuanya melewati API Server.

Alur ketika kamu mendeploy aplikasi:

kubectl apply -f deployment.yaml
        │
        ▼
   API Server (control plane)
        │
        ├─ Validasi manifest
        ├─ Simpan ke Etcd
        │
        ▼
   Scheduler (control plane)
        │
        ├─ Lihat resource tersedia di setiap node
        ├─ Pilih node terbaik
        │
        ▼
   Kubelet (di worker node terpilih)
        │
        ├─ Terima instruksi dari API Server
        ├─ Pull container image
        └─ Jalankan container

Pola ini memiliki implikasi penting: control plane tidak perlu terhubung langsung ke worker node untuk menjalankan perintah. Worker node yang secara aktif polling ke API Server untuk mendapat instruksi terbaru. Ini membuat cluster lebih tangguh terhadap kegagalan koneksi sementara.

Single-Node vs Multi-Node Cluster #

Tidak semua cluster perlu berjalan di banyak mesin. Ada beberapa konfigurasi yang umum digunakan sesuai kebutuhan:

Single-node cluster — control plane dan worker node berjalan di mesin yang sama. Ini cocok untuk development dan belajar. Minikube dan Kind adalah tools populer untuk membuat single-node cluster di laptop.

Multi-node cluster — konfigurasi produksi yang umum. Control plane berjalan di mesin terpisah dari worker node, sehingga kegagalan di aplikasi tidak mempengaruhi control plane.

High-availability cluster — control plane dijalankan di beberapa mesin (biasanya 3 atau 5) untuk eliminasi single point of failure. Etcd juga direplikasi. Ini konfigurasi yang direkomendasikan untuk produksi kritikal.

Kapan butuh konfigurasi apa:

Single-node:
  ✓ Development lokal
  ✓ Belajar Kubernetes
  ✓ CI/CD pipeline testing

Multi-node (control plane tunggal):
  ✓ Environment staging
  ✓ Produksi non-kritikal
  ✓ Tim kecil dengan toleransi downtime terbatas

Multi-node High Availability (3+ control plane):
  ✓ Produksi kritikal dengan SLA tinggi
  ✓ Tidak bisa toleransi downtime control plane
  ✓ Cluster besar dengan ratusan node

Cluster Context dan Kubeconfig #

Dalam praktik, seorang engineer sering bekerja dengan lebih dari satu cluster — misalnya cluster development, staging, dan production. Kubernetes mengelola ini melalui file kubeconfig yang biasanya berada di ~/.kube/config.

Setiap cluster terdaftar sebagai context dalam kubeconfig. Kamu bisa berpindah antar cluster dengan mengganti context aktif:

# Lihat semua context yang tersedia
kubectl config get-contexts

# Pindah ke cluster production
kubectl config use-context production-cluster

# Lihat cluster mana yang sedang aktif
kubectl config current-context

Pastikan selalu memeriksa context aktif sebelum menjalankan perintah yang bersifat destruktif seperti kubectl delete atau perubahan konfigurasi besar. Menghapus resource di cluster production karena lupa ganti context adalah kesalahan yang sangat umum terjadi.

Namespace dalam Cluster #

Satu cluster bisa dibagi menjadi beberapa namespace — partisi logis yang memisahkan resource. Ini berguna untuk memisahkan environment (dev/staging/prod dalam satu cluster), atau memisahkan tim yang berbeda.

# Lihat semua namespace
kubectl get namespaces

# Jalankan perintah di namespace tertentu
kubectl get pods --namespace=production

# Set namespace default untuk sesi ini
kubectl config set-context --current --namespace=staging

Namespace memberikan isolasi nama resource (dua Deployment bernama “api” bisa ada di namespace yang berbeda) tapi tidak memberikan isolasi jaringan atau resource secara default — itu butuh konfigurasi tambahan via NetworkPolicy dan ResourceQuota.

Ringkasan #

Cluster = control plane + worker nodes — dua peran berbeda dalam satu sistem terpadu; control plane membuat keputusan, worker node mengeksekusi.
Semua komunikasi melalui API Server — tidak ada komponen yang berbicara langsung satu sama lain; pola ini membuat cluster lebih tangguh dan auditabel.
Worker node polling ke API Server — bukan control plane yang push perintah; implikasinya adalah koneksi terputus sementara tidak langsung menyebabkan kekacauan.
Konfigurasi cluster bergantung kebutuhan — single-node untuk development, multi-node untuk produksi, HA cluster untuk produksi kritikal.
Kubeconfig mengelola banyak cluster — selalu periksa context aktif sebelum menjalankan perintah destruktif.
Namespace membagi cluster secara logis — untuk isolasi nama dan quota resource, tapi bukan isolasi jaringan secara default.

← Sebelumnya: Kapan Dibutuhkan? Berikutnya: Node →