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 installation in the cluster. helm upgrade applies a change and adds a revision. If revision four is still retained, helm rollback partner-gw 4 restores that revision's Helm-managed resources and values as a new revision. Check that the workloads become ready and traffic behaves correctly. Helm cannot undo a database migration, data change, or anything the chart did not manage.
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.
Change a chart value and watch the release count
helm upgrade shop-release podinfo/podinfo --reuse-values --set replicaCount=3 helm history shop-release # predict: how many revisions now? helm rollback shop-release 1 # back to the first install helm history shop-release # and now?
Before the upgrade the release has one revision. After it, two; after the rollback, three, because a rollback is itself a new revision that copies revision 1. The Helm lab sets this up on a real cluster. Get this working before §3: Argo CD will be doing exactly this for you, from Git.
Release strategies — how the new version reaches real traffic
Shipping a new version is a choice about how much traffic can reach it before you know it works. A Deployment's usual strategy is the rolling update you watched in Part A: new pods are added while old ones are removed in stages. Readiness probes can keep unready pods out of Service traffic and a failed rollout can stall, but a pod can pass readiness and still return errors. Watch the rollout and application metrics; a rolling update is a useful default, not an automatic safety guarantee.
Two heavier strategies exist when a rolling update exposes too much risk. Blue/green runs a second copy beside the first, tests it, then changes the Service or ingress route. You can switch traffic back while the old copy is healthy and compatible; stateful changes may need their own recovery plan. Canary routes a controlled share of requests, say five percent, to the new version and compares error rate and latency before increasing that share. That needs traffic-routing and measurement beyond a plain Deployment. Five percent is an example, not a Kubernetes default or a universal safe level.
| 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 changes route after validation. | All-or-nothing cutover; switching back is possible while the old copy remains healthy and compatible. | You need a clean cutover and can afford two copies during the change. |
| 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.1
Read that agent's job carefully. It compares the desired state in the repo with live resources it manages. When automated sync is enabled, it can apply a merged change; when drift correction is enabled, it can restore a managed object someone edited by hand. That is a reconciliation loop: observe desired state, observe actual state, close the gap, repeat. A Deployment does something similar for its pods. GitOps does it for the resources configured under the agent, not automatically for every object in the cluster.2
With a reviewed repo and automatic reconciliation configured, a deployment can become a pull request and merge. git log records the desired-state changes. If a change fails, revert its commit, wait for reconciliation, and verify the workload's health; reverting manifests cannot reverse data or database changes. AKS offers a GitOps (Flux v2) cluster extension to install and manage the agent. You still configure which repo and paths it watches, how often it syncs, and whether drift is corrected.
Play it through
Three minutes, three moves. Watch a hand-run kubectl fix get silently reverted by the GitOps agent, then choose what to do next, commit the real fix to the repository, and let the agent reconcile it in. It plays on its own and stops when it needs your hands.
Where to run this for real. The short lab for this class is on its own page: A Helm release, upgraded and rolled back. Install a chart, upgrade it with a changed value, then roll back to revision one and prove the change reverted. About twenty-five minutes. The loop you just played is the longer build, GitOps on AKS with Argo CD: you install the agent, point it at a repository, merge a change, and watch the cluster reconcile to it. Set aside half a day and a cluster you are willing to pay for.
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 move into a Git repo. The team configures Flux to watch that path and reconcile the gateway objects, then makes a gateway change through a reviewed pull request. With drift correction configured, a direct edit to a managed object will be overwritten on a later pass. The team checks sync and workload health, and records any incident fix in Git. Other cluster resources can still drift if they are outside this configuration.
For a risky gateway release, they add a traffic-routing mechanism and send a measured share of partner requests to the new pods. They compare errors and latency before widening it. Git records each desired-state change; a revert can restore earlier manifests, subject to compatibility with any data changes. The team still confirms reconciliation and application health after every promotion or revert.
The deploy that is a merge, not a command
You have a config change to ship. Edit the values file in the repo and open a pull request for review. If automatic sync is configured, the agent applies the merge on a later pass; watch its status and the application's health. If the change misbehaves, revert the commit, confirm the revert syncs, and check the workload again. A Git revert changes desired manifests; it does not undo a database migration or guarantee the old version still works with changed data.
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 has numbered revisions. If revision four is retained, helm rollback partner-gw 4 applies its managed manifests and values as a new revision. Check pod readiness and application behavior afterward. It cannot reverse external data or database changes. A confuses packaging with speed; C requires separate traffic routing; D describes a container registry.
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.
Options 2, 4 and 5. GitOps still manages ordinary Deployments and Services. AKS can install Flux through its extension, and automatic sync can apply merged changes to the resources you configured it to manage. Installing Argo CD alone does not enable self-heal for every cluster object. A Git revert changes manifests in Git; it cannot undo a database migration. After any revert, confirm both sync and workload health.
# 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. Configure an agent to watch the right repo path and apply changes to its managed resources. Enable drift correction if direct edits should be restored. Hand-edit an unmanaged object and GitOps will not touch it; hand-edit a managed object with drift correction enabled and a later pass restores Git's version. Check the agent's sync status and the workload's health.
Close on the payoff they will feel. With automatic sync configured, a reviewed merge can deploy the managed resources; a revert can restore prior desired manifests. Neither action proves the application is healthy or reverses data changes. The reconciliation idea is familiar from Deployments, now applied to the resources the GitOps agent owns.
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 updates replace pods in stages; blue/green switches traffic between two copies; canary needs controlled traffic routing and metrics to test a smaller share first. Each still needs health checks.
- GitOps uses Git as desired state for resources configured under an agent such as Argo CD or Flux. Automatic sync and drift correction depend on configuration.
- With automatic sync, a merge can deploy; a Git revert can restore earlier manifests but not data. AKS offers a Flux v2 extension; verify sync and application health.
- 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 advanced lab GitOps on AKS 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. ↩
- 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. ↩
Change one Helm value, let Argo CD reconcile a cluster from a repository, and then add the pipeline that makes a merge the deployment.
Play the lesson above to stamp this class.