About this scenario
The shop namespace runs two images from the company registry, registry.acme.io, which refuses anonymous pulls. Both Deployments sit in ImagePullBackOff.
checkout names a pull secret, regcred, and still gets 401 Unauthorized. worker names no secret at all, and the team doesn't want imagePullSecrets copied into every manifest.
The registry's robot account is in registry-credentials.txt in the editor. Get both Deployments running, with worker's manifest left as it is.
Objectives
- Read why the pulls fail
- Find what's wrong inside the regcred secret
- checkout runs 2 ready replicas
- worker runs 2 replicas, pulling through the ServiceAccount's secret
- worker's Deployment still names no imagePullSecrets
What you'll practice
- A
kubernetes.io/dockerconfigjson secret holds credentials per registry server. The kubelet picks the entry that matches the image's registry, and one typo in the server name means it sends nothing. 401 Unauthorized on an anonymous token means no credentials were sent. With credentials that are wrong, the registry rejects the token request for that user.- Secrets are namespaced: a pull secret has to live in the Pod's namespace.
imagePullSecrets on a ServiceAccount are added to every Pod that uses the account and names none of its own. That happens at admission, so existing Pods need to be recreated.
How the playground works
The cluster runs entirely in your browser: a simulated API server, scheduler, kubelets and controllers, with virtual nodes in three zones. kubectl output follows the real formats, errors use the real messages, and the add-ons (CSI storage, Traefik, Envoy Gateway, cert-manager, Helm, Flux, Argo CD, Kyverno, Cilium, Istio) behave like their real counterparts for the common paths. It's a simulation, so some behavior is simplified. Your progress is saved in this browser.