Membangun High Availability Kubernetes Cluster di Lingkungan On-Premise

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap infrastruktur modern, ketergantungan pada public cloud (AWS, GCP, Azure) sering kali menjadi standar de facto. Namun, bagi enterprise dengan regulasi data yang ketat, latensi lokal yang ekstrem, atau efisiensi biaya operasional jangka panjang, membangun kluster Kubernetes on-premise yang High Availability (HA) adalah keharusan mutlak. Kegagalan infrastruktur pada level kontrol (Control Plane) berakibat fatal: aplikasi web, layanan backend (Go/Node.js/PHP-FPM), hingga pemrosesan antrean asinkron (RabbitMQ/Redis) tidak dapat melakukan scaling, pembaruan, atau pemulihan mandiri jika master node tunggal mengalami kegagalan.

Secara historis, banyak arsitek pemula mengandalkan satu node master dengan database etcd tertanam (stacked), yang merupakan single point of failure (SPOF). Ketika node tersebut mati, seluruh kluster kehilangan kemampuan orkestrasi. Di dunia nyata, masalah diperparah oleh hilangnya konektivitas Load Balancer fisik eksternal, konfigurasi DNS internal yang tidak sinkron, serta manajemen penyimpanan persistent (S3/MinIO atau NFS/Ceph) yang terputus saat terjadi failover.

Perbandingan antara kondisi Sebelum dan Sesudah penerapan High Availability On-Premise:

• Sebelum (Single Master / Stacked Etcd):
  • Uptime rata-rata 99.1%.
  • Waktu pemulihan (Recovery Time Objective / RTO) mencapai 45-120 menit saat master node crash.
  • Tidak ada redundansi kontrol plane; pemeliharaan kernel node master menyebabkan downtime layanan web secara keseluruhan.
• Sesudah (Multi-Master HA dengan External etcd & MetalLB):
  • Uptime mencapai 99.99%.
  • RTO < 5 detik berkat leader election otomatis pada etcd dan API Server.
  • Zero-downtime rolling upgrades untuk sistem operasi maupun komponen Kubernetes.

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur Kubernetes HA on-premise memerlukan pemisahan yang ketat antara Control Plane dan Data Plane (Worker Nodes), serta kuorum penyimpanan etcd yang didistribusikan secara independen.

+-----------------------------------------------------------------------------------+
|                        EXTERNAL LOAD BALANCER (HAProxy / Keepalived)              |
|                               Virtual IP: 192.168.10.100                          |
+-----------------------------------------------------------------------------------+
          |                             |                             |
          v                             v                             v
+-------------------+         +-------------------+         +-------------------+
|  Master Node 1    |         |  Master Node 2    |         |  Master Node 3    |:
|  - API Server     |         |  - API Server     |         |  - API Server     |
|  - Controller Mgr |         |  - Controller Mgr |         |  - Controller Mgr |
|  - Scheduler      |         |  - Scheduler      |         |  - Scheduler      |
+-------------------+         +-------------------+         +-------------------+
          \                             |                             /
           +----------------------------+----------------------------+
                                        |
                                        v
+-----------------------------------------------------------------------------------+
|                           EXTERNAL ETCD CLUSTER (3 Nodes)                         |
|                  (Quorum required: 2 nodes active for write operations)           |
+-----------------------------------------------------------------------------------+
                                        |
                                        v
+-----------------------------------------------------------------------------------
|                            WORKER NODES (Nginx / Go / PHP-FPM)                    |
+-----------------------------------------------------------------------------------

Alur Kerja di Balik Layar (Under the Hood):

1. Permintaan Klien Masuk: Klien, utilitas kubectl, atau webhook eksternal mengirimkan permintaan ke Virtual IP (VIP) yang dikelola oleh Keepalived/HAProxy.
2. Distribusi Load Balancer: HAProxy memproksi lalu lintas ke port 6443 pada salah satu dari tiga Master Node yang aktif.
3. Autentikasi & Otorisasi: kube-apiserver memvalidasi token atau sertifikat SSL, kemudian mencatat atau mengambil status kluster dari External etcd Cluster.
4. Konsensus etcd: etcd menggunakan algoritma Raft Consensus. Untuk melakukan perubahan status kluster (misalnya pembuatan Pod baru), mayoritas node etcd (minimal 2 dari 3 node) harus menyetujui transaksi tersebut.
5. Eksekusi Kontrol: kube-controller-manager dan kube-scheduler mendeteksi perubahan status dan menjadwalkan pod ke Worker Nodes yang sesuai.

3. Perbandingan Komparatif / Analisis Pendekatan

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum menjalankan skrip instalasi, pastikan seluruh node (Minimal 3 Master, 3 etcd, dan 2 Worker) memenuhi spesifikasi berikut:

• OS: Ubuntu Server 22.04 LTS (Clean Minimal Installation).
• Spesifikasi Hardware per Node:
  • Master/etcd: 4 vCPU, 8 GB RAM, 50 GB SSD (NVMe sangat disarankan untuk etcd).
  • Worker: 8 vCPU, 16 GB RAM, 100 GB SSD.
• Konfigurasi Jaringan:
  • Matikan Swap secara permanen.
  • Aktifkan modul kernel br_netfilter dan overlay.
  • Pastikan sinkronisasi waktu (chrony atau ntp) aktif di semua node.

# Jalankan perintah ini di SEMUA node (Master, etcd, dan Worker)
sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

sudo sysctl --system

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Konfigurasi External etcd Cluster (Dilakukan di 3 Node etcd)

Install utilitas etcd dan siapkan direktori sertifikat:

sudo apt-get update && sudo apt-get install -y curl etcd-client etcd-server

[!IMPORTANT] Pastikan Anda menghasilkan sertifikat TLS yang valid menggunakan cfssl atau kubeadm init phase certs etcd untuk mengenkripsi komunikasi antar node etcd.

Contoh file konfigurasi /etc/etcd/etcd.conf.yml pada etcd-node-1 (Ubah IP sesuai node masing-masing):

name: 'etcd-node-1'
data-dir: '/var/lib/etcd'
listen-peer-urls: 'https://192.168.10.11:2380'
listen-client-urls: 'https://192.168.10.11:2379,https://127.0.0.1:2379'
initial-advertise-peer-urls: 'https://192.168.10.11:2380'
advertise-client-urls: 'https://192.168.10.11:2379'
initial-cluster: 'etcd-node-1=https://192.168.10.11:2380,etcd-node-2=https://192.168.10.12:2380,etcd-node-3=https://192.168.10.13:2380'
initial-cluster-token: 'etcd-k8s-cluster'
initial-cluster-state: 'new'
client-transport-security:
  cert-file: '/etc/kubernetes/pki/etcd/server.crt'
  key-file: '/etc/kubernetes/pki/etcd/server.key'
  client-cert-auth: true
  trusted-ca-file: '/etc/kubernetes/pki/etcd/ca.crt'
peer-transport-security:
  cert-file: '/etc/kubernetes/pki/etcd/peer.crt'
  key-file: '/etc/kubernetes/pki/etcd/peer.key'
  client-cert-auth: true
  trusted-ca-file: '/etc/kubernetes/pki/etcd/ca.crt'

Langkah 2: Inisialisasi Kubeadm untuk External etcd

Buat file manifest kubeadm-config.yaml pada Master Node pertama:

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: 1.28.0
controlPlaneEndpoint: "192.168.10.100:6443"
etworking:
  podSubnet: "10.244.0.0/16"
  serviceSubnet: "10.96.0.0/16"
etcd:
  external:
    endpoints:
      - https://192.168.10.11:2379
      - https://192.168.10.12:2379
      - https://192.168.10.13:2379
    caFile: /etc/kubernetes/pki/etcd/ca.crt
    certFile: /etc/kubernetes/pki/etcd/client.crt
    keyFile: /etc/kubernetes/pki/etcd/client.key
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: 192.168.10.21
  bindPort: 6443

Jalankan inisialisasi pada master pertama:

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

Langkah 3: Implementasi MetalLB & Nginx Ingress Controller

Setelah kluster terbentuk dan CNI (misal: Calico) terpasang, deploy MetalLB dalam mode Layer 2 untuk menangani Load Balancer lokal:

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb.yaml

Konfigurasi IP Address Pool untuk MetalLB (metallb-config.yaml):

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: production-ip-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.10.200-192.168.10.210
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2-advertisement
  namespace: metallb-system

Terapkan konfigurasi:

kubectl apply -f metallb-config.yaml

Deploy Nginx Ingress Controller:

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

6. Bedah Kode & Penjelasan Detail Baris Kunci

• controlPlaneEndpoint: "192.168.10.100:6443": Baris ini memberi tahu kubeadm bahwa seluruh permintaan API dialamatkan ke Virtual IP (HAProxy/Keepalived), bukan IP node tunggal. Jika node master pertama mati, HAProxy mengalihkan traffic ke master node kedua secara transparan.
• client-transport-security pada etcd: Mengamankan komunikasi peer-to-peer dan klien dengan enkripsi mTLS. Kegagalan konfigurasi path sertifikat akan membuat etcd menolak koneksi dari kube-apiserver, menyebabkan kluster gagal melakukan bootstrap.
• addresses: 192.168.10.200-192.168.10.210 pada MetalLB: Rentang IP lokal fisik di jaringan LAN Anda yang akan dialokasikan secara otomatis ke Service berjenis LoadBalancer (misalnya Nginx Ingress Controller).

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam studi kasus implementasi platform e-commerce berkapasitas tinggi (menangani 50.000 request per detik untuk API berbasis Go dan frontend Node.js):- Isolasi Beban Kerja: Worker nodes dikelompokkan menggunakan Node Selectors dan Taints/Tolerations. Worker berkapasitas memori tinggi dialokasikan khusus untuk caching Redis dan database transaksional, sementara worker dengan CPU tinggi menangani PHP-FPM dan Node.js API pods.

• Zero-Downtime Deployment: Menggunakan strategi RollingUpdate dengan maxSurge: 2 dan maxUnavailable: 0 pada Deployment Kubernetes, memastikan layanan web tidak pernah terputus meskipun terjadi pembaruan versi kontainer secara bersamaan.

8. Common Pitfalls, Anti-Patterns & Solusi

[!WARNING] Anti-Pattern Umum: Menjalankan etcd pada mesin virtual yang sama dengan beban kerja aplikasi yang rakus I/O (seperti database MySQL/MariaDB atau penulisan log berukuran besar). Dampak: Latency disk I/O menyebabkan etcd mengalami timeout, memicu hilangnya kuorum (lost quorum), dan membuat seluruh kluster Kubernetes menjadi read-only atau tidak responsif. Solusi: Selalu gunakan partisi disk terpisah (NVMe dengan IOPS tinggi) atau mesin fisik mandiri khusus untuk kluster etcd.

Kesalahan fatal lainnya adalah mengabaikan manajemen memori kernel Linux untuk conntrack. Pastikan net.netfilter.nf_conntrack_max ditingkatkan pada skala produksi tinggi.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji ketahanan kluster HA, gunakan utilitas k6 atau wrk untuk melakukan stress testing pada Nginx Ingress Controller:

wrk -t12 -c400 -d30s http://192.168.10.200/healthz

Lakukan tuning parameter sysctl pada worker node untuk menangani koneksi web berkecepatan tinggi:

# /etc/sysctl.d/99-kubernetes-tuning.conf
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.ip_local_port_range = 1024 65535

Pantau metrik latency etcd menggunakan Prometheus dan Grafana dengan memantau metrik etcd_cluster_is_leader dan etcd_server_etcd_server_leader_changes_seen_total untuk memastikan stabilitas konsensus.

10. Checklist Penerapan Produksi & Kesimpulan

• Apakah seluruh node etcd menggunakan disk NVMe terdedikasi?
• Apakah sertifikat TLS etcd memiliki masa berlaku yang cukup panjang (atau dikelola otomatis via Cert-Manager)?
• Apakah Virtual IP (HAProxy/Keepalived) telah diuji dengan mematikan salah satu node master secara paksa?
• Apakah kebijakan RBAC dan Network Policies telah diterapkan untuk mengisolasi namespace aplikasi web?
• Apakah sistem backup otomatis untuk etcd snapshot terjadwal setiap 4 jam menggunakan etcdctl snapshot save?

Dengan mengikuti panduan komprehensif ini, Anda telah membangun fondasi infrastruktur Kubernetes on-premise yang tangguh, aman, dan siap menopang beban kerja enterprise berskala besar secara mandiri tanpa ketergantungan pada cloud publik.