GitOps menjanjikan deployment yang konsisten dan terkontrol melalui single source of truth di Git. Argo CD, tool GitOps populer untuk Kubernetes, menjadi pilihan banyak engineer untuk menjaga cluster tetap sesuai dengan konfigurasi yang ada di repository. Tapi bagaimana kalau automasi yang seharusnya melindungi justru menimbulkan masalah baru?<\/p>\n
Cerita ini berawal dari tantangan menjalankan Kubernetes tanpa harus membayar biaya EKS yang terus menyala. Membangun lab k3s di home server menjadi solusi \u2014 bisa deploy, update, dan rollback aplikasi kapan saja. Argo CD dipasang untuk memonitor drift antara state di cluster dan state di Git. Setiap ada perubahan, Argo CD otomatis mensinkronkan. Kedengarannya sempurna, sampai suatu hari pipeline CI\/CD mendorong image yang broken ke production.<\/p>\n
Masalahnya: Argo CD mendeteksi “perbedaan” antara Git (yang sudah ter-commit image baru) dan cluster (yang masih jalan dengan image lama). Sesuai desain, Argo CD langsung mensinkronkan \u2014 men-deploy image yang belum diuji ke production. Tidak ada gate, tidak ada health check yang memadai. Yang tadinya ingin menghindari drift justru membuat outage lebih cepat menjangkau user.<\/p>\n
Pelajarannya: GitOps bukan berarti menghilangkan semua guardrail. Tambahkan health checks yang ketat, gunakan canary deployment atau blue-green strategy, dan pertimbangkan manual sync untuk environment production. Sinkronisasi otomatis bagus untuk staging, tapi production butuh lapisan verifikasi tambahan sebiarkan Git menjadi penguasa penuh atas yangjalan di cluster.<\/p>\n