Cluster #

Kluster (cluster) adalah unit fundamental dan batas fisik terkecil dari seluruh ekosistem Kubernetes. Ketika kita menyatakan bahwa kita sedang “mendeploy aplikasi ke Kubernetes”, hal itu secara konkret berarti kita sedang berinteraksi dengan sebuah kluster Kubernetes. Kluster mengabstraksikan sekumpulan mesin fisik atau mesin virtual (Virtual Machine) menjadi satu kolam komputasi raksasa yang terpadu.

Memahami bagaimana kluster disusun, bagaimana pembagian peran di dalamnya terjadi, serta bagaimana komunikasi antar komponen dikelola merupakan langkah awal yang wajib dikuasai sebelum kita mendalami objek-objek API Kubernetes yang lebih spesifik.

Pembagian Peran Kluster: Otak vs Otot #

Sebuah kluster Kubernetes tersusun atas sejumlah mesin server (dikenal sebagai Node) yang bekerja sama. Node-node ini dibagi menjadi dua peran utama dengan batas tanggung jawab yang sangat jelas: Control Plane (Otak) dan Worker Node (Otot).

1. Control Plane (Otak Kluster) #

Control Plane bertanggung jawab penuh atas pengambilan keputusan global di dalam kluster (seperti penjadwalan beban kerja), mendeteksi setiap kegagalan, serta merespons perubahan untuk menjaga agar kluster tetap berada pada kondisi yang diinginkan (desired state).

Control Plane tersusun atas beberapa komponen inti yang bekerja secara modular:

  • kube-apiserver: Gerbang utama kluster. Semua komunikasi (baik dari admin via kubectl, aplikasi internal, maupun worker node) harus melalui API Server. Komponen ini memvalidasi dan memproses setiap request.
  • etcd: Basis data terdistribusi bertipe key-value yang menjadi satu-satunya sumber kebenaran (single source of truth) data kluster. Semua konfigurasi, status, dan riwayat objek disimpan di sini secara konsisten.
  • kube-scheduler: Komponen pencari node. Ketika ada Pod baru dibuat, Scheduler akan mendeteksi kebutuhan resource Pod tersebut dan mencari worker node yang paling cocok untuk menjalankannya.
  • kube-controller-manager: Kumpulan loop kontrol yang bertugas menjaga konsistensi kluster. Misalnya, Node Controller mengawasi kesehatan node, sedangkan Deployment Controller memastikan jumlah replika aplikasi selalu sesuai.

2. Worker Node (Otot Kluster) #

Worker Node bertugas untuk mengeksekusi beban kerja aplikasi aktual yang dibungkus dalam bentuk Pod. Komponen yang berjalan di worker node bertugas menerima perintah dari control plane dan melaporkan kembali status kesehatan komputasi secara berkala.

Komponen utama di Worker Node meliputi:

  • kubelet: Agen utama Kubernetes yang berjalan di setiap node. Kubelet memantau spesifikasi Pod (PodSpec) yang dikirimkan oleh API Server dan memastikan kontainer-kontainer di dalam Pod tersebut berjalan dengan sehat.
  • kube-proxy: Pengelola aturan jaringan di tingkat node. Kube-proxy bertugas meneruskan traffic dari load balancer internal ke kontainer aplikasi yang tepat.
  • Container Runtime: Software yang bertugas mengunduh image kontainer dan menjalankannya secara fisik (misal: containerd atau CRI-O).

Topologi Kluster: Dari Lokal hingga High Availability (HA) #

Topologi kluster Kubernetes dirancang sangat fleksibel dan dapat dikonfigurasi sesuai dengan target beban kerja serta toleransi downtime yang disepakati.

1. Kluster Single-Node (Development Lokal) #

Pada topologi ini, seluruh komponen Control Plane dan Worker Node dijalankan di dalam satu mesin fisik atau VM yang sama. Topologi ini sangat ideal untuk keperluan eksperimen, pembelajaran, pengujian pipeline CI/CD, atau pengembangan aplikasi di laptop lokal menggunakan alat bantu seperti Kind atau Minikube.

2. Kluster Multi-Node Standard (Staging) #

Control Plane dijalankan di atas satu mesin dedicated terpisah, sementara beban kerja aplikasi disebarkan ke beberapa mesin Worker Node yang berbeda. Pola ini memisahkan beban kerja sistem dengan beban kerja aplikasi, sehingga jika aplikasi kehabisan memori, Control Plane kluster tetap aman dan tidak ikut crash.

3. Kluster High Availability (HA Produksi) #

Untuk lingkungan produksi kritis, topologi dengan satu Control Plane tunggal sangat berbahaya karena merupakan titik kegagalan tunggal (single point of failure). Jika server control plane mati, kita kehilangan kemampuan untuk memantau, menskalakan, atau memperbaiki aplikasi.

Kluster HA memecahkan masalah ini dengan mendistribusikan Control Plane ke beberapa server (biasanya minimal 3 atau 5 mesin untuk mencapai kuorum algoritma konsensus Raft pada etcd) di belakang load balancer eksternal.

flowchart TD
    subgraph CP_HA ["Control Plane High Availability (Multi-Node)"]
        direction TB
        LB["External Load Balancer (Port 6443)"]
        
        CP1["Control Plane Node 1
        (API Server, Controller, Scheduler)"]
        CP2["Control Plane Node 2
        (API Server, Controller, Scheduler)"]
        CP3["Control Plane Node 3
        (API Server, Controller, Scheduler)"]
        
        subgraph ETCD_Cluster ["Replicated etcd Cluster"]
            E1["etcd 1"] <--> E2["etcd 2"]
            E2 <--> E3["etcd 3"]
            E3 <--> E1["etcd 1"]
        end
        
        LB --> CP1
        LB --> CP2
        LB --> CP3
        
        CP1 <--> ETCD_Cluster
        CP2 <--> ETCD_Cluster
        CP3 <--> ETCD_Cluster
    end

    subgraph Workers ["Worker Nodes Pool"]
        W1["Worker Node 1
        (kubelet, proxy, containerd)"]
        W2["Worker Node 2
        (kubelet, proxy, containerd)"]
        W3["Worker Node 3
        (kubelet, proxy, containerd)"]
    end

    W1 --> LB
    W2 --> LB
    W3 --> LB

    style CP_HA stroke:#8e44ad,stroke-width:2px
    style ETCD_Cluster stroke:#d35400,stroke-width:2px
    style Workers stroke:#27ae60,stroke-width:2px

Dalam arsitektur HA di atas, jika Control Plane Node 1 mati mendadak, load balancer akan mengalihkan lalu lintas permintaan API dari kubelet ke Control Plane Node 2 atau Node 3 secara instan. Kluster tetap berfungsi normal tanpa ada interupsi bagi daur hidup aplikasi.

Manajemen Multi-Kluster: Kubeconfig dan Context #

Sebagai seorang engineer yang mengelola infrastruktur, kita hampir pasti akan bekerja dengan lebih dari satu kluster Kubernetes secara bersamaan — misalnya kluster lokal untuk development, kluster staging untuk pengujian integrasi, dan kluster produksi untuk pengguna akhir.

Kubernetes mengelola kredensial dan endpoint akses kluster-kluster ini melalui sebuah file konfigurasi bernama kubeconfig yang secara default terletak di folder home user: ~/.kube/config.

Di dalam file kubeconfig, data dibagi menjadi tiga bagian utama:

  1. clusters: Berisi alamat endpoint API Server (misal: https://prod-k8s.company.com:6443) beserta sertifikat keamanan otoritasnya (CA Certificate).
  2. users: Berisi token autentikasi atau sertifikat klien dari pengguna kluster.
  3. contexts: Penghubung antara kluster dan user. Menentukan pasangan: “Saya ingin terhubung ke kluster X menggunakan user Y di namespace Z”.

Kita dapat dengan mudah memeriksa dan berpindah konteks aktif menggunakan perintah bawaan kubectl:

# Menampilkan seluruh context yang terdaftar di file kubeconfig
kubectl config get-contexts

# Mengaktifkan context target (misal: staging-cluster)
kubectl config use-context staging-cluster

# Memeriksa context mana yang sedang aktif saat ini
kubectl config current-context

Anti-Pattern: Mengeksekusi Perintah Destruktif pada Context yang Salah #

Bekerja dengan multi-kluster dalam satu terminal yang sama menyimpan risiko human error yang sangat tinggi. Kesalahan yang paling sering ditemui adalah mengeksekusi perintah penghapusan resource di kluster produksi karena berasumsi terminal sedang terhubung ke kluster staging.

ANTI-PATTERN: Eksekusi Perintah Tanpa Validasi Konteks
// KITA MELAKUKAN:
- Menjalankan perintah hapus resource secara terburu-buru:
  kubectl delete namespace payment-service
- Berasumsi terminal terhubung ke kluster lokal/staging.
// KONSEKUENSI DI PRODUKSI:
- Seluruh Pod, Service, ConfigMap, dan data database transient dari layanan pembayaran 
  di kluster produksi terhapus seketika. Downtime total sistem transaksi terjadi.

✓ SOLUSI YANG BENAR:
- Gunakan visualisasi context aktif pada terminal prompt Anda menggunakan tools seperti 
  [kube-ps1](https://github.com/jonmosco/kube-ps1) atau prompt Zsh tema Starship. Prompt terminal 
  akan selalu menampilkan nama kluster aktif secara visual (misal: `(k8s:prod-cluster)` dengan warna merah).
- Gunakan tool seperti [kubectx](https://github.com/ahmetb/kubectx) dan [kubens] untuk berpindah kluster dan namespace secara aman.
- Buat alias khusus dengan proteksi konfirmasi sebelum menjalankan perintah destruktif di cluster produksi.

Pembagian Logis Kluster: Namespace #

Sebuah kluster Kubernetes fisik dapat dibagi menjadi beberapa sub-kluster logis terpisah menggunakan objek Namespace. Namespace bertindak sebagai ruang isolasi nama resource yang berguna untuk membagi kapasitas kluster di antara beberapa tim kerja atau memisahkan lingkungan aplikasi.

# Menampilkan seluruh namespace yang ada di dalam kluster
kubectl get namespaces

# Membuat namespace baru
kubectl create namespace staging

# Melihat daftar Pod di namespace spesifik
kubectl get pods -n staging

Setiap objek di dalam Kubernetes (seperti Pod, Service, Deployment) secara default harus terdaftar di dalam sebuah namespace. Jika kita tidak menentukannya, objek akan dimasukkan ke namespace bawaan bernama default.

Format Resolusi Nama DNS Antar Namespace #

Setiap kali kita mendeploy Service di dalam namespace tertentu, CoreDNS kluster akan mendaftarkan nama domain Service tersebut menggunakan format:

<nama-service>.<nama-namespace>.svc.cluster.local

Artinya, jika Pod Frontend di namespace development ingin mengakses Service API di namespace yang sama, ia cukup memanggil nama pendek http://api-service. Namun, jika ia ingin memanggil API di namespace production, ia harus memanggil nama domain lengkap: http://api-service.production.svc.cluster.local.

Batasan Isolasi Namespace #

Perlu diingat bahwa secara default, Namespace hanya memberikan isolasi nama resource, bukan isolasi fisik atau keamanan.

  • Jaringan: Pod di namespace development secara default dapat mengirimkan paket data ke Pod di namespace production. Untuk membatasi komunikasi ini, kita harus mengonfigurasi objek NetworkPolicy.
  • Alokasi Resource: Satu namespace dapat mengonsumsi seluruh kapasitas CPU/Memory kluster jika tidak dibatasi. Untuk mencegah tim dev menghabiskan kapasitas kluster produksi, kita harus mengonfigurasi objek ResourceQuota di tingkat namespace.

Ringkasan #

  • Kluster adalah abstraksi server terpadu — menyatukan sekumpulan node mesin menjadi satu pool resource komputasi besar yang dikelola API terpusat.
  • Control Plane vs Worker Node — Control Plane (API Server, Scheduler, Controller, etcd) bertugas mengambil keputusan, sedangkan Worker Node (kubelet, proxy, runtime) bertugas menjalankan Pod aplikasi.
  • Topologi Produksi Wajib HA — Menjalankan satu Control Plane tunggal di produksi sangat berisiko. Kluster HA mendistribusikan control plane ke minimal 3 node di belakang load balancer.
  • Kubeconfig dan Context — Berpindah kluster dikelola lewat file ~/.kube/config. Selalu gunakan terminal prompt visual (seperti kube-ps1) untuk meminimalkan risiko salah eksekusi perintah di kluster produksi.
  • Namespace membagi kluster secara logis — Untuk menghindari konflik nama objek dan membagi kuota resource per tim. Ingat bahwa namespace tidak memblokir traffic jaringan secara default tanpa adanya NetworkPolicy.

← Sebelumnya: Kapan Dibutuhkan?   Berikutnya: Node →

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