Membangun Klaster Kubernetes High Availability di AWS EKS dengan GitOps ArgoCD
1. Konteks Industri & Analisis Akar Masalah
Dalam lanskap pengembangan web modern dan arsitektur sistem terdistribusi, kebutuhan akan ketersediaan tinggi (High Availability / HA) dan pengiriman perangkat lunak yang cepat serta andal bukanlah sekadar pilihan mewah, melainkan keharusan mutlak. Bayangkan sebuah aplikasi e-commerce berskala besar yang melayani jutaan pengguna bersamaan dengan backend berbasis Go dan Node.js, ditenagai oleh database relasional MySQL yang terdistribusi, serta menggunakan Redis untuk manajemen session dan caching tingkat lanjut. Ketika terjadi lonjakan traffic mendadak, kegagalan pada proses deployment manual dapat mengakibatkan downtime yang merugikan secara finansial dan merusak reputasi merek.
Secara historis, administrator infrastruktur mengandalkan skrip Bash kustom atau alat CI/CD tradisional seperti Jenkins untuk melakukan push kode dan konfigurasi langsung ke klaster Kubernetes. Pendekatan ini memiliki akar masalah yang fatal: configuration drift (penyimpangan konfigurasi antara apa yang ada di repositori kode dengan kondisi nyata di klaster), kurangnya jejak audit yang jelas, dan tingginya risiko human error saat melakukan eksekusi perintah kubectl apply secara manual di lingkungan produksi. Jika terjadi kegagalan pada versi baru, proses rollback sering kali dilakukan secara panik, memakan waktu lama, dan tidak jarang memperparah masalah.
Untuk mengatasi hal ini, industri beralih ke paradigma GitOps. Dengan menjadikan Git sebagai single source of truth untuk seluruh status infrastruktur dan aplikasi, setiap perubahan dilacak, direview melalui Pull Request, dan disinkronkan secara otomatis oleh mesin Continuous Delivery seperti ArgoCD ke dalam klaster AWS EKS (Elastic Kubernetes Service). Tabel di bawah ini merangkum perbandingan antara metode tradisional dan pendekatan GitOps berbasis ArgoCD:
| Parameter | Metode Tradisional (CI/CD Push-based) | Pendekatan GitOps (ArgoCD Pull-based) |
|---|---|---|
| Sumber Kebenaran | Skrip CI/CD, state lokal developer, server Jenkins | Repositori Git (Git as Single Source of Truth) |
| Keamanan Kredensial | Kredensial klaster disimpan di server CI/CD luar | Klaster menarik (pull) perubahan, token akses terbatas |
| Deteksi Drift | Sulit dideteksi, butuh pemindaian manual | Otomatis terus-menerus mendeteksi perbedaan aktual vs git |
| Kecepatan Rollback | Manual kubectl rollout undo, rawan kesalahan |
Otomatis atau satu klik tombol di UI/CLI ArgoCD |
| Jejak Audit | Tersebar di log sistem CI/CD eksternal | Riwayat commit Git yang permanen dan transparan |
Dengan memadukan ketahanan AWS EKS multi-node group dan otomatisasi sinkronisasi ArgoCD, kita menciptakan fondasi infrastruktur web modern yang tangguh, aman, dan siap menghadapi traffic ribuan request per detik.
2. Konsep Inti & Deep Dive Arsitektur
Arsitektur yang kita bangun berfokus pada pemisahan beban kerja (workload separation) dan ketahanan infrastruktur. Di dalam AWS EKS, kita mengonfigurasi beberapa Node Group yang mendistribusikan pod aplikasi web, layanan database, dan controller ArgoCD ke zona ketersediaan (Availability Zones / AZ) yang berbeda guna menghindari titik kegagalan tunggal (Single Point of Failure / SPOF).
+-------------------------------------------------------------------------+
| AWS Cloud (Multi-AZ) |
| |
| +-------------------------------------------------------------------+ |
| | AWS EKS Cluster |
| | |
| | +--------------------+ +----------------------------------+ |
| | | System Node Group | | Application Node Group | |
| | | - CoreDNS | | - Backend API (Go/Node.js) | |
| | | - AWS Load Balancer| | - Frontend (HTML/JS/Nginx) | |
| | | - ArgoCD Controller| | - Redis & Caching Layers | |
| | +--------------------+ +----------------------------------+ |
| | ^ | |
| +------------|--------------------------------|-----------------+
| | (Sync & Monitor) | (AWS ALB Ingress)
| +--------------+ v |
| | GitHub Repo |<----------------+ User Traffic |
| | (GitOps) | (Route53 -> Cloudflare) |
| +--------------+ |
+-------------------------------------------------------------------------+
Alur kerja eksekusi (execution flow) di dalam sistem ini berjalan sebagai berikut:
- Developer melakukan push perubahan kode aplikasi atau manifes Kubernetes (YAML) ke repositori GitHub.
- ArgoCD Application Controller yang berjalan di dalam klaster EKS secara berkala memindai (poll) atau menerima webhook notification dari repositori Git.
- ArgoCD membandingkan desired state yang ada di Git dengan live state yang berjalan di klaster Kubernetes.
- Jika ditemukan perbedaan (drift), ArgoCD secara otomatis (atau manual berdasarkan konfigurasi sync policy) menerapkan perubahan manifes tersebut ke API Server Kubernetes.
- Kubernetes Scheduler mendistribusikan pod baru ke Application Node Group yang tersedia, sementara AWS Application Load Balancer (ALB) mengarahkan lalu lintas web dari pengguna akhir.
3. Perbandingan Komparatif / Analisis Pendekatan
Dalam merancang klaster EKS dengan ArgoCD, terdapat beberapa pendekatan arsitektural yang dapat dipilih berdasarkan kebutuhan sumber daya (CPU, RAM, Latency) dan kompleksitas operasional:
-
Pendekatan A: Single ArgoCD Instance dengan Shared Cluster Management
- Kelebihan: Mudah dikelola, penggunaan resource RAM dan CPU rendah, cocok untuk perusahaan rintisan atau aplikasi skala menengah.
- Kekurangan: Risiko keamanan jika terjadi eskalasi hak istimewa; jika ArgoCD mengalami crash, seluruh manajemen klaster terdampak.
- Konsumsi Sumber Daya: Rendah (~2 vCPU, 4GB RAM untuk controller dasar).
-
Pendekatan B: Hub-and-Spoke ArgoCD (Multi-Cluster GitOps)
- Kelebihan: Sangat aman, memisahkan klaster manajemen utama (Hub) dari klaster produksi (Spoke), skalabilitas tinggi untuk banyak klaster EKS.
- Kekurangan: Kompleksitas jaringan, membutuhkan konfigurasi network peering atau IAM Cross-Account yang rumit.
- Konsumsi Sumber Daya: Tinggi (~8+ vCPU, 16GB+ RAM tersebar di beberapa klaster).
[!TIP] Untuk lingkungan produksi perusahaan menengah hingga besar, Pendekatan B sangat direkomendasikan guna memastikan isolasi keamanan antara lingkungan Staging dan Production.
4. Prasyarat Sistem & Persiapan Lingkungan
Sebelum melangkah ke implementasi teknis, pastikan mesin lokal atau lingkungan CI/CD Anda telah dilengkapi dengan alat utilitas esensial berikut:
- AWS CLI (Versi 2.x ke atas) dengan konfigurasi akses IAM yang memiliki izin administratif EKS.
- eksctl (Alat resmi CLI untuk mengelola klaster EKS).
- kubectl (Kubernetes CLI versi yang kompatibel dengan minor version EKS).
- Helm (Package manager untuk Kubernetes, digunakan untuk instalasi ArgoCD).
- Argocd CLI (Untuk interaksi terminal dengan server ArgoCD).
Verifikasi instalasi awal dengan menjalankan perintah terminal berikut:
aws --version
eksctl version
kubectl version --client
helm version
argocd version --client
5. Panduan Implementasi Langkah demi Langkah
Langkah 1: Membuat Klaster EKS High Availability dengan eksctl
Buat file konfigurasi klaster bernama eks-cluster-config.yaml untuk mendefinisikan multi-node group.
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: production-cluster
region: ap-southeast-1
version: "1.28"
vpc:
nat:
gateway: HighlyAvailable
managedNodeGroups:
- name: system-node-group
instanceType: t3.medium
desiredCapacity: 2
minSize: 2
maxSize: 4
privateNetworking: true
labels:
role: system
taints:
- key: CriticalAddonsOnly
value: "true"
effect: NoSchedule
- name: app-node-group
instanceType: c6i.xlarge
desiredCapacity: 3
minSize: 3
maxSize: 10
privateNetworking: true
labels:
role: application
tags:
Environment: Production
Project: EnterpriseWeb
Eksekusi perintah pembuatan klaster:
eksctl create cluster -f eks-cluster-config.yaml
Langkah 2: Instalasi ArgoCD di Klaster EKS
Buat namespace khusus untuk ArgoCD dan instal menggunakan manifes resmi yang disediakan oleh proyek Argo.
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Verifikasi bahwa seluruh pod ArgoCD berjalan dengan normal:
kubectl get pods -n argocd
Ubah service ArgoCD Server menjadi LoadBalancer agar dapat diakses oleh administrator, atau gunakan port-forwarding untuk keamanan tingkat lanjut:
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer\