Control Plane #

Control plane adalah bagian cluster yang membuat semua keputusan — di mana Pod dijalankan, apa yang perlu diperbaiki, bagaimana state yang diinginkan dicapai dan dipertahankan. Memahami cara kerja control plane secara mendalam membantumu mendiagnosis masalah cluster, merancang HA setup yang benar, dan mengerti mengapa Kubernetes berperilaku seperti yang kamu amati.

Komponen Control Plane #

Control plane terdiri dari empat komponen utama yang berjalan — umumnya — di satu atau lebih node khusus yang tidak menjalankan workload aplikasi.

Control Plane Node

┌─────────────────────────────────────────────────────┐
│                                                     │
│  ┌───────────────────────────────────────────────┐  │
│  │               kube-apiserver                  │  │
│  │  (satu-satunya komponen yang berbicara ke     │  │
│  │   etcd dan diakses oleh semua komponen lain)  │  │
│  └───────────────────┬───────────────────────────┘  │
│                      │                              │
│         ┌────────────┼────────────┐                 │
│         ▼            ▼            ▼                 │
│  ┌───────────┐ ┌──────────┐ ┌──────────┐            │
│  │   etcd    │ │scheduler │ │controller│            │
│  │           │ │          │ │ manager  │            │
│  └───────────┘ └──────────┘ └──────────┘            │
│                                                     │
└─────────────────────────────────────────────────────┘

API Server #

API Server adalah komponen paling sentral di seluruh cluster. Tidak ada komponen lain yang berkomunikasi langsung satu sama lain — semuanya melewati API Server. Ini bukan hanya keputusan arsitektur, ini adalah desain keamanan dan auditabilitas.

Setiap request ke API Server melewati tiga tahap sebelum diproses:

Request masuk
     │
     ▼
┌─── Autentikasi ──────────────────────────────────────┐
│  Siapa yang mengirim request ini?                    │
│  → Verifikasi certificate, token, atau username/pass │
│  → Jika tidak dikenal: 401 Unauthorized              │
└──────────────────────────────────────────────────────┘
     │
     ▼
┌─── Otorisasi ────────────────────────────────────────┐
│  Apakah mereka punya izin untuk operasi ini?         │
│  → Cek RBAC rules                                    │
│  → Jika tidak punya izin: 403 Forbidden              │
└──────────────────────────────────────────────────────┘
     │
     ▼
┌─── Admission Control ────────────────────────────────┐
│  Apakah request ini sesuai dengan kebijakan cluster? │
│  → Validasi schema resource                          │
│  → Jalankan admission webhooks (custom policy)       │
│  → Mutasi resource jika perlu (inject sidecar, dll)  │
└──────────────────────────────────────────────────────┘
     │
     ▼
  Simpan ke Etcd → Kirim respons

Admission Controllers adalah mekanisme yang sering digunakan untuk kebijakan cluster: memastikan semua container punya resource limits, otomatis menambahkan label tertentu, atau memvalidasi naming convention. Ini berjalan sebagai webhook yang dipanggil API Server sebelum resource disimpan.

Etcd #

Etcd adalah database key-value terdistribusi yang menjadi sumber kebenaran tunggal untuk seluruh state cluster. Setiap object Kubernetes — Pod, Deployment, Service, ConfigMap, bahkan event — disimpan di sini.

Apa yang disimpan di Etcd:

/registry/pods/default/api-server-abc123
/registry/deployments/production/payment-api
/registry/services/kube-system/kubernetes
/registry/configmaps/default/app-config
/registry/secrets/default/db-credentials
... dan seterusnya untuk setiap resource

Etcd menggunakan protokol Raft untuk konsensus terdistribusi. Ketika ada lebih dari satu node Etcd (setup HA), write dianggap berhasil hanya jika majority nodes mengakui operasi tersebut.

Etcd cluster dengan 3 node:

  Node 1 (leader) ─── tulis ke Node 2 ──► OK
                  └── tulis ke Node 3 ──► OK
  → 2 dari 3 node setuju → commit berhasil

  Jika Node 2 mati:
  Node 1 (leader) ─── tulis ke Node 3 ──► OK
  → 1 dari 2 node yang hidup setuju → commit berhasil
  (majority dari 3 = 2, 2 node masih bisa commit)

  Jika Node 2 DAN Node 3 mati:
  Node 1 tidak bisa mencapai majority → cluster freeze
  → Tidak ada write yang bisa dilakukan → cluster read-only

Ini menjelaskan mengapa Etcd cluster selalu menggunakan jumlah node ganjil (3, 5, 7) — untuk memaksimalkan toleransi kegagalan dengan quorum yang benar.

Etcd adalah satu-satunya tempat di mana seluruh state cluster disimpan. Backup Etcd secara reguler adalah kewajiban absolut untuk cluster produksi. Kehilangan Etcd tanpa backup berarti kehilangan seluruh konfigurasi cluster — semua Deployment, Service, Secret, dan konfigurasi lainnya harus direkonstruksi dari nol.

Scheduler #

Scheduler bertanggung jawab untuk satu keputusan: Pod ini harus berjalan di node mana?

Proses scheduling lebih kompleks dari sekadar “pilih node yang paling kosong”. Scheduler melewati dua fase untuk setiap Pod yang belum terjadwal:

Fase 1 — Filtering (mengeliminasi node yang tidak memenuhi syarat):

  Semua node dalam cluster
        │
        ├── Filter: cukup CPU dan memory? (resource fit)
        ├── Filter: node dalam kondisi Ready?
        ├── Filter: Pod punya nodeSelector? (node harus punya label yang cocok)
        ├── Filter: ada taint di node yang tidak ditoleransi Pod?
        └── Filter: ada affinity/anti-affinity rule?
        │
        ▼
  Node-node yang lolos filter (feasible nodes)

Fase 2 — Scoring (memilih node terbaik dari yang lolos):

  Feasible nodes
        │
        ├── Score: node dengan resource paling banyak tersisa
        ├── Score: node yang paling sedikit menjalankan Pod dari image yang sama
        ├── Score: node yang Pod-nya paling tersebar (anti-affinity preferensi)
        └── Score: custom plugin score (jika ada)
        │
        ▼
  Node dengan score tertinggi → Pod dijadwalkan ke sini

Jika tidak ada node yang lolos fase filtering, Pod akan tetap di status Pending sampai ada node yang memenuhi syarat — misalnya ada node baru yang ditambahkan ke cluster atau ada Pod lain yang dihapus dan membebaskan resource.

Controller Manager #

Controller Manager adalah satu proses yang menjalankan banyak controller secara paralel. Setiap controller adalah sebuah control loop yang terus-menerus bekerja: amati state saat ini, bandingkan dengan desired state, ambil tindakan jika ada perbedaan.

Pola control loop (sama untuk semua controller):

while true:
    current_state  = baca dari API Server
    desired_state  = baca dari spec resource
    if current_state != desired_state:
        ambil tindakan untuk mendekati desired_state
    tunggu notifikasi perubahan dari API Server

Beberapa controller penting yang berjalan di Controller Manager:

Deployment Controller — memastikan jumlah replica Pod sesuai dengan yang dideklarasikan di Deployment. Jika ada Pod yang mati, controller ini yang membuat Pod pengganti.

ReplicaSet Controller — mirip Deployment Controller tapi bekerja di level ReplicaSet. Deployment Controller sebenarnya bekerja dengan cara membuat dan mengelola ReplicaSet.

Node Controller — memantau kondisi node. Jika sebuah node berhenti mengirim heartbeat, Node Controller yang menandainya sebagai NotReady dan akhirnya memindahkan Pod ke node lain.

Job Controller — memastikan Job yang sudah selesai tidak di-restart, dan Job yang gagal di-retry sesuai konfigurasi.

Endpoint Controller — memperbarui daftar IP Pod di belakang setiap Service saat Pod dibuat, dihapus, atau kondisinya berubah.

High Availability Control Plane #

Untuk produksi dengan SLA tinggi, control plane perlu dijalankan dalam konfigurasi HA — artinya setiap komponen control plane berjalan di lebih dari satu node.

HA Control Plane Setup (3 node):

  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
  │ Control Plane│  │ Control Plane│  │ Control Plane│
  │   Node 1     │  │   Node 2     │  │   Node 3     │
  │              │  │              │  │              │
  │ apiserver ◄──┼──┼── apiserver  │  │  apiserver   │
  │ scheduler    │  │  scheduler   │  │  scheduler   │
  │ controller   │  │  controller  │  │  controller  │
  │ etcd         │  │  etcd        │  │  etcd        │
  └──────────────┘  └──────────────┘  └──────────────┘
         │                 │                 │
         └─────────────────┴─────────────────┘
                      Load Balancer
                           │
                    kubectl / kubelet

Beberapa detail penting dalam HA setup:

API Server bisa berjalan aktif di semua node secara bersamaan (active-active). Load balancer mendistribusikan request ke semua API Server yang sehat.
Scheduler dan Controller Manager hanya satu instance yang aktif pada satu waktu (active-passive). Mereka menggunakan leader election via Etcd untuk menentukan siapa yang aktif. Jika leader mati, node lain mengambil alih dalam hitungan detik.
Etcd berjalan sebagai cluster terdistribusi dengan Raft consensus di semua node.

Ringkasan #

API Server adalah gatekeeper — semua request melewati autentikasi, otorisasi, dan admission control sebelum diproses; tidak ada jalan pintas.
Etcd adalah sumber kebenaran tunggal — backup reguler adalah kewajiban absolut; kehilangan Etcd tanpa backup berarti kehilangan seluruh state cluster.
Scheduler bekerja dalam dua fase — filtering mengeliminasi node yang tidak memenuhi syarat, scoring memilih yang terbaik dari yang lolos.
Controller Manager menjalankan banyak control loop — setiap controller mengamati satu aspek cluster dan memastikan desired state selalu terpenuhi.
HA control plane butuh setup khusus — API Server bisa active-active, Scheduler dan Controller Manager active-passive via leader election.
Jumlah Etcd node selalu ganjil — 3, 5, atau 7 node untuk memaksimalkan toleransi kegagalan dengan quorum Raft yang benar.

← Sebelumnya: Overview Berikutnya: Worker Node →