High Availability Kubernetes Cluster dengan Cilium CNI dan ArgoCD

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur cloud-native modern, kebutuhan akan klaster Kubernetes yang memiliki ketersediaan tinggi (High Availability atau HA) bukan lagi sebuah kemewahan, melainkan prasyarat mutlak bagi aplikasi berbasis web berskala enterprise. Baik Anda menjalankan arsitektur monolitik yang di-containerize dengan PHP-FPM dan Nginx, hingga ekosistem microservices kompleks berbasis Node.js dan Go yang dihubungkan melalui service mesh, fondasi infrastruktur di bawahnya harus tahan terhadap kegagalan node, lonjakan traffic mendadak, serta ancaman keamanan jaringan.

Secara historis, administrator infrastruktur menghadapi berbagai tantangan kronis pada lapisan networking Kubernetes tradisional (seperti Flannel atau Calico berbasis iptables). Aturan iptables yang membengkak hingga puluhan ribu baris pada klaster skala menengah menyebabkan latensi packet-processing meningkat drastis ($O(n)$ time complexity), membebani CPU kernel, serta menyulitkan proses audit keamanan jaringan. Selain itu, pengelolaan service mesh eksternal seperti Istio sering kali menduplikasi enkripsi mTLS di tingkat application/sidecar proxy, yang menguras memori dan menambah hop latency pada setiap permintaan HTTP/WebSocket.

Analisis akar masalah dari kegagalan operasional web server modern di dalam Kubernetes sering kali berakar pada:

1. Keterbatasan iptables: Lonjakan koneksi TCP dari ribuan klien web yang masuk melalui Nginx Ingress Controller menyebabkan saturasi CPU pada penelusuran aturan netfilter.
2. Kompleksitas Multi-Master Control Plane: Kegagalan pada load balancer eksternal (seperti HAProxy/Keepalived) yang mengarah ke API Server sering menyebabkan split-brain atau downtime total saat control plane node mengalami kegagalan perangkat keras.
3. Kurangnya Observabilitas Jaringan Bawaan: Kesulitan melacak asal paket data yang melintasi namespace ketika terjadi serangan DDoS pada lapisan transport.

Dengan mengintegrasikan Cilium CNI berbasis eBPF (Extended Berkeley Packet Filter) dan manajemen Continuous Delivery deklaratif menggunakan ArgoCD, kita dapat mentransformasi klaster Kubernetes menjadi mesin infrastruktur yang sangat cepat, aman, dan dapat diskalakan secara otomatis.

Perbandingan Kondisi: Sebelum vs Sesudah Penerapan

2. Konsep Inti & Deep Dive Arsitektur

Untuk merancang klaster yang kokoh, kita harus memahami bagaimana komponen-komponen inti berinteraksi di bawah tenda (under the hood).

Arsitektur eBPF dan Cilium CNI

Cilium mengubah cara kernel Linux memproses paket jaringan. Daripada melewatkan paket melalui seluruh tumpukan jaringan Linux (Socket Layer $ ightarrow$ Netfilter/iptables $ ightarrow$ Routing $ ightarrow$ Network Device), Cilium menyuntikkan program eBPF langsung ke titik-titik kait (hooks) kernel seperti XDP (eXpress Data Path) dan TC (Traffic Control).

+-----------------------------------------------------------------------+
|                           Linux Kernel Host                           |+
|                                                                       |
|  +------------------+         +------------------+                    |
|  |   Pod A Namespace|         |   Pod B Namespace|                    |
|  +--------+---------+         +--------+---------+                    |
|           | (veth)                     | (veth)                       |
|           v                            v                              |
|  +-------------------------------------------------+                  |
|  |                Root Network Namespace           |                  |
|  |                                                 |                  |
|  |   [ eBPF XDP / TC Hooks (Cilium Datapath) ]     |                  |
|  |         | (Direct BPF Map Lookup O(1))          |                  |
|  |         v                                       |                  |
|  |   [ Native Routing / Encapsulation (Geneve/VXLAN)|                 |
|  +-------------------------+-----------------------+                  |
|                            |                                          |
+----------------------------|------------------------------------------+
                             v
                 [ Physical Network Fabric ]

Alur Data dan Eksekusi Paket

1. Keluarnya Paket dari Pod: Ketika aplikasi web (misalnya Node.js atau PHP-FPM) mengirimkan respons HTTP, paket keluar melalui virtual ethernet (veth) pair menuju root namespace.
2. Intersepsi eBPF: Program eBPF yang terikat pada TC hook langsung mencegat paket tersebut.
3. Pencarian Map: Berdasarkan identitas keamanan sumber dan tujuan, program melakukan pencarian di dalam eBPF hash maps dengan kompleksitas $O(1)$.
4. Pengiriman Langsung: Paket langsung diteruskan ke interface fisik atau dienkapsulasi menggunakan protokol terowongan (VXLAN atau Geneve) jika melintasi node berbeda, tanpa pernah menyentuh aturan iptables.

Control Plane Multi-Master dengan HA

Klaster production-grade memerlukan Control Plane minimal 3 node master untuk memenuhi toleransi kegagalan kuorum etcd ($N/2 + 1$). Ketersediaan tinggi API Server dicapai melalui kombinasi load balancer lokal (seperti kube-vip atau HAProxy/Keepalived) di depan port 6443 pada masing-masing master node.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun jaringan Kubernetes dan manajemen deployment, terdapat beberapa pilihan arsitektur yang sering menjadi perdebatan di kalangan Principal Engineer. Berikut adalah analisis komparatif mendalam:

Perbandingan CNI: Cilium vs Calico vs Flannel

[!TIP] Gunakan Cilium jika klaster Anda menargetkan throughput tinggi, latensi rendah, serta arsitektur Zero-Trust Security tanpa beban tambahan dari sidecar proxy yang memakan memori RAM pod web Anda.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum mengeksekusi instalasi klaster, pastikan lingkungan infrastruktur Anda (baik bare-metal maupun cloud instance seperti AWS EC2 / GCP Compute Engine) memenuhi spesifikasi berikut:

Spesifikasi Minimum Node

• Control Plane Nodes (Minimal 3 Node): 4 vCPU, 8 GB RAM, 50 GB SSD NVMe.
• Worker Nodes (Minimal 3 Node): 8 vCPU, 16 GB RAM, 100 GB SSD NVMe (untuk menampung database, Redis, Nginx Ingress, dan pod aplikasi web).
• Sistem Operasi: Ubuntu Server 22.04 LTS / 24.04 LTS atau Rocky Linux 9 (Kernel Linux minimal versi 5.15 atau lebih baru agar fitur eBPF berjalan optimal).

Persiapan Kernel dan Parameter Jaringan (Dijalankan di SEMUA Node)

Masuk ke setiap node melalui SSH dan jalankan perintah berikut untuk mengaktifkan modul kernel yang dibutuhkan oleh Kubernetes dan Cilium:

# Memuat modul kernel yang diperlukan
sudo modprobe overlay
sudo modprobe br_netfilter

# Membuat konfigurasi agar modul tetap aktif setelah reboot
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

# Mengatur parameter sysctl untuk jaringan Kubernetes
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

# Menerapkan parameter sysctl tanpa reboot
sudo sysctl --system

Menonaktifkan Swap

Kubernetes memerlukan penonaktifan swap agar penjadwalan memori pod dapat diprediksi secara akurat:

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

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi Container Runtime (containerd)

Kita menggunakan containerd sebagai container runtime standar industri.

# Install prasyarat
sudo apt-get update
sudo apt-get install -y curl gnupg lsb-release apt-transport-https ca-certificates

# Tambahkan GPG key resmi Docker/containerd
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 containerd
echo \
  "deb [arch=$(dpkg --print-architecture) 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

# Install containerd
sudo apt-get update
sudo apt-get install -y containerd.io

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

# Restart dan aktifkan service containerd
sudo systemctl restart containerd
sudo systemctl enable containerd

Langkah 2: Instalasi kubeadm, kubelet, dan kubectl

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

# Tambahkan repository apt Kubernetes v1.28
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

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

Langkah 3: Inisialisasi Multi-Master Control Plane dengan Kubeadm

Pada node Master Pertama, buat file konfigurasi kubeadm-config.yaml untuk menginisialisasi klaster dengan menonaktifkan CNI bawaan (karena kita akan memasang Cilium).

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.28.0
controlPlaneEndpoint: "k8s-cluster-lb.internal:6443"
etworking:
  podSubnet: "10.244.0.0/16"
  serviceSubnet: "10.96.0.0/12"
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd

Jalankan inisialisasi pada master pertama:

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

Simpan token dan certificate key yang dihasilkan untuk menggabungkan master node kedua dan ketiga serta worker node.

Atur 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 4: Instalasi Cilium CNI menggunakan Cilium CLI

Unduh dan pasang Cilium CLI pada node pengelola:

CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
CLI_ARCH=amd64
if [ "$(uname -m)" = "aarch64" ]; then CLI_ARCH=arm64; fi
curl -L --fail --remote-name https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz
sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin
rm cilium-linux-${CLI_ARCH}.tar.gz

Instal Cilium ke dalam klaster dengan mengaktifkan fitur kubeProxyReplacement untuk performa eBPF penuh:

cilium install \
  --set kubeProxyReplacement=strict \
  --set k8sServiceHost=k8s-cluster-lb.internal \
  --set k8sServicePort=6443 \
  --set ipam.mode=kubernetes

Verifikasi instalasi Cilium:

cilium status --wait

Langkah 5: Setup Continuous Delivery dengan ArgoCD

Pasang ArgoCD pada namespace terpisah untuk mengelola seluruh deployment aplikasi web (seperti Nginx, PHP-FPM, Redis, dan PostgreSQL) secara GitOps.

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Ubah service ArgoCD Server menjadi NodePort atau LoadBalancer agar dapat diakses oleh administrator:

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "NodePort"}}'

Dapatkan password awal untuk login ke UI ArgoCD:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
echo

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah konfigurasi penting dari kubeadm-config.yaml dan parameter Cilium yang baru saja dieksekusi:

1. controlPlaneEndpoint: "k8s-cluster-lb.internal:6443"
   • Fungsi: Menentukan alamat DNS/IP dari load balancer eksternal yang berada di depan node-node master. Memastikan jika satu master node mati, kubelet dan worker node tetap dapat berkomunikasi dengan API Server melalui node master yang lain.
2. podSubnet: "10.244.0.0/16"
   • Fungsi: Alokasi blok IP CIDR untuk seluruh pod yang berjalan di dalam klaster. Cilium akan memecah subnet ini menjadi Node Allocations untuk masing-masing worker node.
3. --set kubeProxyReplacement=strict (pada perintah cilium install)
   • Fungsi krusial: Menggantikan fungsi kube-proxy sepenuhnya menggunakan eBPF maps. Dengan parameter strict, Cilium mengambil alih penanganan ClusterIP, NodePort, dan LoadBalancer secara langsung di level kernel, menghilangkan penggunaan iptables sepenuhnya.

[!WARNING] Jangan pernah mengubah kubeProxyReplacement menjadi strict jika kernel Linux di node Anda lebih tua dari versi 5.4, karena fitur eBPF socket load balancing yang dibutuhkan tidak akan tersedia dan menyebabkan kegagalan routing jaringan.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Studi Kasus: E-Commerce Flash Sale dengan Ribuan Request Per Detik (RPS)

Sebuah platform e-commerce enterprise mengalami lonjakan traffic hingga 50.000 RPS pada saat flash sale. Arsitektur di dalam klaster menggunakan:

• Ingress Layer: Nginx Ingress Controller yang dioptimalkan dengan worker process yang terikat pada CPU core spesifik.
• Application Tier: Puluhan pod Node.js dan PHP-FPM yang terhubung ke Redis Cache (cluster mode) dan database MySQL master-replica.
• Networking (Cilium): Menggunakan eBPF Host Routing (native-routing-cidr) untuk melewatkan paket langsung ke network interface fisik tanpa enkapsulasi VXLAN, memangkas latensi jaringan hingga 0.3 milidetik per request.
• GitOps (ArgoCD): Saat terjadi peluncuran fitur baru atau hotfix beban backend, ArgoCD secara otomatis melakukan rolling update dengan strategi Canary Deployment tanpa memutus koneksi WebSocket aktif yang sedang terhubung ke klien.

8. Common Pitfalls, Anti-Patterns & Solusi

1. Anti-Pattern: Membiarkan kube-proxy tetap aktif bersamaan dengan Cilium eBPF Mode.
   • Dampak: Terjadi konflik aturan antara eBPF maps dan iptables yang dikelola oleh kube-proxy, mengakibatkan paket jaringan terlempar ke loop tak berujung atau koneksi TCP sering timeout.
   • Solusi: Pastikan kubeProxyReplacement diaktifkan dan kube-proxy dinonaktifkan atau dihapus dari DaemonSet klaster.
2. Pitfall: Kurangnya Alokasi File Descriptors pada Kernel untuk Concurrency Tinggi.
   • Dampak: Website berbasis web server Nginx / Node.js sering mengalami error Too many open files saat traffic tinggi.
   • Solusi: Tingkatkan batas maksimal file descriptor di /etc/security/limits.conf untuk pengguna sistem.
3. Pitfall: Mengabaikan Sinkronisasi Waktu (NTP) pada Multi-Master Control Plane.
   • Dampak: Terjadi kegagalan kuorum etcd karena perbedaan waktu (clock drift) antar node master.
   • Solusi: Selalu jalankan layanan NTP (chrony atau systemd-timesyncd) di seluruh node klaster.

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 sederhana untuk menguji endpoint web aplikasi di dalam klaster:

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

export const options = {
  stages: [
    { duration: '1m', target: 1000 }, // Ramp-up ke 1000 virtual users
    { duration: '3m', target: 5000 }, // Tahan beban di 5000 virtual users
    { duration: '1m', target: 0 },    // Ramp-down
  ],
};

export default function () {
  const res = http.get('https://app.enterprise.internal/api/v1/products');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 50ms': (r) => r.timings.duration < 50,
  });
  sleep(1);
}

Tuning Performa Kernel untuk Network Stack:

Tambahkan parameter berikut ke /etc/sysctl.d/99-custom-tuning.conf untuk menangani koneksi TCP masif:

# Meningkatkan ukuran backlog antrian socket TCP
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# Mengaktifkan TCP TIME_WAIT recycling/reuse untuk koneksi web berkecepatan tinggi
net.ipv4.tcp_tw_reuse = 1

# Memperluas rentang port ephemeral lokal
net.ipv4.ip_local_port_range = 1024 65535

Terapkan perubahan dengan perintah:

sudo sysctl --preload /etc/sysctl.d/99-custom-tuning.conf

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan klaster Kubernetes Anda ke lingkungan produksi live, verifikasi seluruh poin dalam checklist berikut:

• Kernel Linux: Minimal versi 5.15+ dengan modul eBPF, overlay, dan br_netfilter aktif di semua node.
• Multi-Master HA: Load balancer eksternal atau kube-vip terkonfigurasi dengan benar untuk mendistribusikan traffic ke 3+ API Server.
• Cilium CNI: Terpasang dengan mode kubeProxyReplacement=strict dan verifikasi cilium status menunjukkan hasil serba hijau (healthy).
• GitOps ArgoCD: Terhubung ke repository Git privat yang aman dengan manajemen hak akses berbasis RBAC.
• Keamanan & Enkripsi: Mengaktifkan Transparent Encryption pada Cilium untuk lalu lintas antar pod secara in-flight.
• Observabilitas: Integrasi Cilium Hubble UI/CLI untuk pemantauan flow jaringan secara real-time.
• Backup etcd: Menjadwalkan snapshot otomatis untuk etcd guna mitigasi bencana (Disaster Recovery).

Dengan mematuhi arsitektur dan panduan komprehensif ini, Anda telah membangun sebuah klaster Kubernetes enterprise yang tidak hanya memiliki ketersediaan tinggi, tetapi juga performa jaringan secepat kilat berkat kekuatan teknologi eBPF dan otomatisasi GitOps yang andal.