Helm — your manifests as one versioned, named thing
By now the partner integration is a dozen YAML files: a Deployment, a Service, a ConfigMap, an ingress, a network policy, the storage claims. They travel together, they share values — the image tag, the replica count, the namespace — and yet nothing binds them into a unit you can name, version, or undo in one move. Helm is that binding. It packages a set of manifests as a chart: templated YAML plus a values.yaml file that fills the blanks, so the image tag lives in one place instead of being copy-pasted across six files that will inevitably drift.
Install a chart and you get a release — a named, numbered instance of that chart running in the cluster. That number is the whole point. helm upgrade ships a new version and bumps the revision; helm rollback partner-gw 4 puts revision four back exactly as it was, in one command, at three in the morning, without you reconstructing which six files changed. The release is the unit of change and the unit of regret. Without it, "undo the last deploy" is an archaeology project across your shell history; with it, it is a single line with a number in it.
Helm does not replace what you learned — the objects inside the chart are the same Deployments and Services from Parts A through F. It replaces the handling of them: instead of applying loose files and hoping you got the set complete, you install one artefact with a version on it. That is the same instinct that took you from clicking in the portal to writing infrastructure as code in Phase Three, applied one layer higher. The manifests were already code; Helm makes the collection of them a package.
Release strategies — how the new version reaches real traffic
Shipping a new version is not one thing; it is a choice about how much you gamble on the new pods being healthy. The default, built into every Deployment, is the rolling update you watched in Part A: the new ReplicaSet scales up while the old scales down, a few pods at a time, and if the new pods never pass their readiness probe the rollout stalls with the old ones still serving. It is safe, cheap, and gradual, and for most changes it is the correct and boring answer.
Two heavier strategies exist for when a rolling update's blast radius is still too much. Blue/green stands up a second, complete copy of the app — green beside the running blue — lets you test it in place, then flips all traffic across at once by moving the Service or ingress to point at green. Rollback is instant, because blue is still sitting there. Canary sends a small slice of live traffic — five percent — to the new version, watches its error rate and latency against the old, and only then widens the split. Rolling changes every pod a little; canary exposes a few real users a lot, on purpose, so you learn from production before you commit all of it.
| Strategy | How it works | Blast radius | Reach for it when |
|---|---|---|---|
| Rolling | New ReplicaSet scales up as the old scales down, a few pods at a time; built into the Deployment. | Small and spread — every request has some chance of hitting a new pod during the roll. | The default. Most changes, where a stalled rollout on failed probes is protection enough. |
| Blue/green | A full second environment runs beside the first; traffic flips all at once by repointing the Service or ingress. | All-or-nothing — everyone moves together, but rollback is instant because the old copy still runs. | You need a clean cutover and instant undo, and can afford to run two full copies briefly. |
| Canary | A small percentage of live traffic goes to the new version; you watch its signals, then widen the split. | Narrow and deliberate — a few real users feel the new version fully before the rest do. | The change is risky and you want production evidence, not a staging guess, before committing. |
A release is a bet. Choose your stake.
GitOps — the desired state lives in Git, not in your terminal
Everything so far still assumes a human runs helm upgrade or kubectl apply from a laptop. That is the weak seam. The cluster's real state now depends on who ran what, in which order, from whose machine — knowledge that lives in one person's shell history and leaves when they do. GitOps closes that seam by making a Git repository the single source of truth for what should be running. The manifests and Helm values go in the repo. An in-cluster agent — Argo CD or Flux — watches that repo and continuously makes the cluster match it.
Read that agent's job carefully, because you have seen it before. It observes the desired state (the repo), observes the actual state (the cluster), and works to close the gap — pulling changes when someone merges, and correcting drift when someone hand-edits a live object out from under it. That is the reconciliation loop, the exact idea a Deployment uses to keep three pods running, lifted one level up: now the thing being reconciled is the whole cluster, and the desired state is a Git commit instead of a replica count. Kubernetes reconciles pods to a spec; GitOps reconciles the cluster to a repo. Same loop, larger radius.1
The payoff is that deployment becomes a pull request. You do not push to the cluster; you merge to the repo, and the agent pulls. Every change is now reviewed, versioned, and attributable — git log is your deploy history, and rollback is git revert. Two engineers can run the cluster because neither of them is the cluster's memory; the repo is. AKS ships this as a first-class option: the GitOps (Flux v2) cluster extension installs and manages the agent for you, so you configure a repo to watch rather than hand-installing the reconciler.
The loop, drawn one level up
It is worth seeing the two loops side by side, because the whole track has been walking toward this picture. Inside the cluster, a controller compares a spec to reality and acts. Outside it, the GitOps agent compares a repo to the cluster and acts. The junior who can draw both and say "it is the same loop, just a bigger box" understands Kubernetes at a level that no amount of memorising kubectl flags gets you to.
A cluster a team can run
Put the three pieces together and the cluster changes character. Helm makes each change a versioned artefact. The release strategy decides how boldly that artefact meets traffic. GitOps makes the repo, not a person, the authority on what runs — so review, history, and rollback come for free from tools the team already knows. None of this is exotic; all of it is the same discipline you applied to infrastructure in Phase Three, now covering the workloads too. The cluster stops being a pet someone nurses and becomes a system a rota operates.
Hold the restraint one last time, because production is where teams forget it. GitOps invites you to put everything in the repo and let the agent run a sprawling estate; the discipline is to keep the repo exactly the size of the contract, same as the cluster. A canary rollout is powerful; it is also machinery you now maintain, and most changes still deserve a plain rolling update. The senior move is not adopting every technique in this part — it is choosing the lightest one that meets the risk in front of you, and being able to say why. Competence is knowing all three. Judgement is not always reaching for the biggest.
The cluster becomes something two engineers can run
The partner integration's manifests leave the two engineers' laptops and move into a Git repo. The AKS GitOps extension installs Flux, pointed at that repo; from now on nobody runs kubectl apply against production by hand. A change to the gateway is a pull request one engineer opens and the other reviews, and once it merges the agent reconciles the cluster to match. Drift stops being possible: if someone hot-fixes a live object during an incident, the next reconcile pass restores the repo's version, and the incident note goes into the repo where it belongs.
When the gateway's next version is due, they do not flip it for everyone. A canary sends five percent of partner traffic to the new pods and watches error rate and latency against the old; only when it holds for a few hours do they widen the split. The result is the quiet win the whole contract needed. The cluster is boring, auditable, and reversible — its history is git log, its rollback is git revert — and it no longer lives in one person's memory. Campux built exactly the cluster the contract justified, and now a team can run it.
The deploy that is a merge, not a command
You have a config change to ship. You do not open a terminal against production. You edit the values file in the repo, open a pull request, and let a colleague read it — the review is now a deploy gate, not a courtesy. On merge, Argo CD or Flux notices the new commit and reconciles the cluster to it, and you watch the rollout land in its dashboard. If it misbehaves, you do not scramble at the keyboard; you git revert the commit and the agent rolls the cluster back to the previous truth. The deploy history is the Git history, and anyone on the team can read it.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B. A Helm release is a named, numbered install of a chart, so an upgrade bumps the revision and helm rollback partner-gw 4 restores revision four exactly, in one line. A is not the value — charts are about packaging and versioning, not compression, and apply is not slow. C confuses Helm with a release strategy: canary is a traffic pattern you arrange separately, not something Helm does for you by default. D is a different tool entirely; the registry holds images, Helm holds the manifest package. The tell is "exact previous state, in one move": that is the revision number, which loose files apply strewn across your history cannot give you.
C. Canary deliberately exposes a small slice of real traffic — five percent — to the new version so you learn from production before committing the rest. A rolling update touches every pod a little but does not give you a held-back cohort to compare; the whole fleet is mid-migration at once. Blue/green is the opposite of small: it flips everyone together, which is a clean cutover but not a measured experiment on a few users. D is the crude strategy that accepts downtime and learns nothing before the switch. The phrase that decides it is "a few real users, fully" against "watch the error rate" — that is the canary's narrow, deliberate blast radius.
The reconciling agent, deploy-as-merge, and the Flux v2 extension. The two rejects invert the idea. GitOps changes nothing about the objects inside the cluster — it is the same Deployments and Services from Parts A through F; what changes is that a repo, not a person, is their source of truth. And hand-editing a live object is precisely what GitOps stops being a way to work: the next reconcile pass quietly restores the repo's version, so out-of-band edits are drift the agent corrects, not the normal path. The correct route is a commit, reviewed and merged, which the agent then pulls — the reconciliation loop you already know, one level up.
# runbook: how we ship to the partner cluster now
1. Desired state lives in the Git repo; Flux watches it.
2. To change the app, open a PR against the repo and merge it.
3. For urgent fixes we kubectl edit the live object directly
and skip the repo to save time.
4. Rollback is git revert of the offending commit.
Line three. It is the one habit that contradicts every other line. Lines one, two, and four all say the same true thing: the repo is the truth, changes go through it, and the repo's history is your undo. Then line three carves out an exception that dissolves the guarantee — a hand-edited object either gets silently reverted by the next reconcile pass (your urgent fix vanishes and nobody knows why) or leaves the cluster in a state the repo does not describe, which is exactly the drift GitOps exists to abolish. The "to save time" is the tell: the time you save is borrowed against a 2am incident where the cluster and the repo disagree and no one can say which is right.
The other lines are correct. Flux does watch a repo and reconcile to it (A is wrong). A merged pull request is the intended deploy trigger, not a limitation (B is wrong). And git revert genuinely rolls a deploy back, because the commit was the deploy (D is wrong). The lesson generalises: the moment you allow an authoritative source of truth to have exceptions, it stops being authoritative, and every guarantee built on it becomes a maybe.
Concede the half they have, then name the half they are missing. Keeping manifests in Git is genuinely good, and worth saying so — it gives you review and history for the files. But "run apply from them" leaves the deciding actor a human at a keyboard. Nothing forces the cluster to match the repo; it matches whatever was last applied, by whoever, from wherever. The repo is a suggestion the cluster happens to have followed, not a truth it is held to.
Then put the loop at the centre. GitOps adds an in-cluster agent that continuously reconciles the cluster to the repo — pulling merges and correcting drift, forever. That is the difference between Git as a filing cabinet and Git as the source of truth. Hand-edit a live object under manual apply and it stays edited until someone notices; do it under GitOps and the next reconcile pass restores the repo's version. The repo stops being where the files live and becomes what the cluster provably is.
Close on the payoff they will feel. Because the agent, not a person, applies changes, a deploy becomes a reviewed merge and a rollback becomes a revert — and no single engineer is the cluster's memory anymore. That is what lets a team run it instead of one person. It is the same reconciliation loop a Deployment uses on pods, lifted to the whole cluster; recognising it as the loop they already know is what turns the label into understanding.
The trap is treating a technique as free safety. A canary is not a setting you flip on; it is machinery — traffic splitting, a metrics comparison, a promotion gate, someone watching the window — that the team now builds and maintains. For a risky change, that cost buys real production evidence and is worth it. For a config tweak or a routine image bump, it buys almost nothing, because a rolling update already stalls on failed readiness probes and leaves the old pods serving. You would be paying operational overhead on every change to insure against a risk most changes do not carry.
Then reframe "to be safe" as a question about which risk. Making everything a canary adds steps, and steps are their own failure surface — a stuck promotion, a misread dashboard, a change that sits half-rolled for a day because nobody had time to watch it. More ceremony is not more safety once the ceremony outweighs the risk it guards. The honest default is a rolling update, with canary reserved for the changes whose blast radius genuinely warrants watching real users first.
Close on the principle the whole track has been about. Competence is knowing all three strategies and being able to run any of them. Judgement is reaching for the lightest one that meets the risk in front of you, and being able to say why. A team that canaries everything looks careful and is actually just slow; a team that matches the strategy to the stake is the one that can run this cluster for years without drowning in its own process.
Five things worth carrying out of Part G
- Helm packages your manifests as a versioned, parameterised chart; installing one gives a named release you can upgrade and roll back by revision number in a single command.
- Rolling (default, gradual, in the Deployment) fits most changes; blue/green flips a full second copy at once for instant cutover and undo; canary sends a small percentage to the new version to learn from production first.
- GitOps makes a Git repo the source of truth, and an in-cluster agent (Argo CD or Flux) continuously reconciles the cluster to it — the same reconciliation loop as a Deployment, one level up.
- Under GitOps, deploy is a merge and rollback is git revert; hand-edits to live objects are drift the agent corrects. AKS ships a GitOps (Flux v2) cluster extension to manage the agent.
- You can now run a cluster a team can run — packaged, released deliberately, driven from a repo. Keep the repo the size of the contract, and reach for the lightest release strategy the risk allows.
- The claim that GitOps is "the same loop as Kubernetes" is a teaching simplification worth its honesty tax: the mechanisms differ in the details — a built-in controller watches the API server's etcd through a tight in-process loop, while an Argo CD or Flux agent polls or is webhooked from an external Git host on an interval measured in minutes. Treat the equivalence as conceptual, not literal. What genuinely transfers is the shape — observe desired, observe actual, act to close the gap, repeat — and that shape is the thing to carry, because once you see it you find it everywhere from thermostats to autoscalers. ↩
- The advanced lab Continuous delivery with Argo CD is where this part stops being prose: you install the agent, point it at a repo, merge a change, and watch the cluster reconcile itself to it — then hand-edit a live object and watch the agent put it back. Do that once and the reconciliation loop stops being a diagram and becomes something you have seen defend a whole cluster with your own eyes, which is the difference between reciting GitOps in an interview and having run it. ↩