Challenge: pull an image from a private registry
In the previous lesson you stored a database password in a Secret. There is a second kind of credential that almost nobody counts as configuration, and it is: the one the cluster needs to pull your images.
As long as the images come from a public registry nobody authenticates and the question never comes up. As soon as the registry is private, the kubelet needs credentials, and the first place it looks for them is a Secret in the Pod's Namespace: one of type kubernetes.io/dockerconfigjson, the only one that in practice nobody writes by hand.
This challenge gives you a cluster where the tienda's images have just been migrated to a private registry. Nothing starts, and not all for the same reason, even though in kubectl get pods it all looks exactly the same. You will have to tell a credentials 401 from a name 404 in the Events, and decide where the Secret lives: on the Pod, where it only serves that Pod, or on the Namespace's ServiceAccount, which hands it to all of them.
Passing criterion: the Pods api and reports are Running with their private images, and the Deployment web has its two replicas ready without declaring imagePullSecrets in its template.
There is an idea worth taking away from here, and it does not show on the screen: the image pull happens before the container exists. When the kubelet authenticates against the registry, your Pod is nobody yet, so no application identity (IRSA, Workload Identity, Pod Identity) works for this. Two answers remain: a Secret in the Namespace, or a node that knows how to authenticate on its own. The second is the one managed clusters use underneath, and it is the reason this often "just works" without anyone declaring anything.
- Previous lesson
- Configuration with ConfigMap and Secret
- Next lesson
- Downward API