Membangun High Availability Kubernetes Cluster untuk Arsitektur Microservices Skala Raksasa

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur modern berskala raksasa, aplikasi berbasis microservices tidak lagi menjadi tren semata, melainkan sebuah keharusan operasional untuk melayani jutaan request per detik. Namun, kompleksitas ini mendatangkan tantangan baru pada infrastruktur bawahannya. Sebuah kegagalan pada satu node kontrol atau pemadaman sesaat pada instance database dapat memicu efek domino yang merontokkan seluruh ekosistem digital perusahaan. Mengandalkan single-node control plane atau cluster Kubernetes standar tanpa strategi High Availability (HA) yang matang adalah sebuah tiket langsung menuju bencana operasional.

Secara historis, bottleneck terbesar dalam mengelola infrastruktur web modern berskala masif terletak pada single point of failure (SPOF) di Control Plane Kubernetes, khususnya pada komponen etcd, kube-apiserver, dan kube-controller-manager. Ketika traffic melonjak akibat kampanye flash sale atau serangan DDoS terdistribusi, kuorum etcd sering kali mengalami leader election timeout jika tidak didistribusikan ke dalam topologi multi-master dengan penyimpanan SSD berkecepatan tinggi.

Perbandingan kondisi antara infrastruktur konvensional dan arsitektur High Availability berbasis Kubernetes dapat dijabarkan sebagai berikut:

• Sebelum Penerapan (Single Control Plane / Non-HA):

  • Ketersediaan: 95% - 98% (Sering terjadi downtime saat upgrade sistem operasi atau kegagalan node fisik).
  • Pemulihan Bencana: Membutuhkan intervensi manual (manual failover) dengan RTO (Recovery Time Objective) mencapai 30-60 menit.
  • Manajemen Traffic: Menggunakan load balancer konvensional berbasis HAProxy tunggal yang rentan terhadap saturasi bandwidth.
  • Keamanan: Sertifikat SSL/TLS dikelola manual menggunakan skrip cron kustom yang sering kedaluwarsa tanpa peringatan dini.

• Sesudah Penerapan (High Availability Kubernetes Cluster Skala Raksasa):

  • Ketersediaan: 99.99% (Empat sembilan) dengan mekanisme failover otomatis dalam hitungan detik.
  • Pemulihan Bencana: Otomatis tanpa intervensi manusia, RTO mendekati 0 detik untuk beban kerja stateless dan < 15 detik untuk stateful.
  • Manajemen Traffic: Menggunakan arsitektur Ingress Controller berbasis Nginx/Envoy dengan pembagian beban terdistribusi dan integrasi Cloudflare Edge Caching.
  • Keamanan: Otomatisasi penuh siklus hidup sertifikat menggunakan cert-manager dipadukan dengan pemindaian WAF real-time.

[!WARNING] Jangan pernah menjalankan klaster produksi Kubernetes dengan jumlah node kontrol ganjil kurang dari tiga (misal: 2 node). Konfigurasi kuorum etcd membutuhkan minimal 3 node agar algoritma konsensus Raft dapat berfungsi secara optimal dalam menangani kegagalan satu node tanpa kehilangan data.

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur High Availability Kubernetes mendistribusikan beban kontrol plane ke beberapa node master secara paralel. Di atas node-node master tersebut, sebuah load balancer eksternal (seperti HAProxy atau Keepalived dengan Virtual IP) berdiri di depan untuk menerima seluruh panggilan API dari kubectl maupun agen internal klaster.

Di dalam setiap node master, komponen inti bekerja secara sinkron:

1. kube-apiserver: Pintu gerbang utama berbasis HTTP REST yang memproses seluruh instruksi manajemen.
2. etcd: Penyimpanan data terdistribusi konsisten yang menyimpan seluruh status (state) klaster.
3. kube-controller-manager & kube-scheduler: Mengatur siklus hidup pod, replika, dan penjadwalan beban kerja ke worker nodes.

Berikut adalah representasi visual alur komunikasi arsitektur High Availability:

+-----------------------------------------------------------------------+
|                           EXTERNAL CLIENTS                            |
+-----------------------------------------------------------------------+
                                    |
                                    v
+-----------------------------------------------------------------------+
|               LOAD BALANCER / VIP (HAProxy / Keepalived)              |
+-----------------------------------------------------------------------+
           |                        |                        |
           v                        v                        v
+--------------------+   +--------------------+   +--------------------+
|   MASTER NODE 1    |   |   MASTER NODE 2    |   |   MASTER NODE 3    |
|  - kube-apiserver  |   |  - kube-apiserver  |   |  - kube-apiserver  |
|  - etcd (Member 1) |   |  - etcd (Member 2) |   |  - etcd (Member 3) |
|  - Controller/Sch. |   |  - Controller/Sch. |   |  - Controller/Sch. |
+--------------------+   +--------------------+   +--------------------+
           ^                        ^                        ^
           |                        |                        |
           +------------------------+------------------------+
                                    |
                                    v
+-----------------------------------------------------------------------+
|                             WORKER NODES                              |
|          (kubelet, kube-proxy, Container Runtime / containerd)        |
+-----------------------------------------------------------------------+

Alur eksekusi saat terjadi kegagalan node:

1. Node Master 1 mengalami pemadaman mendadak (hard crash).
2. Load Balancer mendeteksi kegagalan kesehatan (health check timeout) pada port 6443 Node Master 1.
3. Load Balancer secara otomatis mengalihkan seluruh traffic API server ke Node Master 2 dan Master 3.
4. Klaster tetap berjalan normal karena etcd mempertahankan kuorum (2 dari 3 node masih aktif).
5. Schedulers dan controllers pada master yang tersisa mengambil alih proses rekonsiliasi state klaster.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun infrastruktur high availability, pemilihan metode kontrol plane dan load balancer menentukan stabilitas jangka panjang. Tabel berikut membandingkan dua pendekatan utama: Pendekatan Stacked etcd (menggabungkan etcd di node master) vs External etcd (memisahkan klaster etcd dari node master).

[!TIP] Untuk organisasi dengan skala menengah hingga besar yang mengutamakan stabilitas mutlak, arsitektur External etcd dengan disk NVMe berperforma tinggi adalah standar emas industri.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum mengeksekusi instalasi klaster Kubernetes High Availability, pastikan seluruh node (baik master maupun worker) memenuhi spesifikasi minimum berikut:

• Hardware Minimum per Node Master: 4 vCPU, 8 GB RAM, 50 GB SSD (NVMe sangat dianjurkan).
• Hardware Minimum per Worker Node: 8 vCPU, 16 GB RAM, 100 GB SSD.
• Sistem Operasi: Ubuntu Server 22.04 LTS (Kernel Linux >= 5.15) atau RHEL 9.
• Jaringan: Konektivitas internal tanpa NAT antar node, port TCP yang wajib dibuka:
  • Master Nodes: 6443, 2379-2380, 10250, 10259, 10257
  • Worker Nodes: 10250, 30000-32767

Langkah persiapan awal yang wajib dijalankan pada seluruh node (jalankan sebagai root atau sudo):

# 1. Nonaktifkan Swap secara permanen (Kubernetes tidak dapat berjalan dengan swap aktif)
sed -i '/ swap / s/^/#/' /etc/fstab
swapoff -a

# 2. Muat modul kernel yang dibutuhkan oleh containerd & Kubernetes
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# 3. Konfigurasi parameter sysctl agar lalu lintas jembatan (bridge) diteruskan dengan benar
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

sudo sysctl --system

# 4. Instalasi Container Runtime (containerd)
sudo apt-get update
sudo apt-get install -y containerd.ini curl gnupg lsb-release apt-transport-https ca-certificates curl

sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# Ubah SystemdCgroup menjadi true pada konfigurasi containerd
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml

sudo systemctl restart containerd
sudo systemctl enable containerd

# 5. Instalasi kubeadm, kubelet, dan kubectl
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /" | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

5. Panduan Implementasi Langkah demi Langkah

Bagian ini memandu Anda membangun kontrol plane HA menggunakan kubeadm, mengonfigurasi load balancer HAProxy untuk akses API Server, serta menerapkan Ingress Controller dan Cert-Manager.

Langkah 5.1: Konfigurasi Load Balancer HAProxy (Diluar Node Master)

Pada server load balancer terpisah (atau instance mandiri), instal dan konfigurasikan HAProxy untuk mendistribusikan traffic ke master nodes.

sudo apt-get update && sudo apt-get install -y haproxy

Edit file /etc/haproxy/haproxy.cfg dan tambahkan blok konfigurasi berikut:

global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    daemon

defaults
    log     global
    mode    tcp
    option  tcplog
    option  dontlognull
    retries 3
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout check           2s

frontend k8s-api
    bind 192.168.1.100:6443
    mode tcp
    option tcplog
    default_backend k8s-api-backends

backend k8s-api-backends
    mode tcp
    balance roundrobin
    option tcp-check
    server master-01 192.168.1.101:6443 check fall 3 rise 2
    server master-02 192.168.1.102:6443 check fall 3 rise 2
    server master-03 192.168.1.103:6443 check fall 3 rise 2

Restart layanan HAProxy:

sudo systemctl restart haproxy
sudo systemctl enable haproxy

Langkah 5.2: Inisialisasi Master Node Pertama

Buat file konfigurasi kubeadm-config.yaml pada Master Node pertama (192.168.1.101):

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.28.0
controlPlaneEndpoint: "192.168.1.100:6443"
etworking:
  podSubnet: "10.244.0.0/16"
  serviceSubnet: "10.96.0.0/12"
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: "192.168.1.101"
  bindPort: 6443

Jalankan inisialisasi klaster:

sudo kubeadm init --config=kubeadm-config.yaml --upload-certs

Simpan token dan perintah kubeadm join yang dihasilkan pada output terminal untuk menggabungkan master node berikutnya dan worker nodes.

Konfigurasikan akses kubectl untuk user lokal:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Instal Network Plugin (Calico):

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml

Langkah 5.3: Konfigurasi Ingress Controller (NGINX) & Cert-Manager

Untuk menangani traffic HTTP/HTTPS masuk dengan routing berbasis domain dan otomatisasi SSL, terapkan NGINX Ingress Controller dan Cert-Manager.

# Instal NGINX Ingress Controller
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml

# Instal Cert-Manager untuk manajemen sertifikat SSL otomatis Let's Encrypt
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.1/cert-manager.yaml

Buat konfigurasi Issuer (cluster-issuer.yaml):

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@perusahaan.com
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
    - http01:
        ingress:
          class: nginx

Terapkan issuer:

kubectl apply -f cluster-issuer.yaml

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah beberapa parameter krusial dalam file konfigurasi yang telah kita buat:

1. controlPlaneEndpoint: "192.168.1.100:6443"

   • Fungsi: Menentukan alamat IP virtual/load balancer tempat seluruh komponen kontrol plane mendengarkan request eksternal. Parameter ini memaksa kubelet dan worker nodes berkomunikasi melalui HAProxy alih-alih langsung menunjuk ke satu IP node fisik.
   • Dampak Kesalahan: Jika parameter ini dihilangkan atau salah alamat, worker nodes tidak akan dapat bergabung kembali ke klaster setelah terjadi kegagalan pada master node pertama.

2. podSubnet: "10.244.0.0/16"

   • Fungsi: Menentukan rentang alamat IP privat yang akan dialokasikan ke setiap Pod yang berjalan di dalam klaster. Nilai 10.244.0.0/16 adalah standar yang digunakan oleh network plugin Calico.
   • Dampak Kesalahan: Tabrakan IP (IP overlapping) dengan jaringan lokal perusahaan dapat menyebabkan komunikasi antar pod terputus total.

3. SystemdCgroup = true pada containerd

   • Fungsi: Memastikan pengelola container (containerd) menggunakan cgroups v2 dari systemd. Hal ini sangat penting untuk stabilitas penggunaan memori dan CPU pada kernel Linux modern.
   • Dampak Kesalahan: Menyebabkan lonjakan penggunaan resource tanpa batas (memory leak tak terkendali) yang berujung pada kernel panic atau OOM Killer mematikan proses kubelet.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Studi Kasus: Menangani Lonjakan Traffic Flash Sale 500.000 RPS pada Platform E-Commerce

Sebuah perusahaan e-commerce besar menghadapi lonjakan traffic hingga 500.000 Request Per Second (RPS) saat event belanja akhir tahun. Sistem backend dibangun menggunakan microservices Go dan Node.js, terhubung dengan database cluster MariaDB dan Redis Caching.

Strategi Mitigasi Berbasis Kubernetes HA:

1. Horizontal Pod Autoscaler (HPA) & KEDA: Mengonfigurasi HPA berbasis metrik custom Prometheus (jumlah antrean pesan di RabbitMQ) untuk melakukan scale-out pod backend dari 10 instance menjadi 200 instance dalam waktu kurang dari 45 detik.
2. Pod Disruption Budgets (PDB): Menerapkan aturan PDB untuk memastikan selama proses rolling update atau maintenance node, minimal 80% instance aplikasi tetap aktif melayani traffic.

   apiVersion: policy/v1
   kind: PodDisruptionBudget
   metadata:
     name: backend-pdb
     namespace: production
   spec:
     minAvailable: 80%
     selector:
       matchLabels:
         app: ecom-backend
   

3. Edge Caching & WAF: Mengintegrasikan Cloudflare Enterprise di depan Ingress Nginx untuk memblokir bot malicious, serta melakukan cache pada halaman statis produk dengan cache hit ratio mencapai 92%.

8. Common Pitfalls, Anti-Patterns & Solusi

• Anti-Pattern 1: Menjalankan Stateful Workloads Tanpa Storage Class yang Tepat di Klaster HA
  • Masalah: Menggunakan hostPath atau local storage pada deployment database di klaster multi-node. Ketika pod database berpindah (reschedule) ke node lain akibat kegagalan node, data tidak dapat diakses.
  • Solusi: Selalu gunakan Dynamic Provisioning Storage Class yang terintegrasi dengan Network File System (NFS), Ceph, atau AWS EBS/GCP Persistent Disk dengan mode ReadWriteOnce atau ReadWriteMany.
• Anti-Pattern 2: Mengabaikan Resource Limits pada Deployment
  • Masalah: Pod tidak mendefinisikan requests dan limits untuk CPU dan Memory.
  • Solusi: Terapkan LimitRange dan ResourceQuota di tingkat namespace untuk mencegah satu pod nakal melahap seluruh resource node yang mengakibatkan evicted pod massal.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk memastikan klaster siap menanggung beban produksi, lakukan pengujian beban menggunakan tool k6 atau wrk. Berikut adalah skrip pengujian k6 (load-test.js):

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 1000 }, // Ramp-up hingga 1000 VU dalam 2 menit
    { duration: '5m', target: 5000 }, // Pertahankan 5000 VU selama 5 menit
    { duration: '2m', target: 0 },    // Ramp-down kembali ke 0
  ],
  thresholds: {
    http_req_duration: ['p(99)<250'], // 99% request harus selesai di bawah 250ms
    http_req_failed: ['rate<0.01'],  // Error rate harus di bawah 1%
  },
};

export default function () {
  const res = http.get('https://api.perusahaan.com/v1/products');
  check(res, {
    'status adalah 200': (r) => r.status === 200,
    'wakturespon < 200ms': (r) => r.timings.duration < 200,
  });
  sleep(1);
}

Tuning Kernel Lanjutan (/etc/sysctl.conf di Worker Nodes):

# Meningkatkan batas maksimal file descriptor untuk koneksi WebSocket masif
fs.file-max = 2097152

# Optimasi TCP backlog untuk menangani koneksi bersamaan yang tinggi
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# Mengaktifkan TCP Reuse dan Timestamps
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

Terapkan perubahan dengan perintah sudo sysctl -p.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis klaster Kubernetes High Availability ke lingkungan produksi nyata, pastikan checklist berikut telah terpenuhi 100%:

• Kontrol Plane menggunakan minimal 3 node master dengan External/Stacked etcd yang sehat.
• Load Balancer (HAProxy/Keepalived) dikonfigurasi dengan pemeriksaan kesehatan (health check) aktif.
• Swap dinonaktifkan sepenuhnya pada seluruh node klaster.
• Network plugin (Calico/Cilium) terpasang dan aturan firewall jaringan (iptables/security groups) telah diverifikasi.
• Cert-manager dan NGINX Ingress Controller aktif dengan konfigurasi ClusterIssuer Let's Encrypt valid.
• Sistem monitoring (Prometheus, Grafana, Alertmanager) dikonfigurasi untuk memantau penggunaan CPU, Memory, Disk I/O, dan status etcd leader.
• Kebijakan Backup otomatis untuk direktori data etcd dijadwalkan secara berkala (minimal setiap 6 jam).

Dengan menerapkan seluruh arsitektur, konfigurasi baris demi baris, dan pengujian ketat di atas, klaster Kubernetes Anda kini memiliki fondasi baja yang siap menopang aplikasi microservices skala raksasa dengan ketahanan tinggi dan ketersediaan tanpa kompromi.