API Server #

API Server adalah komponen paling sentral di seluruh Kubernetes. Setiap operasi yang terjadi di cluster — dari kubectl apply hingga kubelet yang melaporkan status, dari controller yang membuat Pod hingga operator yang membaca metric — semuanya melewati API Server. Memahami API Server secara mendalam membuka wawasan tentang bagaimana Kubernetes benar-benar bekerja, bukan hanya bagaimana cara menggunakannya.

Peran API Server dalam Cluster #

API Server melayani tiga fungsi sekaligus yang tidak bisa dipisahkan:

API Server sebagai:

1. Gateway tunggal ke Etcd
   Tidak ada komponen lain yang membaca/menulis ke Etcd langsung.
   Semua perubahan state cluster harus melalui API Server.

2. Hub komunikasi antar komponen
   Scheduler tidak berbicara ke Controller Manager.
   Kubelet tidak berbicara ke Scheduler.
   Semuanya berbicara ke API Server, API Server yang mengkoordinasikan.

3. Enforcement point untuk keamanan
   Autentikasi, otorisasi, dan policy validation semuanya di sini.
   Satu tempat untuk audit semua yang terjadi di cluster.

Pipeline Request #

Setiap request ke API Server melewati pipeline yang sama, tanpa pengecualian:

HTTP/HTTPS Request
        │
        ▼
┌───────────────────────────────────────┐
│           Authentication              │
│  Siapa pengirimnya?                   │
│  → Client certificate (TLS mutual)    │
│  → Bearer token (ServiceAccount)      │
│  → Username/password (basic auth)     │
│  Gagal → 401 Unauthorized             │
└───────────────────┬───────────────────┘
                    │
                    ▼
┌───────────────────────────────────────┐
│            Authorization              │
│  Bolehkah mereka melakukan ini?       │
│  → Cek RBAC rules                     │
│  → Evaluasi ClusterRole & RoleBinding │
│  Gagal → 403 Forbidden                │
└───────────────────┬───────────────────┘
                    │
                    ▼
┌───────────────────────────────────────┐
│         Admission Control             │
│  Apakah request ini sesuai policy?    │
│  → Mutating webhooks (modifikasi)     │
│  → Validating webhooks (validasi)     │
│  Gagal → 400/422 Bad Request          │
└───────────────────┬───────────────────┘
                    │
                    ▼
┌───────────────────────────────────────┐
│         Serialization & Storage       │
│  Simpan ke Etcd, kirim respons        │
└───────────────────────────────────────┘

Autentikasi #

Kubernetes tidak punya sistem user management bawaan seperti database username/password. Identitas di Kubernetes dibuktikan melalui beberapa metode:

Client Certificate — cara yang paling umum untuk administrator dan komponen internal. Kubelet, Scheduler, dan Controller Manager semuanya menggunakan certificate untuk membuktikan identitasnya ke API Server.

# Isi certificate yang digunakan kubectl bisa dilihat di kubeconfig
kubectl config view --raw | grep client-certificate-data

Bearer Token — digunakan oleh ServiceAccount untuk Pod yang perlu mengakses API Server dari dalam cluster.

Pod yang perlu akses ke API Server:
  → Kubernetes otomatis mount ServiceAccount token ke /var/run/secrets/kubernetes.io/serviceaccount/token
  → Pod mengirim token ini di header Authorization: Bearer <token>
  → API Server memvalidasi token

OIDC (OpenID Connect) — integrasi dengan identity provider eksternal seperti Google, Azure AD, atau Dex. Memungkinkan login ke cluster menggunakan akun organisasi.

kubectl sendiri membuktikan identitasnya menggunakan client certificate atau token yang tersimpan di file kubeconfig (~/.kube/config). Inilah mengapa file kubeconfig harus dijaga seperti password — siapa yang punya file ini punya akses ke cluster.

Otorisasi dengan RBAC #

Setelah identitas terbukti, API Server mengecek apakah identitas tersebut diizinkan melakukan operasi yang diminta. Kubernetes menggunakan Role-Based Access Control (RBAC).

RBAC bekerja melalui empat resource:

Role: mendefinisikan izin dalam satu namespace
  apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "create", "update"]

ClusterRole: mendefinisikan izin di seluruh cluster

RoleBinding: menghubungkan Role ke user/group/serviceaccount dalam namespace

ClusterRoleBinding: menghubungkan ClusterRole ke user/group/serviceaccount secara global

Contoh alur pengecekan RBAC:

Request: user "alice" ingin membuat Deployment di namespace "production"

API Server cek:
1. Ada RoleBinding di namespace "production" untuk user "alice"?
   → Ya: RoleBinding "dev-team-binding" yang mengikat Role "developer"

2. Apakah Role "developer" mengizinkan create Deployment?
   → Ya: role ini punya verbs: ["get", "list", "create"] untuk resource "deployments"

→ Request diizinkan

Admission Controllers #

Admission controller adalah plugin yang berjalan setelah otorisasi tapi sebelum request disimpan ke Etcd. Ada dua jenis:

Mutating Admission Controller — bisa memodifikasi request sebelum disimpan. Contoh use case:

  • Otomatis inject sidecar container (service mesh seperti Istio melakukan ini)
  • Menambahkan default resource limits jika tidak didefinisikan
  • Menambahkan label atau annotation secara otomatis

Validating Admission Controller — hanya bisa menerima atau menolak request, tidak bisa memodifikasi. Contoh use case:

  • Memastikan semua container punya resource limits
  • Menolak image yang tidak berasal dari registry yang diizinkan
  • Validasi naming convention
Urutan eksekusi admission controller:

Request
  │
  ▼
Mutating webhooks (dijalankan secara serial)
  │  → bisa memodifikasi request
  ▼
Validating webhooks (dijalankan secara paralel)
  │  → hanya bisa terima/tolak
  ▼
Disimpan ke Etcd

Admission controller dikonfigurasi sebagai Webhook — API Server memanggil HTTP endpoint eksternal yang menjalankan logika validasi atau mutasi. Ini memungkinkan kebijakan cluster yang sangat fleksibel dan bisa diperbarui tanpa restart API Server.

Watch Mechanism #

Salah satu fitur paling penting dari API Server adalah kemampuan watch — komponen bisa “berlangganan” perubahan pada resource tertentu dan menerima notifikasi real-time.

Kubectl menjalankan watch:
  kubectl get pods --watch

  Di balik layar:
  GET /api/v1/namespaces/default/pods?watch=true

  API Server membuka long-lived HTTP connection dan streaming:
  {"type":"ADDED","object":{...pod details...}}
  {"type":"MODIFIED","object":{...pod status updated...}}
  {"type":"DELETED","object":{...pod deleted...}}

Controller Manager dan Scheduler menggunakan mekanisme yang sama tapi lebih canggih: Informer. Informer adalah abstraksi di atas watch yang menambahkan caching lokal dan event queue, sehingga tidak setiap perubahan harus langsung diproses.

Informer bekerja dengan dua fase:

Fase 1 — List (saat startup):
  Minta semua resource dari tipe tertentu ke API Server
  Simpan ke cache lokal

Fase 2 — Watch (ongoing):
  Subscribe perubahan dari API Server
  Update cache lokal saat ada perubahan
  Panggil handler function saat ada event baru

Manfaat:
  → Controller tidak perlu query API Server untuk setiap keputusan
  → Cukup baca dari cache lokal → jauh lebih efisien
  → API Server tidak overload meski ada ratusan controller

Berinteraksi Langsung dengan API Server #

kubectl pada dasarnya adalah HTTP client yang berbicara ke API Server. Kamu bisa mengakses API Server langsung untuk memahami apa yang sebenarnya terjadi:

# Buka proxy ke API Server (menangani autentikasi otomatis)
kubectl proxy --port=8001

# Di terminal lain, akses API langsung
curl http://localhost:8001/api/v1/namespaces/default/pods

# Lihat semua API group yang tersedia
curl http://localhost:8001/apis

# Watch perubahan Pod secara real-time
curl "http://localhost:8001/api/v1/namespaces/default/pods?watch=true"

# Atau dengan kubectl verbose untuk melihat HTTP request yang dibuat
kubectl get pods -v=8

# Output akan menampilkan:
# GET https://api-server:6443/api/v1/namespaces/default/pods
# Response Status: 200 OK
# Response Body: {...}

API Versioning dan Deprecation #

Kubernetes sangat serius dalam menjaga kompatibilitas backward. Resource API diorganisir dalam API group dan versi:

Stable API:    /api/v1                    ← Pod, Service, ConfigMap
Apps API:      /apis/apps/v1              ← Deployment, StatefulSet
Networking:    /apis/networking.k8s.io/v1 ← Ingress, NetworkPolicy
RBAC:          /apis/rbac.authorization.k8s.io/v1

Alpha (berubah tanpa notice): v1alpha1
Beta (lebih stabil):          v1beta1
Stable (garansi kompatibel):  v1

Ketika sebuah API versi di-deprecate, Kubernetes memberikan masa transisi minimal satu minor version (biasanya lebih lama). Manifest yang menggunakan API lama akan mendapat warning tapi masih berfungsi sampai versi tersebut benar-benar dihapus.

Ringkasan #

  • API Server adalah satu-satunya gateway ke Etcd — tidak ada komponen lain yang membaca atau menulis ke Etcd langsung; semua melalui API Server.
  • Pipeline tiga tahap — setiap request melewati autentikasi, otorisasi RBAC, dan admission control sebelum diproses; tidak ada pengecualian.
  • Kubernetes tidak punya user database — identitas dibuktikan via certificate, token ServiceAccount, atau OIDC; file kubeconfig mengandung kredensial dan harus dijaga ketat.
  • Admission controller untuk policy enforcement — mutating untuk modifikasi otomatis, validating untuk penolakan; keduanya bisa dikustomisasi via webhook.
  • Watch mechanism adalah fondasi efisiensi — komponen tidak poll API Server; mereka subscribe perubahan dan menyimpan cache lokal via Informer pattern.
  • API versioning tiga tingkat — alpha bisa berubah kapan saja, beta relatif stabil, stable (v1) dijamin kompatibel backward.

← Sebelumnya: Worker Node   Berikutnya: Scheduler →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact