Los pods que no logran mantenerse arriba | Labs | DevOps in Practice

Una nueva revisión del Deployment de Kubernetes receipt-api está reiniciando sus Pods y degradando el servicio.

Empieza revisando el estado del workload.

Prueba: kubectl get pods

Comando de terminal

El rollout está healthy.

La aplicación puede escribir en /app/runtime mientras el resto del filesystem del contenedor sigue siendo de solo lectura.

Lección

Un filesystem raíz de solo lectura es una barrera de seguridad útil. Monta un volumen escribible solo donde el proceso lo necesita; emptyDir funciona aquí porque el reporte es temporal y no debe sobrevivir al pod.

Editar deployment/receipt-api

Usa el patrón anterior para completar el volumen escribible de /app/runtime.

El Pod template todavía necesita volumes y volumeMounts con el mismo nombre, un emptyDir y mountPath: /app/runtime.

Conceptos clave

¿Qué es Kubernetes?

Un sistema para ejecutar y coordinar contenedores.

Qué es

Kubernetes es una plataforma open-source que ejecuta aplicaciones en contenedores sobre una o más máquinas.

En este incidente

El cluster intenta mantener corriendo el workload receipt-api, pero sus contenedores siguen terminando.

Por qué importa

Kubernetes compara continuamente el estado deseado con la realidad y actúa cuando son diferentes.

¿Qué es un Pod?

La unidad más pequeña que ejecuta Kubernetes.

Qué es

Un Pod es la unidad más pequeña que ejecuta Kubernetes. Agrupa uno o más contenedores que comparten red y almacenamiento.

En este incidente

El Deployment receipt-api crea Pods que ejecutan el contenedor de la aplicación.

Por qué importa

Los Pods son descartables. Kubernetes normalmente reemplaza un Pod unhealthy en lugar de repararlo en el sitio.

¿Qué es CrashLoopBackOff?

Un contenedor está arrancando y terminando repetidamente.

Qué es

CrashLoopBackOff es un estado de Kubernetes que aparece cuando un contenedor sigue fallando y Kubernetes retrasa cada nuevo intento de reinicio.

En este incidente

Los dos Pods de receipt-api entran en CrashLoopBackOff porque el proceso de la aplicación termina durante el arranque.

Por qué importa

Confirma un ciclo de reinicios, pero no explica su causa. Los logs son la siguiente fuente útil de evidencia.

Read-only no significa sin almacenamiento

La imagen del contenedor puede seguir inmutable.

Qué es

readOnlyRootFilesystem impide que un proceso modifique el filesystem raíz del contenedor.

En este incidente

La línea decisiva de los logs muestra que el proceso termina cuando intenta escribir en /app/runtime.

Por qué importa

La barrera de seguridad puede mantenerse. Un volumen permite hacer escribible únicamente la ruta necesaria.

¿Qué es un Deployment?

Una declaración del estado deseado del workload.

Qué es

Un Deployment declara el estado deseado de un workload y administra sus ReplicaSets y Pods.

En este incidente

Su Pod template activa un filesystem raíz read-only, pero no proporciona un mount escribible.

Por qué importa

Cambiar el template crea nuevos Pods con la configuración corregida en lugar de modificar los existentes.

¿Por qué usar un volumen?

Crea un límite escribible y controlado.

Qué es

Un volumen es almacenamiento conectado a un Pod y expuesto al contenedor mediante un volumeMount.

En este incidente

Un emptyDir montado en /app/runtime proporciona la ruta escribible que necesita el proceso.

Por qué importa

emptyDir dura lo mismo que el Pod. Sirve para archivos temporales, no para datos que deban persistir.

¿Qué demuestra rollout status?

Que el reemplazo deseado quedó disponible.

Qué es

Un rollout es el proceso de reemplazar los Pods anteriores cuando cambia el Pod template de un Deployment.

En este incidente

Kubernetes creó los Pods de reemplazo y estos alcanzaron el estado disponible.

Por qué importa

Confirma el progreso del despliegue. Una comprobación funcional de la aplicación seguiría siendo el próximo paso en producción.