Cheat notes · Module 13 · Operate with teams

Capstone: onboard and operate catalog

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

Onboarding a team is a set of reviewed files: an AppProject, platform namespaces, an account and role, a secret store, a repo credential, ExternalSecrets and two Applications. Handling an incident is: health first, then the pods, then a revert, then the five answers.

Remember

Platform pieces: projects/catalog.yaml (only its repos, only its namespaces, no cluster-scoped kinds, quotas, limits, network policies and RBAC denied), namespaces/catalog.yaml, secret-store/catalog.yaml (store-catalog, readable only from catalog-dev and catalog-prod), and accounts.catalog-dev with role:catalog-team in policy.csv.
Team pieces: a private catalog-config with helm/dev.yaml and helm/prod.yaml (nameOverride: catalog) and an ExternalSecret catalog-db per environment, reading from the catalog store. Its deploy key sits in store-platform, with an ExternalSecret in the platform repo.
The Applications: three sources each (the shared chart at v1.0.0, the values repo as ref: config, and secrets/<env>), project catalog, the resources finalizer, and automated sync with prune and self-heal.
Done means: both apps Synced and Healthy, the team account limited to its project, a secret from its own store in use, a PreSync migration in dev, and an incident written up.
The five answers: what failed, how it was detected, who responded, how it was corrected, how it is prevented.
Rebuild: your repos recreate everything on a fresh cluster. On kind the store values live in the cluster, so put them back; with a real vault there is nothing to redo.

Pitfalls

Leaving the shared chart repo out of the project's sourceRepos: the Applications are not permitted.
Copying checkout's ExternalSecrets for catalog without changing the store: the checkout store does not serve catalog's namespaces. Point them at catalog.
Pushing straight to main, as the course did from module 07 to stay on Argo CD. A team protects main in every repo and works through pull requests with the validate check.

Commands

`argocd app get APP --refresh \| grep -E 'Health\|Deployment'`	Health first
`kubectl -n NS get pods`	The reason: `OOMKilled`, `CrashLoopBackOff`
`git revert --no-edit HEAD && git push`	Recover
`gh issue create -R OWNER/REPO --title "Incident: ..." --body "What failed: ..."`	Write the five answers
`kind delete cluster --name argocd`	Tear down. Git keeps the setup

Test yourself

Answer in your head first, then open the answer.

What did onboarding team-catalog require from the platform team?

A project, namespaces, a secret store, an account and role, a repo credential and two Application files, all as reviewed pull requests.

Where do you look first when an app is Degraded?

The resource tree, then the failing object's events and logs. Degraded is about the workload, not Argo CD.

What would you automate when a third team arrives?

Generating the project, namespaces and Applications from one file per team with ApplicationSets: the Fleet GitOps course.

Where module 13 leaves you: team-catalog runs catalog in dev and prod, with the same boundaries as team-checkout, entirely from Git. You handled an incident and wrote the five answers in an issue. You can run Argo CD for a team.