Solución de problemas de cargas de trabajo

Introducción

Las implementaciones no siempre salen según lo previsto. Cuando algo falla, necesita un método de solución de problemas que pueda repetir.

En este laboratorio, resolverá «El caso de la imagen desaparecida».

En Kubernetes, la solución de problemas suele comenzar por el estado del objeto, continuar con los eventos y terminar con una inspección más detallada. Este laboratorio se centra en ese flujo de trabajo basado en evidencias.

Usted:

• Creará la escena del incidente: implementará intencionadamente un Pod defectuoso.
• Investigarará: utilizará unos «binoculares» (get) para comprobar que algo no funciona correctamente.
• Recopilará pruebas: utilizará una «lupa» (describe) para encontrar la causa raíz.
• Resolverá el caso: corregirá la configuración y observará cómo se recupera la aplicación.

Crear un Pod defectuoso

Comenzará implementando un Pod con un error tipográfico intencionado. Esto simula un error frecuente: especificar una imagen que no existe.

También es importante recordar que Kubernetes acepta muchos manifiestos cuyos problemas solo se descubren más adelante. Un archivo YAML puede ser sintácticamente válido y, aun así, ser incorrecto desde el punto de vista operativo. Por eso, al solucionar problemas debe distinguir entre «¿Se aceptó el objeto?» y «¿La carga de trabajo se inició correctamente?».

Cree un archivo llamado broken-pod.yaml:

nano broken-pod.yaml

Pegue el contenido siguiente. Observe la etiqueta de imagen sospechosa wrongtag123.

apiVersion: v1
kind: Pod
metadata:
  name: broken-pod
spec:
  containers:
    - name: nginx
      image: nginx:wrongtag123

Guarde el archivo y salga (Ctrl+X, Y, Enter).

Implemente el Pod:

kubectl apply -f broken-pod.yaml

Kubernetes acepta el archivo porque el formato YAML es correcto. El «incidente» todavía no se ha detectado.

Observar el fallo

Ahora, compruebe el estado de la implementación. Es como utilizar unos binoculares para observar la escena.

Estados como ErrImagePull e ImagePullBackOff son síntomas, no explicaciones definitivas. Le indican dónde debe investigar a continuación. Una buena solución de problemas consiste en tratar la salida del estado como la primera pista, no como el diagnóstico completo.

Compruebe los Pods del espacio de nombres predeterminado:

kubectl get pods

Al principio podría ver ContainerCreating, pero después de unos segundos probablemente cambiará a ImagePullBackOff o ErrImagePull.

ImagePullBackOff es la forma en que Kubernetes indica lo siguiente: «Intenté descargar esta imagen, pero no pude. Esperaré un momento y volveré a intentarlo más tarde».

Esto confirma que la víctima —el Pod— no está en buen estado.

Inspeccionar los eventos

Sabemos que ha fallado, pero no sabemos por qué. Para averiguarlo, debemos examinarlo más de cerca.

El comando kubectl describe es su lupa. Muestra los eventos internos y los registros de un recurso específico.

La sección Events es especialmente valiosa porque conserva una breve narración de lo ocurrido según componentes de Kubernetes como el scheduler y kubelet. Cuando los principiantes aplican correcciones al azar sin leer los eventos, suelen perder tiempo resolviendo el problema equivocado.

Inspeccione el Pod defectuoso:

kubectl describe pod broken-pod

Este comando muestra una gran cantidad de datos. Desplácese hasta el final para encontrar la sección Events.

Debería ver algo parecido a lo siguiente:

Type     Reason     Message
----     ------     -------
Normal   Pulling    Pulling image "nginx:wrongtag123"
Warning  Failed     Failed to pull image "nginx:wrongtag123": manifest unknown
Warning  Failed     Error: ErrImagePull

El mensaje manifest unknown es la prueba decisiva. Significa que el registro de Docker, donde se almacenan las imágenes, no tiene ningún registro de nginx:wrongtag123.

Caso resuelto: la etiqueta de la imagen no es válida.

Corregir el Pod

Ahora que conoce la causa raíz, puede corregirla.

Este último paso también muestra un patrón más amplio: observar, formular una hipótesis a partir de las evidencias, realizar un único cambio específico y comprobar después la recuperación. Este ciclo disciplinado es más fiable que aplicar varios cambios especulativos a la vez.

Abra de nuevo el archivo broken-pod.yaml:

nano broken-pod.yaml

Corrija el «error tipográfico». Cambie nginx:wrongtag123 por nginx (que utiliza de forma predeterminada nginx:latest, una imagen válida).

apiVersion: v1
kind: Pod
metadata:
  name: broken-pod
spec:
  containers:
    - name: nginx
      image: nginx

Guarde el archivo y salga.

Aplique la corrección. Kubernetes puede actualizar el Pod existente con la nueva información.

kubectl apply -f broken-pod.yaml

Ahora, observe la recuperación:

kubectl get pods -w

Debería ver que el estado cambia de ImagePullBackOff a Running.

Pulse Ctrl+C para detener la supervisión.

¡Excelente trabajo, detective! Identificó el error y restauró correctamente el servicio.

Resumen

En este laboratorio, aprendió el flujo de trabajo fundamental para solucionar problemas de Kubernetes:

1. Observar: compruebe kubectl get pods para identificar las cargas de trabajo que presentan errores.
2. Inspeccionar: utilice kubectl describe pod para consultar el registro de eventos y encontrar los mensajes de error.
3. Corregir: actualice el manifiesto YAML y aplique la corrección.

Este proceso —Obtener, describir y corregir— resolverá el 90 % de los problemas de implementación que encontrará durante su trayectoria profesional con Kubernetes.