Membangun Klaster Kubernetes High Availability untuk Beban Kerja Finansial Mission-Critical

1. Konteks Industri & Analisis Akar Masalah

Dalam industri finansial modern, infrastruktur IT bukan lagi sekadar penunjang operasional, melainkan jantung utama dari entitas bisnis itu sendiri. Sistem perdagangan saham berfrekuensi tinggi (HFT), pemrosesan pembayaran real-time, perbankan inti (core banking), dan platform manajemen risiko menuntut ketersediaan sistem (availability) hingga 99.999% (atau yang dikenal sebagai five nines), yang berarti waktu downtime kumulatif tahunan tidak boleh lebih dari 5 menit 26 detik.

Namun, mengoperasikan beban kerja finansial mission-critical di dalam orkestrasi kontainer menghadirkan tantangan teknis yang masif. Bottleneck paling umum yang sering dihadapi oleh Infrastructure & DevOps Engineers di dunia nyata meliputi:

1. Single Point of Failure (SPOF) pada Control Plane: Mengandalkan satu node master Kubernetes berisiko menghentikan seluruh operasi cluster jika node tersebut mengalami kernel panic, kegagalan penyimpanan, atau gangguan jaringan.
2. Inkonsistensi State pada etcd: Penyimpanan key-value terdistribusi yang menjadi otak Kubernetes rentan terhadap split-brain syndrome jika kuorum (quorum) hilang akibat partisi jaringan (network partition).
3. Latensi Tinggi pada Transaksi Database: Beban kerja finansial sering kali mengintegrasikan stateful database (seperti MySQL/MariaDB cluster atau PostgreSQL) dengan Redis untuk caching dan Message Broker (RabbitMQ/Kafka). Latensi jaringan antar pod atau ketidakstabilan load balancer dapat memicu kegagalan transaksi (transaction timeout).
4. Manajemen Certificate dan Secret yang Rentan: Kegagalan rotasi sertifikat TLS mTLS antar komponen control plane dapat membuat seluruh klaster lumpuh secara mendadak.

Kondisi Sebelum vs Sesudah Penerapan Klaster HA

2. Konsep Inti & Deep Dive Arsitektur

Klaster Kubernetes High Availability (HA) dirancang dengan membuang segala bentuk SPOF. Arsitektur ini dibagi menjadi dua lapis utama: Control Plane HA dan Data Plane (Worker Nodes) yang dihubungkan melalui Layer 4 Load Balancer.

Alur Eksekusi Permintaan (Request Flow Under the Hood)

Ketika seorang developer atau sistem otomatis menjalankan perintah kubectl apply -f deployment.yaml atau aplikasi backend finansial (misal: layanan transfer dana berbasis Go) melakukan pemanggilan API ke cluster, alur data yang terjadi adalah sebagai berikut:

+------------------+
|  Client / App    |
+--------+---------+
         |
         v  [Virtual IP (VIP): 192.168.10.100:6443]
+--------+---------+
|    Keepalived    |
+--------+---------+
         |
         v  [TCP Load Balancing]
+--------+---------+
|     HAProxy      | ---> (Master 1: 6443) ---> [kube-apiserver]
+------------------+ ---> (Master 2: 6443) ---> [kube-apiserver]
                   ---> (Master 3: 6443) ---> [kube-apiserver]
                                                       |
                                                       v
                                            +--------------------+
                                            | etcd Raft Cluster  |
                                            | (Distributed KV)   |
                                            +--------------------+

1. Virtual IP (VIP): Klien mengakses API Server melalui alamat IP virtual yang dikelola secara dinamis oleh Keepalived menggunakan protokol VRRP (Virtual Router Redundancy Protocol).
2. Load Balancing: HAProxy menerima trafik pada port 6443 dan mendistribusikannya secara round-robin atau least-conn ke sekumpulan instance kube-apiserver yang berjalan di setiap node master.
3. API Validation & etcd Storage: kube-apiserver memvalidasi permintaan, lalu membaca atau menulis state klaster ke dalam klaster etcd yang menggunakan konsensus algoritma Raft (membutuhkan jumlah node ganjil, minimal 3 node, untuk toleransi kegagalan 1 node / failure tolerance $N = 2F + 1$).

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun Control Plane HA untuk Kubernetes, terdapat dua pendekatan utama yang umum digunakan di enterprise:

Stacked etcd Topology vs External etcd Topology

[!IMPORTANT] Untuk beban kerja finansial yang memproses ribuan transaksi per detik, pendekatan External etcd Topology sangat disarankan guna menghindari resource contention antara proses deserialisasi API Server dan penyimpanan transaksional etcd.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum memulai instalasi, pastikan seluruh node (Minimal 3 Master, 3 etcd Eksternal jika menggunakan external topology, dan 3 Worker Nodes) memenuhi spesifikasi minimum:

Spesifikasi Minimum Per Node (Production)

• CPU: 4 vCPU (Master), 8 vCPU (Worker)
• RAM: 8 GB (Master), 16 GB+ (Worker)
• Storage: 100 GB SSD NVMe (IOPS tinggi untuk etcd)
• OS: Ubuntu Server 22.04 LTS / RHEL 9
• Network: Jaringan lokal berkecepatan 1 Gbps / 10 Gbps dengan rentang IP statis.

Langkah Persiapan Awal (Dijalankan di SEMUA Node)

Jalankan skrip bash berikut untuk menonaktifkan swap, memuat modul kernel yang dibutuhkan, dan mengonfigurasi parameter sysctl:

#!/bin/bash
set -e

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

# 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 jaringan
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

# 4. Install Container Runtime (containerd)
sudo apt-get update
sudo apt-get install -y containerd.io apt-transport-https ca-certificates curl gpg

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

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

sudo systemctl restart containerd
sudo systemctl enable containerd

echo "Prasyarat sistem berhasil dikonfigurasi!"

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi kubeadm, kubelet, dan kubectl

# Tambahkan repository resmi Kubernetes
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-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/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 2: Konfigurasi HAProxy dan Keepalived pada Load Balancer Nodes (LB1 & LB2)

Instal HAProxy dan Keepalived di dua node terpisah yang bertindak sebagai Load Balancer.

sudo apt-get update && 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
    maxconn 4096

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-frontend
    bind *:6443
    mode tcp
    option tcplog
    default_backend k8s-api-backend

backend k8s-api-backend
    mode tcp
    balance roundrobin
    option tcp-check
    server master1 192.168.10.11:6443 check fall 3 rise 2
    server master2 192.168.10.12:6443 check fall 3 rise 2
    server master3 192.168.10.13:6443 check fall 3 rise 2

Konfigurasi /etc/keepalived/keepalived.conf (pada Master/LB Utama - 192.168.10.21):

vrrp_script check_haproxy {
    script "killall -0 haproxy"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass FinansialSecur3Pass!
    }
    virtual_ipaddress {
        192.168.10.100/24
    }
    track_script {
        check_haproxy
    }
}

Langkah 3: Inisialisasi Klaster Kubernetes dengan kubeadm

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

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.28.0
controlPlaneEndpoint: "192.168.10.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.10.11"
  bindPort: 6443

Jalankan inisialisasi:

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

Simpan token dan certificate key yang dihasilkan untuk menggabungkan master dan worker node berikutnya.

6. Bedah Kode & Penjelasan Detail Baris Kunci

• controlPlaneEndpoint: "192.168.10.100:6443": Baris ini memberi tahu komponen internal Kubernetes bahwa seluruh komunikasi control plane harus diarahkan melalui Virtual IP Load Balancer, bukan langsung ke IP fisik salah satu node master. Jika node master 1 mati, HAProxy dan Keepalived akan mengalihkan trafik ke node master 2 tanpa mengubah konfigurasi di dalam klaster.
• option tcp-check pada HAProxy: Memastikan HAProxy secara aktif melakukan health check berbasis TCP handshake ke port 6443 pada setiap node master. Jika kube-apiserver mengalami freeze, HAProxy langsung mengeluarkan node tersebut dari rotasi beban.
• track_script check_haproxy pada Keepalived: Mekanisme pencegahan split-brain. Jika proses HAProxy di suatu node mati, prioritas Keepalived akan diturunkan, memaksa node cadangan mengambil alih Virtual IP (192.168.10.100).

7. Skenario Produksi & Studi Kasus Dunia Nyata

Pada sistem pembayaran digital berskala nasional, lonjakan transaksi terjadi secara masif pada momen tertentu (seperti Payday atau Flash Sale akhir tahun). Klaster HA ini dirancang untuk menangani lonjakan beban hingga 50.000 requests per second (RPS) pada API Gateway.

• Pemisahan Node Pool: Menggunakan taints and tolerations untuk mendedikasikan worker node khusus untuk database stateful (MySQL/MariaDB cluster dengan proxysql) dan worker node terpisah untuk microservice stateless berbasis Go.
• Network Policies: Mengisolasi namespace finansial (namespace: core-banking) agar hanya dapat diakses melalui ingress controller terproteksi WAF.

8. Common Pitfalls, Anti-Patterns & Solusi

[!WARNING] Kesalahan Fatal #1: Menjalankan etcd di atas penyimpanan jaringan NFS atau HDD konvensional. Solusi: etcd sangat sensitif terhadap disk latency (fsync latencies < 10ms). Selalu gunakan SSD NVMe berperforma tinggi dengan IOPS terdedikasi.

[!WARNING] Kesalahan Fatal #2: Tidak melakukan rotasi sertifikat TLS secara berkala. Solusi: Sertifikat yang dikeluarkan oleh kubeadm memiliki masa aktif 1 tahun. Gunakan sistem otomatisasi seperti cert-manager atau integrasikan cron job untuk memperbarui sertifikat sebelum kedaluwarsa.

9. Benchmark, Metrik Kinerja & Tuning Performa

Lakukan pengujian beban (load testing) pada API Server menggunakan tool k6 atau wrk untuk memastikan HAProxy dan etcd tidak mengalami bottleneck.

Contoh 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
    { duration: '5m', target: 5000 }, // Sustained load
    { duration: '2m', target: 0 },    // Ramp-down
  ],
};

export default function () {
  const url = 'https://192.168.10.100:6443/healthz';
  const params = {
    headers: {
      'Authorization': 'Bearer <YOUR_SERVICE_ACCOUNT_TOKEN>',
    },
    insecureSkipTLSVerify: true,
  };
  const res = http.get(url, params);
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

Tuning Kernel Linux untuk High Concurrency (/etc/sysctl.conf):

fs.file-max = 2097152
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan klaster Kubernetes finansial ini ke lingkungan live production, pastikan Anda telah mencentang seluruh item dalam daftar berikut:

• Semua node master dan worker menggunakan versi kernel dan OS yang seragam.
• Virtual IP Keepalived teruji melakukan failover dalam waktu < 3 detik.
• Backup otomatis etcd dijadwalkan setiap 30 menit ke object storage terenkripsi (S3/MinIO).
• WAF dan Intrusion Detection System (Fail2ban/CrowdSec) aktif pada edge nodes.
• Monitoring Prometheus & Grafana aktif dengan alert kritis via PagerDuty/Telegram untuk metrik etcd_server_leader_changes_total dan kube_apiserver_request_duration_seconds.

Dengan menerapkan arsitektur Multi-Master High Availability ini, infrastruktur finansial Anda dijamin memiliki ketahanan operasional tingkat enterprise yang mampu menghadapi kegagalan perangkat keras maupun lonjakan transaksi ekstrem tanpa zero downtime.