Estabiliza un Pod ajustando recursos y probes
El equipo de desarrollo se queja de dos Pods que no hay manera de poner en marcha. Los manifiestos están en /home/laborant/manifests. Nadie tiene claro qué pasa, solo que uno "no arranca nunca" y el otro "arranca pero se cae solo". Averígualo desde la pestaña dev-machine:
kubectl get pods
Un aviso importante: la solución no es borrar la configuración problemática. El Pod procesador debe conservar requests de recursos (con valores sensatos) y el Pod estado debe conservar su liveness probe (apuntando a donde debe). En el mundo real, quitar las probes o los requests para "arreglar" un Pod es cambiar un problema visible por tres invisibles.
El Pod procesador
Pista 1
Un Pod en Pending es un Pod que el scheduler no ha podido asignar a ningún nodo. La sección Events de kubectl describe pod procesador incluye el motivo exacto del scheduler. Fíjate en cuánta CPU y memoria pide el Pod y compáralo con el campo Allocatable de los nodos (kubectl describe nodes).
Pista 2
Un kubectl apply no te va a dejar cambiar los requests de un Pod ya creado: el redimensionado en caliente existe desde hace unas versiones, pero va por un subrecurso aparte (resize) y no por el camino habitual. Para ajustarlos, corrige los valores en el manifiesto (algo del estilo de decenas de milicores y de mebibytes es más que suficiente para un nginx), elimina el Pod y vuelve a aplicarlo.
El Pod estado
Pista 3
Cuando una liveness probe falla repetidamente, el kubelet mata el contenedor y lo reinicia. Los eventos del Pod muestran el detalle: una petición HTTP que responde 404. La pregunta es si la ruta que comprueba la probe existe en este servidor. Puedes verificarlo tú mismo con kubectl exec estado -- wget -O- http://localhost/estado: BusyBox escribe el código de error por la salida estándar de errores. Compáralo con lo que devuelve la raíz /.
Pista 4
Las probes de un Pod también son inmutables. Corrige la ruta en el manifiesto para que apunte a un endpoint que responda 200, elimina el Pod y aplícalo de nuevo.
Por qué importa
Requests mal dimensionados y probes que apuntan a rutas inexistentes son dos de las causas más frecuentes de despliegues inestables en producción. Lo traicionero es que la aplicación no tiene ningún fallo: es su contrato con Kubernetes lo que está mal escrito. Aprender a leer los eventos del scheduler y del kubelet te permite distinguir en segundos un bug de la aplicación de un error de configuración.