API Server #

API Server (kube-apiserver) adalah gerbang utama kluster Kubernetes. Bertindak sebagai resepsionis sekaligus penjaga keamanan kluster, API Server adalah satu-satunya komponen yang mengekspos API kontrol kluster ke dunia luar. Tidak ada perubahan status kluster (state change) yang dapat terjadi tanpa melalui persetujuan dan pemrosesan dari API Server.

Bagi tim DevOps dan pengembang, memahami alur pemrosesan internal API Server sangatlah penting untuk melacak masalah perizinan (RBAC), mendesain integrasi webhook kebijakan keamanan, serta mengoptimalkan performa interaksi aplikasi dengan kluster.

Pipeline Pemrosesan Request API Server #

Setiap kali kita mengirimkan sebuah perintah (misalnya kubectl apply -f deployment.yaml atau saat Kubelet melaporkan status kesehatannya), request tersebut harus melewati rangkaian pemeriksaan ketat di dalam API Server sebelum akhirnya disimpan ke dalam database etcd.

Berikut adalah visualisasi alur pipa (pipeline) pemrosesan request di dalam API Server:

flowchart TD
    Req["Request Masuk (HTTP POST/PUT/DELETE)"] --> AuthN{"1. Authentication\n(Siapa Pengirimnya?)"}
    
    AuthN -- Gagal (401 Unauthorized) --> Terminate["Hentikan Request & Kembalikan Error"]
    AuthN -- Sukses --> AuthZ{"2. Authorization\n(Apakah Berhak?)"}
    
    AuthZ -- Gagal (403 Forbidden) --> Terminate
    AuthZ -- Sukses --> Mutating{"3. Mutating Admission\n(Ubah/Lengkapi Objek)"}
    
    Mutating --> SchemaVal{"4. Schema Validation\n(Apakah Struktur YAML Valid?)"}
    
    SchemaVal -- Gagal (422 Unprocessable) --> Terminate
    SchemaVal -- Sukses --> Validating{"5. Validating Admission\n(Apakah Boleh Dibuat?)"}
    
    Validating -- Gagal (403 Forbidden) --> Terminate
    Validating -- Sukses --> EtcdWrite["6. etcd Write\n(Simpan Permanen ke DB)"]
    
    EtcdWrite --> Response["Kirim HTTP 201 Created ke Client"]

    style AuthN stroke:#2980b9,stroke-width:2px
    style AuthZ stroke:#f39c12,stroke-width:2px
    style Mutating stroke:#8e44ad,stroke-width:2px
    style SchemaVal stroke:#7f8c8d,stroke-width:2px
    style Validating stroke:#d35400,stroke-width:2px
    style EtcdWrite stroke:#27ae60,stroke-width:2px

Penjelasan Tahapan Pipeline: #

1. Authentication (Autentikasi - Siapa Pengirimnya?) #

API Server memeriksa identitas pengirim request menggunakan sertifikat TLS klien, token HTTP Bearer, atau otentikasi eksternal (seperti OpenID Connect). Jika identitas tidak valid, request langsung ditolak dengan kode status HTTP 401 Unauthorized.

2. Authorization (Otorisasi - Apakah Berhak?) #

Setelah identitas dikenali, API Server memeriksa apakah pengguna tersebut memiliki izin untuk melakukan tindakan yang diminta pada objek target (misal: “apakah user John diizinkan menghapus Pod di namespace production?”). Evaluasi ini diselesaikan melalui kebijakan RBAC (Role-Based Access Control). Kegagalan pada tahap ini menghasilkan status HTTP 403 Forbidden.

3. Mutating Admission Webhooks (Modifikasi Objek) #

Tahapan webhook di mana API Server mengirimkan manifes ke sistem eksternal untuk dilengkapi. Mutating webhook dapat mengubah isi manifes secara dinamis — misalnya, secara otomatis menyisipkan kontainer sidecar Fluentd ke dalam Pod, atau menambahkan environment variables default ke dalam kontainer.

4. Schema Validation (Validasi Skema) #

API Server memverifikasi apakah struktur data manifest YAML/JSON yang dikirimkan mematuhi spesifikasi resmi Kubernetes (misal: memeriksa apakah tidak ada typo penulisan nama field di dalam YAML).

5. Validating Admission Webhooks (Validasi Kebijakan) #

Berbeda dengan mutating webhook yang bertugas melengkapi, Validating Webhook bertugas menolak request jika melanggar kebijakan organisasi kluster (misalnya: menolak pembuatan Pod jika image kontainer tidak berasal dari registri internal perusahaan, atau menolak kontainer yang mencoba berjalan sebagai root).

6. etcd Write (Penyimpanan Permanen) #

Setelah lolos dari seluruh tahapan pemeriksaan di atas, API Server akhirnya mendekripsi data (jika berupa objek Secret) dan menuliskan objek tersebut secara permanen ke database etcd. Hanya pada tahap inilah status kluster dianggap resmi berubah.

Mekanisme Watch API Server: Efisiensi gRPC/HTTP2 Streaming #

Kubernetes sangat bergantung pada kecepatan propagasi informasi. Ketika ada status baru di etcd (misal: Pod harus dijalankan di Node-2), Scheduler dan Kubelet di Node-2 harus segera mengetahuinya dalam milidetik.

Jika komponen menggunakan polling (bertanya terus-menerus), database kluster akan kolaps karena kebanjiran beban. Untuk itu, API Server menggunakan fitur Watch API.

Mekanisme Watch bekerja dengan cara memanfaatkan protokol HTTP/2 (atau WebSockets) yang mendukung koneksi streaming dua arah yang bertahan lama (persistent connection).

• Kubelet membuka satu koneksi Watch ke API Server dan menyatakan: “Beri tahu saya jika ada perubahan Pod baru yang ditugaskan ke node saya”.
• API Server akan membiarkan koneksi tersebut tetap terbuka.
• Begitu Scheduler menulis penugasan node Pod ke etcd, API Server mendeteksi perubahan tersebut dan langsung mengirimkan event pembaruan sebagai satu aliran paket data kecil (stream) melalui koneksi persistent yang sedang terbuka ke Kubelet secara real-time.

Admission Controllers di Produksi: Enforcing Policy #

Admission Controllers adalah plugin yang berjalan di dalam proses API Server untuk membatasi dan melengkapi resource kluster. Di kluster produksi modern, kita sering menggunakan mesin kebijakan eksternal (External Policy Engines) seperti OPA Gatekeeper atau Kyverno yang diintegrasikan melalui Validating Admission Webhooks.

Contoh penggunaan Admission Controller di tingkat produksi:

• Mencegah deployment aplikasi yang tidak mendefinisikan resources.requests dan limits guna menghindari kehabisan kapasitas node.
• Memastikan setiap Pod memiliki label team dan environment wajib untuk keperluan audit.
• Secara otomatis menambahkan sertifikat TLS ke dalam Ingress menggunakan cert-manager mutating webhook.

ANTI-PATTERN: Bypass API Server untuk Mengubah etcd secara Langsung
// KITA MELAKUKAN:
- Menghubungkan utilitas `etcdctl` langsung ke database etcd kluster untuk mengedit 
  atau menghapus entri objek Kubernetes secara paksa demi menyelesaikan masalah Pod yang macet.
// KONSEKUENSI DI PRODUKSI:
- Rusaknya Validasi Skema: Kita melewati seluruh pipa validasi API Server. Jika kita salah menulis 
  entri, etcd akan menyimpan data corrupt yang memicu crash pada proses kube-apiserver saat booting.
- inkonsistensi Kluster: Controller Manager tidak mendapatkan notifikasi watch event, 
  membuat reconciliaton loop mengalami disorientasi state kluster.
- Risiko Kehilangan Data Total: Manipulasi etcd secara manual tanpa kontrol API Server dapat merusak kuorum Raft.

✓ SOLUSI YANG BENAR:
- Selalu interaksikan kluster melalui API Server menggunakan perintah `kubectl` atau API resmi.
- Jika ada objek yang stuck dan tidak bisa dihapus (misal karena finalizer), gunakan patch API resmi untuk membersihkannya:
  `kubectl patch pod <nama-pod> -p '{"metadata":{"finalizers":null}}'`
- Biarkan API Server yang mengelola seluruh penulisan database etcd secara aman dan terkontrol.

Ringkasan #

• Resepsionis Sentral Kluster — API Server adalah gerbang utama; semua komponen internal dan external tools wajib berkomunikasi melalui API Server.
• Pipeline Validasi Ketat — Setiap request harus melewati tahapan Autentikasi ➔ Otorisasi (RBAC) ➔ Mutating Webhook ➔ Schema Validation ➔ Validating Webhook sebelum ditulis ke etcd.
• Watch via HTTP/2 — API Server menyebarkan event perubahan status secara real-time menggunakan koneksi streaming HTTP/2 gRPC, menghilangkan overhead polling.
• Policy Enforcement — Admission Controllers (seperti Kyverno/Gatekeeper) bertugas mengamankan kluster produksi dengan menolak manifes yang melanggar aturan organisasi.
• Dilarang Bypass etcd — Jangan pernah mencoba memodifikasi database etcd secara langsung tanpa melalui API Server guna menghindari kerusakan database kluster.

← Sebelumnya: Worker Node   Berikutnya: Scheduler →