Belajar GitOps - FluxCD - Cloud Provider Patterns

#Pendahuluan

Di episode 29 kalian sudah membangun infrastruktur sebagai kode dengan Terraform, mengelola resource cloud secara deklaratif. Sekarang kita bawa deklaratif itu satu lapis lebih tinggi: ke dalam cluster. Di episode 30 ini kalian belajar pola penerapan FluxCD di tiga penyedia cloud utama — AWS EKS, GCP GKE, dan Azure AKS — serta strategi multi-cloud bila organisasi kalian beroperasi di lebih dari satu penyedia.

Sebelum menelaah tiap provider, ingat satu prinsip: FluxCD hanya peduli pada Git dan cluster. Ia tidak peduli siapa yang menyediakan cluster — alur flux bootstrap pada dasarnya identik, dan yang berbeda hanyalah konteks di sekitarnya: IAM, identitas workload, registry, dan layanan secret.

flux bootstrap github \
  --owner=devvnull \
  --repository=fleet \
  --branch=main \
  --path=clusters/prod

Perintah di atas berlaku untuk EKS, GKE, maupun AKS, selama kredensial kubeconfig sudah menunjuk ke cluster tujuan. Perbedaan muncul saat menghubungkan Flux dengan layanan cloud — memberi akses pull image, membaca secret, dan sebagainya.

#AWS EKS

#Bootstrap EKS

Setelah cluster EKS dibuat, jalankan flux check --pre untuk memverifikasi koneksi, lalu flux bootstrap github. Pastikan kubeconfig memakai IAM user atau role yang tepat, karena EKS melakukan autentikasi melalui AWS IAM dan peta aws-auth di ConfigMap kube-system.

#IRSA - IAM Roles for Service Accounts

EKS menawarkan IRSA untuk memberikan peran IAM ke Pod tertentu melalui Service Account. Ini pola paling aman untuk memberi identitas ke controller seperti kustomize-controller agar bisa membaca secret dari AWS Secrets Manager.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: kustomize-controller
  namespace: flux-system
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/flux-secrets

Controller kemudian diberi akses secret lewat eks.amazonaws.com/role-arn, dan policy IAM pada role tersebut hanya membatasi akses ke Secret Manager.

#ECR dan AWS Secrets Manager

Image dari ECR ditarik oleh image-reflector-controller dengan kredensial yang diperoleh otomatis melalui IRSA, sehingga tidak perlu menyimpan Docker config secret. Sementara secret aplikasi yang disimpan di AWS Secrets Manager diambil dengan External Secrets Operator atau controller yang sudah diberi role IRSA tadi.

#Application Load Balancer

Untuk traffic masuk, ekspos service dengan ingress ke ALB. Flux cukup menerapkan Ingress yang dikelola AWS Load Balancer Controller:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  namespace: apps
  annotations:
    kubernetes.io/ingress.class: alb
spec:
  rules:
    - host: shop.devvnull.id
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: shop
                port:
                  number: 80

#GCP GKE

#Bootstrap dan Workload Identity

Di GKE, konsep identitas workload disebut Workload Identity: Service Account Kubernetes dipetakan ke Service Account GCP, lalu ke peran IAM tertentu. Ini memungkinkan controller Flux mengambil secret dari GCP Secret Manager tanpa kredensian statis.

#Artifact Registry dan Secret Manager

Image disimpan di Artifact Registry (penerus GCR). Akses pull oleh cluster GKE ditangani otomatis lewat Workload Identity, sehingga tidak perlu imagePullSecrets tambahan. Untuk secret aplikasi, gunakan GCP Secret Manager dengan External Secrets Operator yang memakai Service Account yang sama.

#Cloud Load Balancing

GKE menyediakan Cloud Load Balancing melalui ingress dengan ingress class gce. Flux menerapkan resource ini sama seperti resource lainnya:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  namespace: apps
  annotations:
    kubernetes.io/ingress.class: gce
spec:
  rules:
    - host: shop.devvnull.id
      http:
        paths:
          - path: /*
            pathType: ImplementationSpecific
            backend:
              service:
                name: shop
                port:
                  number: 80

#Azure AKS

#Bootstrap dan Azure AD

AKS mengautentikasi melalui Azure AD. Kubeconfig dibuat dengan az aks get-credentials, dan akses dikendalikan oleh Azure RBAC plus Kubernetes RBAC. Setelah kubeconfig aktif, flux bootstrap github berjalan normal.

#ACR dan Azure Key Vault

Image dari ACR ditarik dengan kredensial yang dibuat dari Service Principal atau Managed Identity, yang bisa diotorisasi lewat acr pull. Secret aplikasi disimpan di Azure Key Vault dan diambil oleh Secret Store CSI Driver atau External Secrets Operator, sehingga secret tidak pernah masuk ke Git.

#Application Gateway

Ingress di AKS bisa memakai Application Gateway melalui ingress controller AGIC (Application Gateway Ingress Controller):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  namespace: apps
  annotations:
    appgw.ingress.kubernetes.io/use-private-ip: "true"
spec:
  ingressClassName: azure-application-gateway
  rules:
    - host: shop.devvnull.id
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: shop
                port:
                  number: 80

#Multi-Cloud Patterns

Organisasi besar sering berjalan di lebih dari satu cloud, entah karena pilihan tim, risiko vendor lock-in, atau tuntutan regulasi data. Flux membantu menyatukan pengelolaan melalui beberapa pola:

• Unified GitOps: satu repositori fleet dengan satu path per cloud, misalnya clusters/eks, clusters/gke, clusters/aks. Kontrol Git tetap satu, konfigurasi per-cloud hanya pada lapisan yang benar-benar berbeda.
• Abstraksi cloud-agnostic: simpan yang netral (Deployment, Service, HPA) di folder apps, dan sisipkan hanya yang spesifik (Ingress, StorageClass, identitas) di folder clusters/<provider>.
• Federation: bagikan konfigurasi bersama antar cluster dengan Kustomization yang menunjuk ke source yang sama, sehingga perubahan baseline langsung menjalar ke semua cloud.

Perbandingan singkat ketiga provider:

#Penutup

Di episode ini kalian melihat pola penerapan FluxCD di tiga cloud provider utama: AWS EKS dengan IRSA dan ALB, GCP GKE dengan Workload Identity dan Cloud Load Balancing, serta Azure AKS dengan Azure AD, ACR, dan Application Gateway.

Inti yang harus dibawa pulang:

• Bootstrap identik: flux bootstrap tidak membedakan provider, yang berbeda hanyalah kredensial kubeconfig dan identitas workload.
• Identitas diutamakan: selalu pakai IRSA, Workload Identity, atau Managed Identity sebelum jatuh pada kredensial statis.
• Pisahkan lapisan: konfigurasi netral di apps, konfigurasi spesifik cloud di clusters.
• Secret di luar Git: manfaatkan secret manager native masing-masing cloud lewat External Secrets atau CSI driver.
• Satu Git untuk semua cloud: repositori fleet tunggal memudahkan multi-cloud dan audit perubahan.

Di episode 31, kita naik dari skala teknis ke skala organisasi: enterprise adoption patterns — platform engineering, struktur tim platform dan aplikasi, strategi repositori monorepo vs polyrepo, manajemen perubahan, serta onboarding tim. Sampai jumpa!