Control Plane #

Control Plane adalah pusat kendali kluster Kubernetes. Bertindak sebagai “otak”, Control Plane bertanggung jawab untuk membuat keputusan arsitektural global (seperti penjadwalan kontainer), memproses request dari pengguna, serta terus memantau dan memulihkan kondisi kesehatan seluruh kluster.

Bagi tim DevOps dan Platform Engineer, menguasai arsitektur internal Control Plane serta cara mengonfigurasinya untuk kebutuhan High Availability (HA) adalah syarat mutlak untuk membangun platform cloud-native berskala enterprise yang tangguh terhadap bencana infrastruktur.

Komponen-Komponen Otak Kluster #

Control Plane tidak berdiri sebagai satu software utuh, melainkan berjalan sebagai beberapa proses (daemon) independen yang berkolaborasi secara erat:

kube-apiserver: Komponen gerbang depan yang melayani seluruh permintaan API Kubernetes (baik internal maupun eksternal).
kube-controller-manager: Agen pengawas kluster yang menjalankan puluhan loop kontrol (controllers) secara simultan untuk menyelaraskan actual state dengan desired state.
kube-scheduler: Komponen penjadwal cerdas yang bertugas menempatkan Pod baru pada node yang memiliki sisa kapasitas memadai.
etcd: Database konsistensi terdistribusi yang menyimpan seluruh data status objek kluster.

Pola Komunikasi Sentral: Keunggulan API-Centric #

Salah satu prinsip desain paling penting dari Control Plane Kubernetes adalah Pola Komunikasi API-Centric. Semua komunikasi di dalam kluster, tanpa kecuali, harus melalui API Server.

Pola Aliran Komunikasi Control Plane:

flowchart LR
    ETCD["etcd"] <-->|"gRPC"| APIServer["kube-apiserver"]
    APIServer <-->|"HTTP/2"| Scheduler["kube-scheduler"]
    APIServer <-->|"HTTP/2"| ControllerManager["kube-controller-manager"]

Pola ini memiliki implikasi yang sangat penting:

etcd Terisolasi: Database etcd tidak pernah diakses secara langsung oleh Scheduler, Controller Manager, ataupun Kubelet di worker node. Hanya kube-apiserver yang memiliki otoritas untuk membaca dan menulis data ke etcd. Hal ini mengamankan database dari kerusakan data akibat akses paralel yang tidak tervalidasi.
Validasi Tunggal: Karena semua request harus melewati kube-apiserver, proses autentikasi (siapa pengirimnya), otorisasi (apakah ia berhak), dan validasi skema YAML hanya perlu dilakukan di satu tempat secara konsisten.
Loose Coupling: Komponen-komponen Control Plane tidak perlu saling mengetahui lokasi jaringan IP satu sama lain. Mereka hanya perlu mengetahui alamat URL dari API Server.

High Availability (HA) Control Plane di Produksi #

Untuk kluster tingkat produksi, menggunakan satu Control Plane tunggal sangatlah berbahaya. Jika server tersebut mati (mengalami kegagalan disk, jaringan, atau crash OS), kluster akan lumpuh: kita tidak bisa mendeploy aplikasi baru, memicu autoscaling, atau memulihkan kontainer yang crash.

Untuk mendesain kluster HA yang andal, kita harus mendistribusikan Control Plane ke minimal 3 mesin server terpisah di belakang load balancer eksternal. Namun, karena karakteristik internal komponen Control Plane berbeda-beda, Kubernetes menerapkan dua strategi replikasi yang berbeda:

1. Stateless Active-Active (kube-apiserver) #

Komponen kube-apiserver bersifat stateless (tidak menyimpan status lokal). Semua data disimpan ke etcd. Oleh karena itu, kita dapat menjalankan banyak instansi API Server secara aktif bersamaan (Active-Active). Load Balancer eksternal (seperti HAProxy atau AWS ALB) akan mendistribusikan traffic dari kubectl dan kubelet secara merata ke seluruh instance API Server yang aktif.

2. State-Sensitive Active-Passive dengan Leader Election #

Komponen kube-scheduler dan kube-controller-manager bersifat sensitif terhadap status kluster (state-sensitive). Jika dua Scheduler berjalan aktif bersamaan dan mendeteksi Pod baru yang sama, mereka dapat memutuskan untuk menempatkan Pod tersebut ke dua node berbeda secara bersamaan, memicu konflik status kluster.

Untuk mencegah konflik ini, Kubernetes menggunakan mekanisme Leader Election (Pemilihan Pemimpin) bertipe Active-Passive:

Seluruh instansi Scheduler dan Controller Manager (misal: 3 instansi di 3 node control plane) akan berjalan.
Mereka akan memperebutkan hak sewa kunci (Lease lock) pada API Server menggunakan objek API Leases.
Instansi yang berhasil mengunci objek Lease pertama kali akan ditunjuk sebagai Leader (Aktif) dan bertugas mengeksekusi logika orkestrasi. Instansi lainnya akan masuk status Standby (Pasif).
Leader harus terus memperbarui kunci sewa secara berkala (misal: setiap 2 detik).
Jika Leader mati mendadak dan gagal memperbarui sewa, instansi Standby akan mendeteksi hilangnya sewa dan memperebutkan kunci kembali untuk menunjuk Leader baru secara otomatis.

3. Konsensus Kuorum etcd #

Database etcd menggunakan algoritma konsensus Raft untuk mereplikasi data ke seluruh node. Raft mensyaratkan kluster harus mencapai Kuorum (mayoritas suara) untuk menyetujui setiap penulisan data baru. Rumus kuorum Raft adalah:

$$\text{Quorum} = \left\lfloor \frac{N}{2} \right\rfloor + 1$$

Di mana $N$ adalah jumlah total node etcd di dalam kluster.

ANTI-PATTERN: Jumlah Node Control Plane Produksi Genap (2 atau 4)
// KITA MELAKUKAN:
- Menyewa 2 server Control Plane (etcd) demi menghemat anggaran bulanan kluster produksi.
// KONSEKUENSI DI PRODUKSI:
- Berdasarkan rumus kuorum etcd:
  - Total Node (N) = 2.
  - Kuorum = floor(2/2) + 1 = 2 Node.
- Jika salah satu node control plane mati, jumlah node yang hidup tersisa 1.
- Karena 1 < kuorum (2), kluster etcd langsung terkunci ke mode read-only dan menolak semua 
  penulisan data baru (Split-Brain Protection).
- Kita kehilangan toleransi kegagalan (*fault tolerance*) kluster sepenuhnya. Menyewa 2 node 
  memiliki ketahanan yang lebih buruk daripada 1 node tunggal, namun dengan biaya ganda.

✓ SOLUSI YANG BENAR:
- Selalu gunakan jumlah node ganjil untuk Control Plane/etcd: minimal 3 node untuk kluster produksi standard, atau 5 node untuk kluster produksi skala besar.
  - Kluster 3 Node: Kuorum = 2. Toleransi Kegagalan = 1 Node mati.
  - Kluster 5 Node: Kuorum = 3. Toleransi Kegagalan = 2 Node mati.
- Ini menjamin konsensus Raft dapat dicapai secara matematis saat terjadi bencana jaringan fisik.

Ringkasan #

Otak Kluster Modular — Control Plane tersusun atas API Server (gerbang), etcd (data), Scheduler (pensejadwal), dan Controller Manager (penjaga status kluster).

API-Centric Communication — Menjamin isolasi etcd dari luar dan memastikan validasi skema serta autentikasi/otorisasi dilakukan secara konsisten di satu pintu.

Active-Active vs Active-Passive — API Server direplikasi secara Active-Active di belakang load balancer, sedangkan Scheduler & Controller Manager direplikasi secara Active-Passive menggunakan mekanisme Leader Election via Lease API.

Kuorum Ganjil etcd — etcd membutuhkan mayoritas suara (kuorum) berdasarkan konsensus Raft. Selalu jalankan 3 atau 5 node control plane di produksi (jangan gunakan 2 atau 4 node).

← Sebelumnya: Overview Berikutnya: Worker Node →