Module 11 · Operate and grow · 60 min · You are: Platform team

Going to cloud, and splitting the repo

Everything you built is cloud-agnostic above the cluster line. Two things change in a real cloud: how clusters are created and how Argo CD authenticates to them. And as teams grow, one repo becomes three, because ownership and lifecycles differ.

Open this module in the interactive course to track progress and switch tracks.

Concepts

fleet-hub is portable

The module only needs a hub provider configuration and, per spoke, a server, labels and an Argo CD config. Feed it from your cloud Terraform.

Identity per spoke

AKS: workload identity and argocd-k8s-auth azure. EKS: IRSA or Pod Identity and awsAuthConfig. GKE: workload identity and argocd-k8s-auth gcp. No tokens to rotate.

Three repositories

infrastructure-live (Terraform, slow, high blast radius), platform-fleet (ApplicationSets, add-ons, policies, products), <product>-deployment (each team's config). The folders in your repo already have these boundaries.

What moves where

infrastructure/ and clusters/ to infrastructure-live (it needs the inventory); product-deployments/<x> to each team; product.yaml stays in the platform repo, pointing at the team repo.

Files to know

Open them in your editor or on GitHub; the bullets say what to look at.

• infrastructure/README.md (reference, your repo): Running the same fleet on existing or cloud clusters.
  1. Call fleet-hub with your own clusters L61–77
  2. The scripted route, and why to replace it L83–95
• infrastructure/cloud/aks/up.sh (reference, your repo): What a production-like cloud cluster needs. Skim the flags.
  1. Tier, OIDC issuer, workload identity, network, upgrade channel, autoscaling L66–78
• infrastructure/argocd/values-prod.yaml (reference, your repo): Argo CD for a real hub.
  1. Redis HA: 3 replicas L40–41
  2. Controller sizing and when to shard L49–58

Steps

1. Run the cloud track (optional, costs money)

Same repo, real clusters. Every script supports --dry-run.

Create your settings file from the example, and fill it in (the file explains each value):

cd ~/work/fleet-gitops
cp infrastructure/cloud/aks/env.example infrastructure/cloud/aks/env && $EDITOR infrastructure/cloud/aks/env

Read before you run. This prints every command the script would run, and changes nothing:

infrastructure/cloud/aks/up.sh --dry-run

Create the clusters. This costs money while they run:

infrastructure/cloud/aks/up.sh

Propose the real cluster addresses as an inventory change:

git switch -c cloud-inventory && git add clusters && git commit -m "Inventory: aks" && git push -u origin HEAD

When you are done, delete everything so it stops costing money:

infrastructure/cloud/aks/down.sh

2. Sketch the Terraform route for your cloud

Replace the scripts with your cloud's official Kubernetes module for hub and spokes, and call fleet-hub with each spoke's workload-identity config. The README shows the call; the identity configs are in the comments of infrastructure/cloud/lib/argocd.sh.

3. Plan the repository split

Write the split as an issue in your repo: which folders go where, which team owns each repo, which checks each repo needs. Use the table below as the starting point.

infrastructure-live: infrastructure/ and clusters/. Owner: the platform team. Terraform plan and apply run in CI.

platform-fleet: root-app.yaml, applicationsets/, addons/, charts/, products/ and .github/. Owner: the platform team; product teams propose changes to products/.

checkout-deployment: product-deployments/checkout/ with its base/, dev/ and prod/. Owner: team-checkout. The production gate lives here.

4. Find the long-lived credential

The cloud scripts register each spoke with a ServiceAccount token stored on the hub. Find where, and decide what replaces it on your cloud.

Done when:

• You can say where the token is stored and who could read it
• You can name what replaces it on your cloud (workload identity), and what gets deleted afterwards

Search the script for where the token is created and stored. Expect a few matching lines with line numbers; read the code around them.

grep -n "bearerToken\|service-account-token" ~/work/fleet-gitops/infrastructure/cloud/lib/argocd.sh

Quiz

1. What has to change in fleet-hub to support EKS?
   • Nothing: you pass EKS spokes with an awsAuthConfig-based config
   • Everything: the hub has to be rebuilt as an EKS cluster, and every add-on reinstalled
   • Argo CD does not support EKS, so the spokes would have to be managed by another tool
2. Why split infrastructure into its own repository?
   • Git becomes slow when a repository holds many files, so infrastructure moves out for speed
   • Different owners, cadence, permissions and blast radius
   • Terraform requires its own repository, and refuses to run if the code sits next to manifests
3. After the split, where does checkout's product.yaml live?
   • In checkout-deployment, since the file now belongs with the manifests it describes
   • Nowhere any more; the platform generates it from the inventory on every run
   • In platform-fleet, pointing at checkout-deployment

Field note

Do not split on day one. Split when a second team owns a product, or when the infrastructure cadence starts blocking product changes. The folders make it a mechanical move.

Report a problem with this module