Kustomize apply, with no reconciler

The image exists; something has to make it run. Kustomize, one directory per app, digest-pinned images, applied with kubectl apply -k. No Argo, no Flux, no controller reconciling in the background.

What you get. The cluster’s state is exactly what someone applied, when they applied it. A kubectl edit sticks rather than being reverted thirty seconds later by a controller — which is genuinely valuable in a classroom, where the whole point of an exercise is often to change something by hand and watch what happens. It is also a much smaller surface: no controller with cluster-wide write access, no CRDs, no reconcile loop to reason about when something changes and nobody pushed.

What you lose. Drift detection, and the guarantee that the repository describes the cluster. Nothing notices if a manifest is added to the repo and never applied, or applied and later deleted, or applied by hand and never committed. The repository becomes documentation of intent rather than a description of fact, and the gap between those two is invisible by construction.

That is not an abstract risk here. It is exactly how the first item in the errata stayed invisible — two apps listed nowhere in the kustomization, so kubectl apply -k silently does not deploy them, while a wait-loop in the README expects one of them to exist. A reconciler would have surfaced that as drift on its first pass. Read that erratum next to this hop; it is the cost of this choice, made concrete.

Digest pinning. image: …@sha256:… rather than a tag means a re-apply cannot pick up different bytes than the last one, so "the same manifest" means the same software. It also means updating an image is a commit with a diff, which is the point: the change is reviewable and the history says when it happened. The cost is that nothing updates itself, including the thing you wanted updated, so an image bump is a task somebody owns rather than a property of the system.