Membangun Kluster Kubernetes High Availability untuk Beban Kerja Finansial

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap teknologi finansial (FinTech) modern, kegagalan infrastruktur bukanlah sekadar masalah teknis, melainkan bencana finansial dan reputasional. Sistem perbankan inti, pemrosesan pembayaran real-time, dan platform trading algoritmik menuntut ketersediaan layanan hingga five nines (99.999%), yang berarti total waktu downtime kumulatif tidak boleh lebih dari 5,26 menit dalam setahun. Pada beban kerja finansial, latensi tinggi atau kegagalan node tunggal (single point of failure) pada control plane Kubernetes dapat menyebabkan transaksi time-out, inkonsistensi data buku besar (ledger), hingga kerugian finansial masif akibat kegagalan eksekusi order pasar.

Secara historis, banyak institusi keuangan menjalankan aplikasi monolitik pada mesin virtual (VM) tradisional dengan arsitektur Active-Passive tradisional. Meskipun terlihat sederhana, pendekatan ini rentan terhadap latensi failover yang tinggi—seringkali memakan waktu beberapa menit hingga layanan kembali normal. Di sisi lain, adopsi Kubernetes tanpa perencanaan High Availability (HA) yang matang justru menciptakan jebakan baru. Jika control plane standar dengan satu node master mengalami kegagalan hardware, seluruh kluster kehilangan kemampuan untuk menjadwalkan pod baru, mengubah state objek, atau memproses permintaan API, meskipun node worker yang menjalankan aplikasi masih hidup.

Sebelum penerapan arsitektur HA berbasis stacked etcd atau external etcd terdistribusi, kegagalan jaringan atau disk pada server master mengakibatkan penghentian total layanan transaksi. Setelah migrasi ke kluster Kubernetes High Availability multi-master dengan etcd terdistribusi, sistem mampu mentoleransi kegagalan (failure tolerance) hingga $f = lfloor (n-1) / 2 floor$ di mana $n$ adalah jumlah node etcd (umumnya 3 atau 5 node). Jika satu node master mati, node master lainnya secara instan mengambil alih beban API Server tanpa gangguan pada lalu lintas transaksi finansial yang sedang berjalan.

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur Kubernetes High Availability bertumpu pada redundansi komponen Control Plane dan penyimpanan konsensus terdistribusi (etcd). Dalam desain ini, tidak ada satu pun komponen yang menjadi titik tunggal kegagalan. Komponen utama terdiri dari Load Balancer eksternal (menggunakan HAProxy dan Keepalived), minimal 3 node master yang menjalankan kube-apiserver, kube-controller-manager, kube-scheduler, dan kluster etcd, serta sekumpulan node worker.

Alur eksekusi permintaan (request lifecycle) pada arsitektur finansial ini dirancang untuk menjamin keamanan dan konsistensi data:

[ Client / FinTech App ]
          │
          ▼
[ External Load Balancer (HAProxy / Keepalived) ]
          │
          ├───────────────────────┬───────────────────────┐
          ▼                       ▼                       ▼
   [ Master Node 1 ]       [ Master Node 2 ]       [ Master Node 3 ]
   (API Server / etcd)     (API Server / etcd)     (API Server / etcd)
          │                       │                       │
          └───────────────────────┴───────────────────────┘
                                  │
                          [ Raft Consensus ]

1. Client Request: Permintaan API dari aplikasi klien atau CI/CD pipeline dikirim ke Virtual IP (VIP) yang dikelola oleh Keepalived.
2. Load Balancing: HAProxy mendistribusikan lalu lintas secara merata ke port 6443 dari ketiga kube-apiserver pada node master.
3. API Validation: kube-apiserver melakukan autentikasi, otorisasi, dan validasi permintaan sebelum mencatat state objek ke kluster etcd.
4. Consensus Protocol: etcd menggunakan algoritma konsensus Raft untuk memastikan bahwa perubahan state direplikasi ke mayoritas node etcd sebelum transaksi dianggap sukses (commit). Hal ini krusial untuk mencegah split-brain scenario pada data finansial.
5. Scheduling & Reconciliation: kube-controller-manager dan kube-scheduler bekerja secara aktif namun terkoordinasi (hanya satu leader aktif yang memimpin pada satu waktu melalui mekanisme lease) untuk menjadwalkan pod ke node worker.

3. Perbandingan Komparatif / Analisis Pendekatan

Memilih topologi etcd adalah keputusan arsitektural paling krusial saat membangun kluster Kubernetes HA untuk finansial. Berikut adalah analisis mendalam perbandingan antara pendekatan Stacked etcd dan External etcd.

[!WARNING] Untuk beban kerja finansial, latensi penulisan disk (fsync) pada etcd tidak boleh melebihi 10-15 milidetik. Gunakan penyimpanan NVMe berperforma tinggi dengan Write-Back Cache yang dilindungi baterai (Battery-Backed Write Cache) untuk menghindari korupsi data pada kluster etcd.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melakukan bootstrap kluster, pastikan seluruh node (minimal 3 Master dan 2 Worker) memenuhi spesifikasi teknis dan konfigurasi kernel berikut:

• Spesifikasi Hardware per Node: Minimal 4 vCPU, 16 GB RAM, 100 GB NVMe SSD (untuk etcd).
• Sistem Operasi: Ubuntu Server 22.04 LTS x86_64 dengan kernel Linux minimal versi 5.15.
• Jaringan: Port berikut harus dibuka pada firewall (UFW / Cloud Security Group):
  • Master Node: 6443 (Kubernetes API), 2379-2380 (etcd client/peer), 10250 (Kubelet), 10259 (Scheduler), 10257 (Controller Manager).
  • Worker Node: 10250 (Kubelet), 30000-32767 (NodePort Services).

Lakukan konfigurasi dasar pada seluruh node (Master dan Worker):

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

# Muat modul kernel yang diperlukan untuk Containerd
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# Konfigurasi sysctl agar iptables melihat bridged traffic
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-netfilter-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-netfilter-call-ip6tables = 1
EOF

sudo sysctl --system

Instal runtime container containerd dan konfigurasi SystemdCgroup:

sudo apt-get update && sudo apt-get install -y containerd apt-transport-https ca-certificates curl
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

Instal kubeadm, kubelet, dan kubectl versi spesifik (misal: v1.28.2):

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/ /etc/apts/sources.list.d/kubernetes.list' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet=1.28.2-1.1 kubeadm=1.28.2-1.1 kubectl=1.28.2-1.1
sudo apt-mark hold kubelet kubeadm kubectl

5. Panduan Implementasi Langkah demi Langkah

Langkah 5.1: Konfigurasi Load Balancer Eksternal (HAProxy & Keepalived)

Pada dua node load balancer terpisah (atau menggunakan load balancer cloud), instal HAProxy dan Keepalived untuk menyediakan Virtual IP (VIP) 192.168.10.100.

Konfigurasi /etc/keepalived/keepalived.conf pada Load Balancer Primary:

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 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass FinTechSecPass99
    }
    virtual_ipaddress {
        192.168.10.100/24
    }
    track_script {
        check_haproxy
    }
}

Konfigurasi /etc/haproxy/haproxy.cfg pada kedua node Load Balancer:

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 kubernetes-apiserver-frontend
    bind 192.168.10.100:6443
    mode tcp
    option tcplog
    default_backend kubernetes-apiserver-backend

backend kubernetes-apiserver-backend
    mode tcp
    option tcp-check
    balance roundrobin
    server master-01 192.168.10.11:6443 check fall 3 rise 2
    server master-02 192.168.10.12:6443 check fall 3 rise 2
    server master-03 192.168.10.13:6443 check fall 3 rise 2

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

Buat file konfigurasi kubeadm kubeadm-config.yaml pada master-01:

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.28.2
controlPlaneEndpoint: "192.168.10.100:6443"
etworking:
  podSubnet: "10.244.0.0/16"
  serviceSubnet: "10.96.0.0/12"
etcd:
  local:
    serverCertSANs:
      - "192.168.10.11"
      - "localhost"
    peerCertSANs:
      - "192.168.10.11"
      - "localhost"
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: "192.168.10.11"
  bindPort: 6443

Jalankan inisialisasi pada master-01:

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

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

Konfigurasikan akses kubectl untuk pengguna lokal:

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

Langkah 5.3: Instalasi CNI (Calico Network Policy)

Untuk keamanan tingkat finansial, gunakan Calico guna menerapkan NetworkPolicies ketat antar namespace:

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml

Langkah 5.4: Konfigurasi Ingress Controller & Cert-Manager

Pasang NGINX Ingress Controller yang diperkuat dengan TLS termination:

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

Instal cert-manager untuk otomatisasi sertifikat SSL/TLS perbankan:

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.1/cert-manager.yaml

Buat Issuer Let's Encrypt Production (issuer-prod.yaml):

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

kubectl apply -f issuer-prod.yaml

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah parameter penting dalam file kubeadm-config.yaml yang krusial untuk stabilitas finansial:

• controlPlaneEndpoint: "192.168.10.100:6443": Baris ini memaksa seluruh komponen internal (kubelet, controller manager) untuk berkomunikasi melalui Virtual IP load balancer alih-alih IP node spesifik. Jika master-01 down, koneksi otomatis beralih tanpa perlu regenerasi sertifikat.
• podSubnet: "10.244.0.0/16": Menentukan alokasi blok IP internal pod. Pastikan rentang ini tidak bertabrakan dengan jaringan VLAN internal perusahaan (corporate intranet) untuk menghindari masalah routing pada service mesh.
• serverCertSANs: Menambahkan IP spesifik node master ke dalam Subject Alternative Name sertifikat SSL internal API Server, memastikan komunikasi terenkripsi mTLS tetap valid saat diakses langsung melalui IP lokal node.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Pada sistem pemrosesan pembayaran akhir bulan (End-of-Month Payroll Settlement), kluster finansial ini mengalami lonjakan beban hingga 45.000 transaksi per detik (TPS). Untuk menjamin ketersediaan latensi rendah (< 20ms), arsitektur menerapkan:

1. Pod Disruption Budget (PDB):

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-engine-pdb
  namespace: financial-prod
spec:
  minAvailable: 80%
  selector:
    matchLabels:
      app: payment-engine

PDB ini memastikan bahwa selama pemeliharaan node atau rolling update, setidaknya 80% pod pemrosesan pembayaran tetap berjalan aktif, mencegah kegagalan transaksi massal.

2. Resource Quotas & LimitRanges pada namespace transaksi untuk mencegah pod rogue menghabiskan memori node yang dapat memicu OOM (Out Of Memory) Killer pada daemon sistem krusial.

8. Common Pitfalls, Anti-Patterns & Solusi

• Anti-Pattern 1: Menjalankan kluster etcd dan beban kerja aplikasi berat pada node worker yang sama.
  • Solusi: Isolasi total control plane dan etcd menggunakan taints and tolerations, serta pisahkan disk etcd ke storage controller fisik mandiri.
• Anti-Pattern 2: Menggunakan satu node Load Balancer tanpa Keepalived.
  • Solusi: Selalu gunakan arsitektur Active-Passive berpasangan dengan VIP menggunakan Keepalived atau BGP Anycast untuk menghindari Single Point of Failure pada lapisan jaringan masuk.
• Pitfalls 3: Mengabaikan pemantauan kesehatan etcd (etcd_high_internal_queue_latency).
  • Solusi: Pantau metrik Prometheus secara ketat untuk etcd_disk_backend_commit_duration_seconds_bucket.

9. Benchmark, Metrik Kinerja & Tuning Performa

Pengujian beban (load testing) dilakukan menggunakan tool k6 untuk mensimulasikan lonjakan transaksi pembayaran ganda. Parameter kernel Linux pada node master disetel ulang untuk menangani koneksi TCP masif di /etc/sysctl.d/99-fintech-performance.conf:

# Tingkatkan batas file descriptor untuk koneksi API Server masif
fs.file-max = 2097152

# Optimasi TCP backlog dan buffer
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 16384
net.core.netdev_max_backlog = 16384

# Penyesuaian port ephemeral
net.ipv4.ip_local_port_range = 1024 65535

# Nonaktifkan timewait assassination protection dan aktifkan reuse
net.ipv4.tcp_tw_reuse = 1

Terapkan perubahan dengan perintah:

sudo sysctl --preload /etc/sysctl.d/99-fintech-performance.conf

Metrik kunci yang harus dipantau melalui Grafana/Prometheus mencakup:

• apiserver_request_duration_seconds: Latensi respons API (Target p99 < 50ms).
• etcd_server_leader_changes_seen_total: Perubahan leader etcd harus mendekati nol selama operasi normal.
• container_cpu_usage_seconds_total: Penggunaan CPU pod aplikasi finansial.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis kluster Kubernetes High Availability ini ke lingkungan Live Production finansial, pastikan seluruh item dalam checklist berikut telah diverifikasi:

• Tiga node Master terinisialisasi dengan kluster etcd Raft yang stabil.
• Load Balancer HAProxy + Keepalived terkonfigurasi dengan Failover otomatis.
• Penyimpanan etcd menggunakan NVMe dengan Write-Back Cache terlindungi.
• Kebijakan jaringan (Calico NetworkPolicies) aktif mengisolasi namespace finansial.
• Cert-manager dan NGINX Ingress dikonfigurasi dengan enkripsi mTLS/TLS 1.3.
• Sistem backup otomatis etcd (etcdctl snapshot save) berjalan setiap 1 jam ke object storage terenkripsi (MinIO/AWS S3).
• Sistem monitoring (Prometheus, Grafana, Alertmanager) aktif memantau latensi dan anomali disk.

Dengan menerapkan arsitektur ultra-mendalam ini, infrastruktur Kubernetes Anda tidak hanya memiliki ketahanan tinggi terhadap kegagalan perangkat keras, tetapi juga memenuhi standar audit kepatuhan industri finansial yang ketat.