The Exploded Cluster · The Delivery Arc
Three courses on the toolchain around the cluster: how change travels, how images are named, and how one definition serves a fleet. Scroll, and each machine comes apart.
Course VI · GitOps
The mental model everyone arrives with: someone with credentials pushes manifests at the cluster. In GitOps nothing is pushed. A repository holds the desired state, an agent inside the cluster watches it, and the cluster pulls its own future from git. kubectl is for looking; git is for changing.
C-II taught the reconciliation loop: desired versus actual, fix the difference, repeat. ArgoCD is the same habit applied to delivery. An Application names a repo, a path and a revision - watch this branch of this repository - and the controller renders what it finds there, compares it against the live cluster, and syncs the difference. The deploy button is a git commit; the audit log is git log; code review is change control.
kubectl apply is for archaeology, not for change.
The cluster pulls. No CI system, no laptop, no build pipeline holds a credential that can touch it - the agent inside holds a read-only deploy key, and the trust arrow points out. Compromise the build system and you can propose a change, which is visible; you cannot reach into production. Hand-edit a live object and the controller flags it OutOfSync - selfHeal puts it back, and what leaves git leaves the cluster. Rollback is git revert, which is why commit hygiene is an operational skill.
Field note. Fighting the reconciler over SSH is arm-wrestling a machine that does not get tired - C-II's warning, now with a face. The fix is always upstream, in git.
Git holds everything except secrets - a secret in git is published, forever, to everyone who ever clones. So the pattern splits the reference from the value: git carries an ExternalSecret naming a logical key; a vault - Azure Key Vault in the worked example - holds the value; an operator inside the cluster exchanges one for the other at runtime. Rotation happens in the vault, never as a commit. That is why the vault floats apart in the scene above: it is never absorbed into the pipeline.
Git holds the shape of the secret. The vault holds the secret.
Delivery stops being an event and becomes a property: the cluster is always converging on what the repository says. "Who deployed this?" becomes "who merged this?" - and that question always has an answer.
Pre-reads: C-II · Kubernetes concepts · git + pull requests Further: Argo CD · OpenShift GitOps · External Secrets · Azure Key Vault
Course VII · The image supply chain
myapp:latest feels like a name. It is a sticky note - a mutable pointer anyone with push rights can peel off one image and press onto another, and nothing anywhere records that it moved. The digest is the image's actual name: same bytes, same digest, forever.
Three ways to name an image, in rising order of honesty: :latest (a moving target), :1.4.2 (a promise somebody keeps, until they re-push it), and name:1.4.2@sha256:... - a fact. The tag stays for human eyes; the digest does the pulling. Pin by digest and "what is running?" has exactly one answer.
Field note. :latest is how two nodes run different code from one manifest - the second node pulled an hour later, after a re-push. Nobody changed the YAML.
Between the build and the node sits the registry chain. Upstream, a managed registry - Azure Container Registry in the worked example - holds what CI built. In front of the cluster sits a mirror: a pull-through cache like zot. The fleet asks the mirror, the mirror asks upstream once, everything after is local. Rate limits, egress cost, disconnected sites, control - one place to gate and audit what enters. OpenShift formalises the re-route with image mirror rules, and carries a sharp edge: digest-mirror rules rewrite digest pulls only, so a by-tag pull silently skips the mirror. The pinning habit is what makes the mirror actually catch the traffic.
Every rebuild is a different artefact - different digest, untested by the stages before it. So build once, then promote the same digest through environments by copying, registry to registry - dev proves the exact bytes prod will run. Human tags ride along; the digest is the through-line.
If the digest changed, it is not a promotion - it is a new candidate.
Names that can move are convenient exactly until they move. Address content by what it is, and the supply chain stops being a chain of trust and becomes a chain of arithmetic.
Pre-reads: C-I · Kubernetes images Further: zot · Azure Container Registry · OpenShift image mirroring · skopeo
Course VIII · Helm
The default way to run one app on five clusters is five copies of the YAML, and the default result is five slightly different apps. The inversion: stop copying outputs and ship the function. A chart is a template with holes; each cluster supplies one small values file that fills them.
Helm templates are Go text/template: {{ .Values.device.address }} is a pipeline walking a values object, _helpers.tpl holds the named functions every manifest calls. You are not writing YAML - you are writing a program whose output is YAML. So render locally, read the output, and lint what came out, not what went in.
Review the render, not just the template.
Field note. ArgoCD deploys charts by running helm template - a pure render. Anything needing a live cluster or an install lifecycle (lookup, hooks) is silently dead there. Render the way your deployer renders.
The chart owns everything structural - resources, probes, security, policy. Each cluster owns one values file: names, addresses, sizes, flags. The context is deliberately values-only; the moment it carries its own manifests there are two owners for one object, and they will disagree. One value can feed many rendered artefacts - an address appearing in the app config, the network attachment and two policies renders from one field, so the copies cannot diverge - the lived version is BLOG in the key above.
The chart owns the shape. The context owns the numbers.
A template that renders whatever it is given just moves the failure downstream. The grown-up chart carries a values.schema.json: a context missing a required value fails at render time, in the pipeline, with a message naming the field - not months later as enforcement pointed at nothing.
Field note. The failure you want is the render that refuses. It costs a red pipeline. The alternative reports healthy the whole time.
Fleet consistency is not a discipline problem, it is a construction problem. Divergence stops being something you police and becomes something the tooling cannot express.
Pre-reads: C-II · Kubernetes objects Further: Helm docs · chart template guide · Go text/template · Helm on OpenShift
Appendix · The dependency ledger
The arc reads like a closed machine: repo to reconciler to registry to node. It is not closed. Three load-bearing pieces live outside the cluster - and the honest move is to write down what leans on them, and what actually happens when they are down.
Where the desired state lives - the system of record the whole loop watches, through a read-only deploy key.
Leans on it: sync, rollback, change review, the "who merged this" answer.
When it is down: the cluster does not care - the reconciler enforces the last synced state indefinitely. What stops is change. GitOps degrades to read-only, which is the graceful half of the design.
Where the secret values live - git carries the reference, the vault carries the value, an operator keeps them synced.
Leans on it: secret sync, rotation, the first deploy of anything that needs a credential.
When it is down: already-synced Secrets keep working - values are materialised in-cluster. What stops is rotation and new secrets. Survivable - unless you are inside a rotation window.
Where the fleet pulls from - a pull-through mirror between the cluster and the internet, and the control point for what enters.
Leans on it: every image pull on every node - boot, reschedule, scale-up, recovery.
When it is down: the sharpest edge. Upstream down + mirror up = nobody notices. Mirror down on a mirror-only pull path = nothing new schedules, and a rebooting node may not come back whole.
None of these outages stop what is already running - they stop change, rotation and recovery, in that order of pain. Cache what you pull, split references from values, and let the cluster hold its last known truth without asking anyone's permission.
Further: GitHub docs · Azure Key Vault · zot · Kubernetes · Helm · Red Hat OpenShift
The whole arc · end to end
Every course above is one stretch of the same journey. Here is the full run, drawn in the house blueprint style: the change lane, the shape lane, the artefact lane and the secret lane, all converging on one running workload.