Challenge: registro privado
En la lección anterior guardaste una contraseña de base de datos en un Secret. Hay un segundo tipo de credencial que casi nadie cuenta como configuración y lo es: la que necesita el clúster para descargar tus imágenes.
Mientras las imágenes salen de un registro público nadie se autentica y el asunto no existe. En cuanto el registro es privado, el kubelet necesita credenciales, y el sitio donde las busca primero es un Secret del Namespace del Pod: uno de tipo kubernetes.io/dockerconfigjson, el único que en la práctica nadie escribe a mano.
Este challenge te da un clúster donde acaban de migrar las imágenes de la tienda a un registro privado. Nada arranca, y no todo por el mismo motivo, aunque en kubectl get pods se vea exactamente igual. Vas a tener que distinguir en los Events un 401 de credenciales de un 404 de nombre, y decidir dónde vive el Secret: en el Pod, que solo le sirve a ese Pod, o en la ServiceAccount del Namespace, que se lo pasa a todos.
Criterio de superación: los Pods api y reports están en Running con sus imágenes privadas, y el Deployment web tiene sus dos réplicas listas sin declarar imagePullSecrets en su template.
Hay una idea que conviene llevarse de aquí, y no se ve en la pantalla: la descarga de la imagen ocurre antes de que exista el contenedor. Cuando el kubelet se autentica contra el registro, tu Pod todavía no es nadie, así que ninguna identidad de aplicación —IRSA, Workload Identity, Pod Identity— sirve para esto. Quedan dos respuestas: un Secret en el Namespace, o un nodo que sepa autenticarse solo. La segunda es la que usan por debajo los clústeres gestionados, y es la razón de que muchas veces esto "ya funcione" sin que nadie declare nada.
- Previous lesson
- Configuración con ConfigMap y Secret
- Next lesson
- Downward API