High Availability Kubernetes Clusters: Scaling & Disaster Recovery

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap enterprise modern, kegagalan infrastruktur bukanlah sebuah kemungkinan (probability), melainkan kepastian waktu (certainty). Ketika sebuah aplikasi web skala besar mengalami lonjakan trafik—baik karena flash sale, serangan DDoS, atau kegagalan node fisik di pusat data—infrastruktur Kubernetes yang tidak dirancang dengan High Availability (HA) akan langsung runtuh. Kerugian finansial dan reputasi yang diakibatkan oleh downtime ini sangat masif.

Secara historis, administrator sistem mengandalkan satu master node tunggal untuk menjalankan control plane Kubernetes (API Server, etcd, Controller Manager, Scheduler). Pendekatan ini menyimpan cacat fatal: Single Point of Failure (SPOF). Jika master node tersebut mengalami kernel panic, kegagalan disk, atau gangguan jaringan, seluruh kluster menjadi buta. Anda tidak dapat melakukan scaling, deployment baru, atau bahkan memonitor kesehatan pod yang berjalan.

[!WARNING] Menjalankan kluster Kubernetes produksi tanpa multi-master control plane dan mekanisme disaster recovery otomatis adalah bentuk kelalaian operasional yang berisiko tinggi terhadap kelangsungan bisnis.

Kondisi Sebelum vs Sesudah Implementasi HA & DR

2. Konsep Inti & Deep Dive Arsitektur

Untuk mencapai High Availability sejati pada control plane Kubernetes, kita harus mendistribusikan komponen inti ke beberapa node master (biasanya ganjil: 3 atau 5 node) untuk mencegah split-brain syndrome dalam konsensus etcd.

Alur Kerja Control Plane HA & Load Balancing

+-------------------------------------------------------------------------+
|                         External Load Balancer                          |----
|                        (HAProxy / Keepalived / AWS ELB)                 |    |
+-------------------------------------------------------------------------+    |
         |                                     |                               |
         v                                     v                               v
+------------------+                  +------------------+            +------------------+
|  Master Node 01  |                  |  Master Node 02  |            |  Master Node 03  |
|  - API Server    |                  |  - API Server    |            |  - API Server    |
|  - etcd (Peer)   | <--------------> |  - etcd (Peer)   | <--------> |  - etcd (Peer)   |
|  - Scheduler     |                  |  - Scheduler     |            |  - Scheduler     |
+------------------+                  +------------------+            +------------------+

Di atas lapisan control plane, komponen etcd menggunakan algoritma konsensus Raft. Raft membutuhkan kuorum (mayoritas node) untuk menyetujui setiap perubahan state kluster. Dengan 3 node master, kluster dapat bertahan dari matinya 1 node (tolerated failures = (n-1)/2). Load balancer eksternal (seperti HAProxy dengan Keepalived atau Cloud Load Balancer) bertindak sebagai pintu masuk tunggal (Virtual IP atau DNS) yang mendistribusikan trafik API dari kubectl dan kubelet ke seluruh node master yang aktif.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun HA Kubernetes, terdapat dua pendekatan utama untuk topologi etcd:

1. Stacked etcd Topology: Topologi di mana kluster etcd diko-lokasikan (co-located) pada node control plane yang sama.
2. External etcd Topology: Topologi di mana kluster etcd berjalan pada server terpisah dari node control plane.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum mengeksekusi instalasi, pastikan seluruh node (Minimal 3 Master, 2 Worker) memenuhi spesifikasi berikut:

• OS: Ubuntu Server 22.04 LTS / RHEL 9 (Clean installation)
• Hardware Minimum (Master): 4 vCPU, 8 GB RAM, 50 GB SSD
• Hardware Minimum (Worker): 8 vCPU, 16 GB RAM, 100 GB SSD
• Jaringan: Port 6443 (API Server), 2379-2380 (etcd), 10250 (Kubelet), 10259 (Scheduler), 10257 (Controller Manager) harus terbuka.

Jalankan perintah berikut pada seluruh node (Master dan Worker) untuk menyiapkan kernel dan modul:

# Matikan swap secara permanen
sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab

# Load modul kernel yang dibutuhkan container runtime
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# Konfigurasi sysparameter network untuk Kubernetes
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

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi Container Runtime (containerd) di Semua Node

# Instal dependensi dasar
sudo apt-get update
sudo apt-get install -y curl gnupg software-properties-common apt-transport-https ca-certificates

# Tambahkan GPG key resmi Docker
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Tambahkan repository Docker
echo \
  "deb [arch=$(dpkg --arch) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Instal containerd
sudo apt-get update && sudo apt-get install -y containerd.io

# Konfigurasi containerd agar menggunakan SystemdCgroup
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml

sudo systemctl restart containerd
sudo systemctl enable containerd

Langkah 2: Instalasi kubeadm, kubelet, dan kubectl

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /' | sudo tee /etc/apt/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

Langkah 3: Konfigurasi Load Balancer (HAProxy & Keepalived pada Control Plane Load Balancer Node)

Install HAProxy dan Keepalived di luar master node (atau gunakan load balancer cloud):

sudo apt-get install -y haproxy keepalived

Konfigurasi /etc/haproxy/haproxy.cfg:

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
    timeout connect 5000ms
    timeout client  50000ms
    timeout server  50000ms

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

backend k8s-master-backend
    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

Langkah 4: Inisialisasi Master Node Pertama (master-01)

Buat file konfigurasi kubeadm-config.yaml:

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:

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

Simpan perintah kubeadm join yang dihasilkan untuk master node berikutnya dan worker node.

Langkah 5: Setup Disaster Recovery dengan Velero (Backup & Restore)

Instal Velero CLI pada management workstation dan hubungkan ke object storage (misalnya MinIO atau AWS S3):

# Instal Velero CLI
wget https://github.com/vmware-tanzu/velero/releases/download/v1.12.0/velero-v1.12.0-linux-amd64.tar.gz
tar -xvf velero-v1.12.0-linux-amd64.tar.gz
sudo mv velero-v1.12.0-linux-amd64/velero /usr/local/bin/

# Buat kredensial file credentials-velero
cat <<EOF > credentials-velero
[default]
aws_access_key_id = minioadmin
aws_secret_access_key = minioadminpassword
EOF

# Instal Velero ke kluster Kubernetes dengan backends MinIO
velero install \
    --provider aws \
    --plugins velero/velero-plugin-for-aws:v1.8.0 \
    --bucket k8s-backups \
    --secret-file ./credentials-velero \
    --use-volume-snapshots=true \
    --backup-location-config region=minio,s3ForceURL=http://minio.storage.svc:9000

Membuat backup terjadwal (Scheduled Backup):

velero schedule create daily-cluster-backup --schedule="0 2 * * *"

Melakukan restore total jika terjadi bencana:

velero restore create --from-restore daily-cluster-backup-<timestamp>

6. Bedah Kode & Penjelasan Detail Baris Kunci

• controlPlaneEndpoint: "192.168.1.100:6443": Baris ini memberitahu kubeadm bahwa seluruh node di kluster harus mengarahkan komunikasi API mereka ke IP virtual load balancer, bukan ke IP node individual. Hal ini krusial agar jika master-01 down, worker node tetap dapat menghubungi kluster melalui master-02 atau master-03.
• SystemdCgroup = true: Konfigurasi penting pada containerd. Tanpa parameter ini, kubelet dan containerd akan menggunakan manajemen cgroup yang berbeda (cgroupfs vs systemd), menyebabkan lonjakan memori yang tidak terkontrol dan OOM Killer pada pod sistem.
• s3ForceURL=http://minio.storage.svc:9000: Menginstruksikan Velero untuk menggunakan penyimpanan S3-compatible lokal (seperti MinIO yang berjalan di dalam kluster atau on-premise) alih-alih AWS S3 publik.

7. Skenario Produksi & Studi Kasus Dunia Nyata

[!TIP] Pada lingkungan produksi finansial berskala tinggi, pastikan Anda mengonfigurasi etcd snapshot otomatis setiap jam menggunakan cronjob eksternal di luar mekanisme Velero sebagai lapis pengaman tambahan (defense in depth).

Dalam studi kasus penanganan Black Friday Traffic pada e-commerce enterprise:

1. Auto-scaling: Kluster dikonfigurasi menggunakan Horizontal Pod Autoscaler (HPA) yang terhubung dengan Prometheus Metrics Server.
2. Network Policies: Mengisolasi namespace database (MySQL/MariaDB) agar hanya dapat diakses oleh pod backend (Node/PHP-FPM/Go) tertentu, mencegah pergerakan lateral penyerang (lateral movement) jika terjadi kompromi pada pod frontend.
3. Ingress Controller Tuning: Menggunakan Nginx Ingress Controller dengan konfigurasi worker_processes auto dan keepalive yang dioptimalkan untuk menahan 50.000 concurrent requests per detik.

8. Common Pitfalls, Anti-Patterns & Solusi

• Anti-Pattern 1: Menggunakan jumlah node master genap (misal: 2 atau 4 node).
  • Dampak: Memicu masalah kuorum Raft dan split-brain.
  • Solusi: Selalu gunakan jumlah node master ganjil (3 atau 5).
• Anti-Pattern 2: Meletakkan etcd dan aplikasi beban berat (seperti database transaksional) pada node fisik yang sama.
  • Dampak: IOPS disk yang tinggi dari aplikasi akan menyebabkan etcd heartbeat timeout, memicu master node not ready massal.
  • Solusi: Pisahkan disk etcd menggunakan NVMe dedicated dengan prioritas I/O tertinggi (ionice).

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji ketahanan kluster HA dan Ingress Controller, gunakan tool k6 untuk simulasi beban HTTP tinggi:

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

export const options = {
  stages: [
    { duration: '2m', target: 1000 }, // Ramp up ke 1000 users
    { duration: '5m', target: 5000 }, // Pertahankan beban tinggi
    { duration: '2m', target: 0 },    // Ramp down
  ],
};

export default function () {
  const res = http.get('https://api.enterprise-app.com/health');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

Tuning parameter sysctl lanjutan pada worker node untuk menangani tingginya koneksi TCP:

# Tambahkan ke /etc/sysctl.conf
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1

10. Checklist Penerapan Produksi & Kesimpulan

• Kuorum etcd terjaga dengan 3 atau 5 node master fisik/virtual terpisah.
• Load balancer eksternal (HAProxy/Cloud LB) dikonfigurasi dengan health check aktif ke port 6443.
• Velero terkonfigurasi dengan backup terjadwal otomatis dan penyimpanan objek terenkripsi.
• Network Policies diterapkan untuk membatasi komunikasi antar namespace.
• Monitoring etcd latency dan API server request duration aktif di Prometheus/Grafana.

Dengan menerapkan arsitektur High Availability multi-master dan strategi Disaster Recovery berbasis Velero yang dipadukan dengan optimasi sistem tingkat lanjut, kluster Kubernetes Anda kini siap menghadapi beban kerja enterprise paling ekstrem sekalipun dengan tingkat ketersediaan 99.999%.