Diagnostica y repara un Pod roto
Acabas de incorporarte al equipo de plataforma y te encuentras esta escena: alguien desplegó anoche dos Pods en el clúster y ninguno de los dos funciona. Los manifiestos originales están en /home/laborant/manifests. Tu trabajo es averiguar qué le pasa a cada uno y dejarlos en estado Running.
Empieza por ver el panorama general desde la pestaña dev-machine:
kubectl get pods
Verás dos Pods con problemas distintos. Las herramientas que ya conoces, kubectl describe y kubectl logs, son todo lo que necesitas para diagnosticarlos. Recuerda que los eventos del describe cuentan la historia de lo que Kubernetes intentó hacer, y los logs cuentan lo que el proceso hizo al arrancar.
El Pod api
Pista 1
El estado ImagePullBackOff significa que el kubelet no consigue descargar la imagen del contenedor. Las causas típicas son tres: el nombre o el tag de la imagen tienen una errata, la imagen no existe en el registro, o el registro requiere autenticación. La sección Events de kubectl describe pod api te dice exactamente qué imagen está intentando descargar.
Pista 2
La imagen de un contenedor es uno de los pocos campos de un Pod que se pueden modificar en caliente. Puedes corregir el manifiesto y aplicarlo de nuevo, editar el Pod directamente, o usar el subcomando de kubectl que cambia imágenes. Compara el tag con el de la lección anterior del curso.
El Pod worker
Pista 3
CrashLoopBackOff no es un error en sí mismo: significa que el contenedor arranca, termina, y Kubernetes lo reinicia una y otra vez con esperas crecientes. La pregunta correcta es por qué termina el proceso. kubectl logs worker te enseña lo que escribió antes de terminar, y el campo command del manifiesto te enseña qué se le pidió ejecutar.
Pista 4
A diferencia de la imagen, el campo command de un Pod es inmutable. Para cambiarlo tendrás que eliminar el Pod, corregir el manifiesto en /home/laborant/manifests/worker.yaml y aplicarlo de nuevo. Piensa qué debería ejecutar este contenedor para mantenerse vivo: si eliminas el command, la imagen usará su proceso por defecto.
Por qué importa
Estos dos estados, ImagePullBackOff y CrashLoopBackOff, concentran una parte enorme de los incidentes reales en Kubernetes. La secuencia que acabas de practicar, get para ver el estado, describe para leer los eventos y logs para escuchar al proceso, es el reflejo que distingue a quien opera un clúster con soltura.