Belajar GitOps dengan ArgoCD - Cloud Provider Specific Patterns

#Pendahuluan

Di episode 30 sebelumnya ekosistem sudah tersambung. Namun ada satu lapisan yang belum kita singgung secara spesifik: siapa yang menjalankan cluster-nya. EKS, GKE, dan AKS masing-masing memiliki mekanisme autentikasi, ingress, secret manager, dan registry yang berbeda. Pola GitOps yang sama tetap berlaku — Git sebagai kebenaran, ArgoCD sebagai penyeimbang — tetapi "bagaimana" diwujudkan berbeda di tiap cloud.

Episode ini memetakan tiga cloud utama, lalu menutup dengan pola multi-cloud. Tujuannya bukan ensiklopedia, melainkan pola pikir: bagaimana abstraksi cloud-agnostic menjaga Git tetap bersih meski cloud di belakangnya berbeda.

#AWS EKS

Sebelum mulai, pastikan kubectl menunjuk ke cluster yang benar: aws eks update-kubeconfig --name eks-prod --region ap-southeast-1.

#IRSA (IAM Roles for Service Accounts)

IRSA memetakan Service Account Kubernetes ke IAM Role — pod yang memakai SA tersebut otomatis mendapat kredensial AWS via OIDC. Ini cara yang aman memberi ArgoCD akses ke resource AWS (misalnya untuk Image Updater atau plugin):

Service account dengan IRSA

apiVersion: v1
kind: ServiceAccount
metadata:
  name: argocd-repo-server
  namespace: argocd
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/argocd-repo-role

ArgoCD memakai IRSA untuk: menarik image dari ECR tanpa kredensial statis, membaca nilai Helm dari SSM Parameter Store, atau menulis hasil update ke S3. Tidak ada secret yang ditulis ke Git — kredensial mengikuti SA.

#ALB Ingress Controller

Akses ke UI/API ArgoCD di EKS biasanya lewat AWS Load Balancer Controller (ALB). Resource IngressClass dari AWS dan Ingress annotation membuat Application Load Balancer:

Ingress ALB untuk ArgoCD

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd-server
  namespace: argocd
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS-1-2
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS": 443}]'
spec:
  rules:
    - host: argocd.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: argocd-server
                port:
                  number: 80

#External Secrets: AWS Secrets Manager

Integrasi natural dengan External Secrets Operator (episode 12): SecretStore menunjuk ke Secrets Manager memakai kredensial IRSA, dan ExternalSecret me-mount secret ke ArgoCD tanpa pernah menyimpannya di Git.

#ECR

Untuk image di Amazon Elastic Container Registry, Image Updater (episode 16) atau Tekton cukup memakai kredensial sementara dari IRSA. ECR meminta token yang bertahan 12 jam — jangan simpan sebagai secret statis; biarkan IRSA yang menanganinya, atau gunakan helper ecr-login di CI.

#GCP GKE

Ambil kredensial cluster terlebih dahulu: gcloud container clusters get-credentials gke-prod --region asia-southeast1.

#Workload Identity

Workload Identity menghubungkan Service Account Kubernetes dengan Google Service Account. Pod yang memakai SA tersebut otomatis diautentikasi ke GCP:

SA GKE dengan Workload Identity

apiVersion: v1
kind: ServiceAccount
metadata:
  name: argocd
  namespace: argocd
  annotations:
    iam.gke.io/gcp-service-account: argocd-prod@gcp-project.iam.gserviceaccount.com

Pola pemakaiannya sama dengan IRSA: repository server menarik dari Artifact Registry, membaca nilai dari Secret Manager, tanpa secret statis.

#GKE Ingress

GKE menawarkan dua kelas ingress: GKE Ingress (native, load balancer global) dan Ingress NGINX (controller di dalam cluster). Untuk ArgoCD, NGINX lebih fleksibel untuk fitur seperti rate limiting dan annotation kustom; GKE Ingress unggul untuk skala besar dan integrasi Cloud Armor. Pilih sesuai kebutuhan, tapi pastikan konfigurasinya hidup di Git.

#GCP Secret Manager

Sama seperti AWS: SecretStore + ExternalSecret menunjuk ke GCP Secret Manager. Karena Workload Identity sudah memberi akses, tidak ada kredensial yang disimpan.

#Artifact Registry

GCR sedang pensiun; Artifact Registry adalah penerusnya. Integrasi dengan ArgoCD: Image Updater mendeteksi image baru di Artifact Registry, commit ke Git, ArgoCD sync.

#Azure AKS

Sambungkan kubectl ke cluster: az aks get-credentials --resource-group rg-prod --name aks-prod.

#Azure AD Integration

AKS mengintegrasikan Azure AD untuk autentikasi. Untuk ArgoCD, gunakan OIDC: ArgoCD diarahkan ke Azure AD (atau Dex yang meneruskan ke AD) sehingga login ArgoCD memakai identitas perusahaan. RBAC Azure AD bisa memetakan grup ke project ArgoCD (episode 10).

#Application Gateway Ingress

AKS umumnya memakai Application Gateway Ingress Controller (AGIC) — Azure Application Gateway sebagai ingress, dengan keuntungan integrasi WAF (Web Application Firewall) langsung:

Ingress dengan Application Gateway

metadata:
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/backend-protocol: http
spec:
  tls:
    - hosts:
        - argocd.example.com

#Azure Key Vault

Key Vault terhubung ke cluster lewat AKS add-on Secret Store CSI atau External Secrets Operator dengan Azure KeyVault provider. Secret ArgoCD (misalnya kredensial repo) di-reference dari Key Vault.

#ACR (Azure Container Registry)

Registry AKS standar. Sama seperti cloud lain: biarkan pod menarik via managed identity (AAD Pod Identity atau Workload Identity untuk AKS), dan Image Updater menangani pembaruan.

#Pola Multi-Cloud

#Unified GitOps Lintas Cloud

Pola yang konsisten di semua cloud: satu repo manifest, satu ArgoCD hub, banyak cluster target. Cluster EKS, GKE, dan AKS semuanya terdaftar sebagai destination di ArgoCD (episode 9). Manifest yang sama di-deploy ke semua cluster — perbedaan cloud hanya di lapisan bawah (storage class, ingress, dll.) yang di-handle lewat Kustomize overlay atau nilai Helm per cluster (episode 8).

#Abstraksi Cloud-Agnostic

Kunci multi-cloud adalah jangan menulis konfigurasi yang spesifik cloud ke dalam manifest aplikasi. Pakai:

Crossplane (episode 29) dengan Composition yang dipilih per cloud — claim yang sama bisa diwujudkan sebagai RDS di AWS, Cloud SQL di GCP, atau Azure SQL.
CSI driver sebagai abstraksi storage — pilih storage class per cluster lewat overlay, bukan hardcode.
Ingress abstraction — manifest aplikasi cukup menyebut Ingress; implementasi per cloud di taruh di layer platform, bukan di aplikasi.

#DR Lintas Cloud

Untuk disaster recovery (episode 21) lintas cloud: ArgoCD hub di cluster A mengelola cluster B sebagai target aktif-pasif. Karena manifest identik dan Git adalah kebenaran, failover = mengubah routing DNS + memastikan cluster B di-sync penuh. Latih DR drill secara berkala — perbedaan perilaku antar cloud (misalnya CIDR, quota, latensi) hanya terlihat saat benar-benar diuji.

Warning

Konsistensi manifest tidak otomatis berarti konsistensi perilaku. Storage class yang sama tidak berarti IOPS yang sama; Ingress yang sama tidak berarti keamanan yang sama. Saat men-deploy multi-cloud, validasi perilaku (response time, throughput, compliance) bukan hanya manifest di setiap cloud.

#Penutup

Episode ini memetakan pola per cloud: AWS EKS dengan IRSA, ALB Ingress, Secrets Manager, dan ECR; GCP GKE dengan Workload Identity, GKE/NGINX Ingress, Secret Manager, dan Artifact Registry; Azure AKS dengan Azure AD, Application Gateway, Key Vault, dan ACR; serta pola multi-cloud dengan satu Git, ArgoCD hub, abstraksi cloud-agnostic, dan DR lintas cloud.

Poin yang harus kalian bawa:

Kredensial cloud sebaiknya mengikuti identitas kerja (IRSA, Workload Identity, managed identity), bukan secret statis.
External Secrets + Secret Manager cloud = secret tidak pernah masuk Git.
Abstraksi (Crossplane, CSI, Ingress) menjaga manifest tetap cloud-agnostic.
Multi-cloud membutuhkan validasi perilaku, bukan hanya manifest.

Pola-pola ini siap dipakai dalam organisasi. Langkah terakhir sebelum skala penuh adalah menyusunnya sebagai kebijakan dan budaya. Di episode 32 selanjutnya kita membahas enterprise patterns & best practices — struktur organisasi platform team, strategi repository, manajemen environment, change management, dan dokumentasi runbook. Sampai jumpa di episode 32!