Cheat notes · Module 11 · Operate and grow

Going to cloud, and splitting the repo

A five-minute review for when you have done this module and want it back in your head. Open the full module for the steps and the lab, or the full text to print.

The idea

Everything above the cluster line is cloud-agnostic. In a real cloud two things change: how clusters are created and how Argo CD authenticates to them (workload identity, not tokens). As teams grow, one repo becomes three along ownership lines.

Remember

fleet-hub is portable: it needs a hub provider configuration and, per spoke, a server, labels and an Argo CD config. Feed it from your cloud's 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 (infrastructure/, clusters/: Terraform, slow, high blast radius), platform-fleet (root app, ApplicationSets, add-ons, charts, products, .github/), <product>-deployment (each team's config, with the production gate).
product.yaml stays in the platform repo, pointing at the team's repo: the declaration is the contract with the platform.
The cloud scripts leave one long-lived credential: a ServiceAccount token per spoke, stored on the hub. Workload identity replaces it.

Pitfalls

Splitting repos on day one. Split when a second team owns a product or infrastructure cadence starts blocking product changes; the folders make it a mechanical move.
Forgetting down.sh after the cloud track: clusters keep costing money.

Commands

`infrastructure/cloud/CLOUD/up.sh --dry-run`	Print every command the script would run; changes nothing
`infrastructure/cloud/CLOUD/up.sh`	Create the cloud fleet (costs money while it runs)
`infrastructure/cloud/CLOUD/down.sh`	Delete it all
`grep -n "bearerToken\\|service-account-token" infrastructure/cloud/lib/argocd.sh`	Find the long-lived token

Test yourself

Answer in your head first, then open the answer.

What has to change in fleet-hub to support EKS?

Nothing. You pass EKS spokes with an awsAuthConfig-based config.

Why split infrastructure into its own repository?

Different owners, cadence, permissions and blast radius.

After the split, where does checkout's product.yaml live?

In platform-fleet, pointing at checkout-deployment.

Where module 11 leaves you: A written plan: which folders go to which repository, who owns each, and what replaces the token with workload identity. If you ran the cloud track, an inventory pull request with real cluster addresses.