Belajar GitOps dengan ArgoCD - Troubleshooting & Debugging

#Pendahuluan

Di episode 26 sebelumnya kita membuat ArgoCD sulit untuk tumbang — multi replika, leader election, Redis dengan Sentinel, dan chaos testing. Namun ketangguhan terhadap kegagalan infrastruktur tidak menyembuhkan bug dan kesalahan konfigurasi. Di dunia nyata, pekerjaan harian seorang SRE lebih banyak dihabiskan untuk menjawab pertanyaan daripada mematikan server: kenapa aplikasi ini OutOfSync? Kenapa sync gagal di tengah jalan? Kenapa health check bilang Degraded padahal pod-nya Running?

Episode ini adalah toolkit debugging. Tujuannya bukan menghafal empat puluh perintah, melainkan mengajarkan alur pikir diagnostik — membaca sinyal dari status, log, events, dan diff, lalu menyempitkan akar masalah dari Git, ke ArgoCD, ke Kubernetes. Karena semuanya bersumber dari Git, ingat prinsip Golden Rule GitOps: selalu mulai dari pertanyaan "apa bedanya Git dan cluster?".

#Status: Titik Awal Diagnosa

Sebelum debugging, kalian harus membaca status dengan cepat. Dua kolom kunci dari argocd app get:

• Sync status — apakah yang ada di cluster sesuai dengan Git (Synced atau OutOfSync).
• Health status — apakah resource yang sudah di-sync berjalan sehat (Healthy, Progressing, Degraded, Missing, Suspended).

Kombinasi keduanya sudah bercerita banyak:

argocd app get api
Name:               api
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          api
URL:                http://localhost:8080/applications/api
Sync Status:        OutOfSync
Health Status:      Healthy

#Masalah Umum dan Penyebabnya

#Sync Failures

Sync gagal ketika manifest yang dirender tidak bisa diterapkan. Penyebab paling umum: YAML invalid, namespace tujuan tidak ada, CRD belum terpasang, atau resource sudah dimiliki aplikasi lain. Langkah pertama selalu melihat detail operasi:

argocd app get api --show-operation
argocd app sync api --dry-run

--dry-run memperlihatkan hasil sync tanpa benar-benar menerapkan — cara paling aman untuk menguji apakah perubahan manifest akan diterima cluster.

#Health Check Failures

Health assessment ArgoCD mengecek apakah resource sehat menurut aturannya — Deployment butuh availableReplicas sama dengan desiredReplicas, Job butuh selesai, dsb. Ketika Degraded, penyebabnya hampir selalu di runtime, bukan di Git:

kubectl get pods -n api
kubectl describe pod api-5d4b6c7d9-8xk2m -n api
kubectl get events -n api --sort-by='.lastTimestamp'

Perhatikan pola di output: CrashLoopBackOff berarti aplikasi crash terus, ImagePullBackOff berarti image tidak bisa ditarik, Pending berarti masalah scheduling atau resource. Setiap pola menuntun ke tempat yang berbeda.

#Masalah Autentikasi

• SSO bermasalah — login lewat Dex/OIDC gagal; periksa log argocd-server dan konfigurasi Dex.
• Token kedaluwarsa — CLI mengembalikan error 401; lakukan argocd login <server> ulang.
• RBAC menolak — padahal kredensial valid; ini masalah otorisasi, bukan autentikasi (dibahas di bagian RBAC).

#Akses Repository

Repo server tidak bisa menarik dari Git. Cek dulu daftar repo dan status kredensialnya:

argocd repo list
argocd repo get https://github.com/timmu/manifests
argocd repo update https://github.com/timmu/manifests --username deploy-bot

Error klasik: authentication required, repository not found, atau SSH host key tidak dikenal. Jika repo bersifat privat, pastikan kredensial disimpan sebagai Secret terenkripsi (episode 12) dan di-acl-kan ke project yang tepat (episode 10).

#Konflik Resource

Dua aplikasi mengelola resource yang sama adalah desain yang salah, dan ArgoCD akan menampilkannya dengan jelas. Cari tahu siapa pemilik resource lewat resource tree dan label pelacakan:

kubectl get deployment api -n api -o jsonpath='{.metadata.labels.argocd\.argoproj\.io/tracking-id}'
argocd app get api --tree

#Teknik Debugging Dasar

#Log Aplikasi

argocd app logs memutar log pod dari semua resource Deployment di aplikasi — setara kubectl logs tetapi terfilter otomatis per aplikasi:

argocd app logs api --tail 100
argocd app logs api --since-time 2026-08-03T10:00:00Z
argocd app logs api --container main

#Analisis Diff

argocd app diff menampilkan perbedaan persis antara manifest yang diinginkan (dari Git) dan yang hidup di cluster:

deployment.apps/api desired
  - spec.replicas: 2
+ spec.replicas: 3
  - resource.argoproj.io/requested-at: ...

Perbedaan replicas sering muncul ketika HPA ikut mengubah Deployment — bukan bug, tetapi perlu dicatat agar tidak disalahpahami sebagai drift.

#Live Manifest Comparison

Untuk melihat apa yang sebenarnya ada di cluster (termasuk field yang diisi controller lain), bandingkan manifest mentahnya:

kubectl get deployment api -n api -o yaml
kubectl get deployment api -n api -o jsonpath='{.metadata.ownerReferences}'
argocd app get api --resource deployment:apps/api

#Resource Tree

argocd app get <app> --tree menampilkan hierarki parent-child (Deployment → ReplicaSet → Pod) lengkap dengan health masing-masing node. Ini cara tercepat menemukan node mana yang Degraded dalam aplikasi yang kompleks.

#Debugging dengan CLI ArgoCD

Selain --show-operation, ada empat perintah yang wajib dikuasai:

app manifests sangat berguna untuk memverifikasi bahwa nilai yang dipakai ArgoCD adalah yang diharapkan — sering kali masalah ada di nilai Helm yang salah, bukan di chart-nya. Gabungkan dengan --hard-refresh untuk melewati cache:

argocd app get api --hard-refresh
argocd app manifests api | less
argocd app history api

#Debugging Lanjutan

#Log Komponen ArgoCD

Ketika masalah tidak ada di aplikasi, arahkan ke komponen:

kubectl logs -n argocd -l app.kubernetes.io/name=argocd-application-controller --tail=100 -f
kubectl logs -n argocd -l app.kubernetes.io/name=argocd-repo-server --tail=100 -f
kubectl logs -n argocd -l app.kubernetes.io/name=argocd-server --tail=100 -f

• Controller — membandingkan Git dan cluster; log ini menampilkan kegagalan reconciliation.
• Repo server — kloning dan render; error akses repo, cache, dan manifest muncul di sini.
• API server — login, token, dan penolakan RBAC.

#Debugging Jaringan

Repo server membutuhkan koneksi keluar ke Git; controller membutuhkan koneksi ke cluster target. Di cluster yang dikunci network policy (episode 28), koneksi ini sering terputus secara diam-diam:

kubectl run nettest --rm -it --restart=Never --image=curlimages/curl -- \
  curl -s https://github.com/team/manifests.git/info/refs
kubectl get networkpolicy -n argocd

#Debugging RBAC

Bukan hanya "gagal login" — sering kali user valid tapi tidak punya izin. Verifikasi identitas dan kemampuan secara eksplisit:

argocd account get-user-info
argocd rbac can run sync --application api
argocd rbac can get application --application api

argocd rbac can menjawab langsung pertanyaan "apakah user ini boleh melakukan X?" tanpa mencoba — sangat berguna saat menyusun kebijakan project (episode 10).

#Masalah Performa

Masalah performa sudah kita bedah di episode 25; yang perlu kalian ingat di sini adalah sinyalnya:

• Sync lambat — periksa pending_request_total di repo server; repo besar atau banyak aplikasi tanpa cache membuat kloning berulang.
• Memory tinggi — controller yang hampir OOM sering menampilkan status aplikasi yang tidak diperbarui. Naikkan limits atau pakai sharding.
• API latency — UI dan CLI terasa lambat; periksa Redis dan rate limiting di Ingress.
• Repo clone gagal — ukuran repo, kedalaman klon, atau rate limit provider Git (GitHub membatasi 60 request/jam untuk akses anonim). Aktifkan kredensial dan --depth 1.

argocd_repoclientset_processors_run_count
argocd_repo_pending_request_total
argocd_app_reconcile_count

#Penutup

Episode ini melengkapi kalian dengan toolkit diagnostik: membaca status sync dan health sebagai titik awal, mengenali penyebab sync failure, health check, autentikasi, akses repo, dan konflik resource, memakai log, events, diff, live manifest, dan resource tree, menguasai perintah CLI argocd app get --show-operation, logs, manifests, dan diff, debuging lanjutan di log komponen, jaringan, dan RBAC, serta mengenali sinyal masalah performa.

Poin yang harus kalian bawa:

• Mulai selalu dari pertanyaan: apa bedanya Git dan cluster?
• Kombinasi sync + health status menentukan arah investigasi.
• --show-operation dan app manifests memverifikasi apa yang sebenarnya dijalankan ArgoCD.
• Log controller, repo server, dan API server memisahkan masalah aplikasi dari masalah platform.
• argocd rbac can memverifikasi izin tanpa mencoba.

Kemampuan debug ini menjadi fondasi untuk menjalankan ArgoCD bagi banyak tim sekaligus. Di episode 28 selanjutnya kita membahas multi-tenancy at scale — model tenancy namespace, cluster, dan hybrid, strategi isolasi, pola self-service dengan ApplicationSet, serta manajemen resource dan biaya antar tim. Sampai jumpa di episode 28!