Learning GitOps - FluxCD - Cloud Provider Patterns

#Introduction

In episode 29 you built infrastructure as code with Terraform, managing cloud resources declaratively. Now we bring that declarative approach one layer higher: into the cluster. In this episode 30 you'll learn the FluxCD adoption patterns on the three main cloud providers — AWS EKS, GCP GKE, and Azure AKS — plus multi-cloud strategies if your organization operates on more than one provider.

Before examining each provider, remember one principle: FluxCD only cares about Git and the cluster. It doesn't care who provides the cluster — the flux bootstrap flow is basically identical, and what differs is only the surrounding context: IAM, workload identity, registries, and secret services.

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

The command above applies to EKS, GKE, and AKS alike, as long as the kubeconfig credentials point to the destination cluster. Differences appear when connecting Flux to cloud services — granting image pull access, reading secrets, and so on.

#AWS EKS

#EKS Bootstrap

After the EKS cluster is created, run flux check --pre to verify the connection, then flux bootstrap github. Make sure the kubeconfig uses the right IAM user or role, because EKS authenticates through AWS IAM and the aws-auth map in the kube-system ConfigMap.

#IRSA - IAM Roles for Service Accounts

EKS offers IRSA to give specific Pods an IAM role through a Service Account. This is the safest pattern for giving identity to controllers like kustomize-controller so it can read secrets from 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

The controller is then given secret access through eks.amazonaws.com/role-arn, and the IAM policy on that role only limits access to the Secret Manager.

#ECR and AWS Secrets Manager

Images from ECR are pulled by the image-reflector-controller with credentials obtained automatically through IRSA, so there's no need to store a Docker config secret. Meanwhile, application secrets stored in AWS Secrets Manager are retrieved with the External Secrets Operator or the controller already given the IRSA role above.

#Application Load Balancer

For incoming traffic, expose the service with an ingress to ALB. Flux just applies the Ingress managed by the 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 and Workload Identity

On GKE, the workload identity concept is called Workload Identity: a Kubernetes Service Account is mapped to a GCP Service Account, then to a specific IAM role. This lets a Flux controller retrieve secrets from GCP Secret Manager without static credentials.

#Artifact Registry and Secret Manager

Images are stored in Artifact Registry (the successor of GCR). Pull access by the GKE cluster is handled automatically through Workload Identity, so no additional imagePullSecrets are needed. For application secrets, use GCP Secret Manager with the External Secrets Operator using the same Service Account.

#Cloud Load Balancing

GKE provides Cloud Load Balancing through an ingress with the gce ingress class. Flux applies this resource just like any other:

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 and Azure AD

AKS authenticates through Azure AD. The kubeconfig is created with az aks get-credentials, and access is controlled by Azure RBAC plus Kubernetes RBAC. Once the kubeconfig is active, flux bootstrap github runs normally.

#ACR and Azure Key Vault

Images from ACR are pulled with credentials created from a Service Principal or Managed Identity, which can be authorized through acr pull. Application secrets are stored in Azure Key Vault and retrieved by the Secret Store CSI Driver or the External Secrets Operator, so secrets never enter Git.

#Application Gateway

Ingress on AKS can use Application Gateway through the AGIC (Application Gateway Ingress Controller) 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

Large organizations often run on more than one cloud, whether due to team choices, vendor lock-in risk, or data regulation demands. Flux helps unify the management through several patterns:

• Unified GitOps: one fleet repository with one path per cloud, for example clusters/eks, clusters/gke, clusters/aks. Git control stays unified, per-cloud configuration only at the layers that truly differ.
• Cloud-agnostic abstraction: keep the neutral parts (Deployment, Service, HPA) in an apps folder, and insert only what's specific (Ingress, StorageClass, identity) in a clusters/<provider> folder.
• Federation: share common configuration between clusters with a Kustomization pointing at the same source, so a baseline change immediately propagates to all clouds.

A brief comparison of the three providers:

#Closing

In this episode you saw the FluxCD adoption patterns on the three main cloud providers: AWS EKS with IRSA and ALB, GCP GKE with Workload Identity and Cloud Load Balancing, and Azure AKS with Azure AD, ACR, and Application Gateway.

The key takeaways:

• Bootstrap is identical: flux bootstrap doesn't distinguish providers; what differs is only the kubeconfig credentials and workload identity.
• Identity comes first: always use IRSA, Workload Identity, or Managed Identity before falling back to static credentials.
• Separate the layers: neutral configuration in apps, cloud-specific configuration in clusters.
• Secrets outside Git: use each cloud's native secret manager through External Secrets or a CSI driver.
• One Git for all clouds: a single fleet repository makes multi-cloud and change audit easy.

In episode 31, we go up from the technical scale to the organizational scale: enterprise adoption patterns — platform engineering, platform and application team structures, monorepo vs polyrepo repository strategies, change management, and team onboarding. See you!