🔒 Registro cerrado · Apertura oficial próximamente · Acceso exclusivo para alumnos activos
Iniciar SesiónQué se pierde al reiniciar un pod
5 tareas · 38 min · Principiante
Un contenedor está hecho para reemplazarse, y esa virtud es el primer problema de quien investiga: cada reinicio, cada borrado y cada reprogramación se llevan una parte de la evidencia sin avisar. Textiles Lomabaja, martes 12 de octubre de 2027: un monitor de salida avisa de una conexión rara de un pod del namespace de ventas, y cuando alguien lo mira el contenedor ya se había reiniciado varias veces. Antes de interpretar nada, inventarías qué sigue existiendo y qué ya se perdió. Solo lectura de salidas de ejemplo.
Objetivo de la sala
Un contenedor está hecho para reemplazarse, y esa virtud es el primer problema de quien investiga: cada reinicio, cada borrado y cada reprogramación se llevan una parte de la evidencia sin avisar. Textiles Lomabaja, martes 12 de octubre de 2027: un monitor de salida avisa de una conexión rara de un pod del namespace de ventas, y cuando alguien lo mira el contenedor ya se había reiniciado varias veces. Antes de interpretar nada, inventarías qué sigue existiendo y qué ya se perdió. Solo lectura de salidas de ejemplo.Un pod es un grupo de contenedores con volúmenes. Cuando un contenedor se reinicia dentro de su pod (por una salida con error o por falta de memoria), Kubernetes crea un contenedor nuevo a partir de la imagen: todo lo que el anterior escribió en su propia capa de escritura, fuera de los volúmenes, desaparece. Los volúmenes de tipo emptyDir sí sobreviven a ese reinicio, porque su vida está atada al pod, no al contenedor.
Cuando es el pod el que se borra o se reprograma en otro nodo, desaparecen también los volúmenes efímeros como emptyDir, y con ellos se pierden los registros del contenedor guardados en el nodo. Solo un volumen persistente (un persistentVolumeClaim) vive más que el pod.
Responde para continuar
El contenedor de una aplicación se reinicia por falta de memoria dentro de su mismo pod. ¿Qué ocurre con lo que había escrito?
El estado del pod guarda, por contenedor, cuántas veces se reinició, el motivo del último fin (una salida con código de error, falta de memoria) y las horas. Es la primera lectura: dice cuánto historial se perdió ya, porque el nodo conserva un solo contenedor terminado y los demás ya no existen.
Responde para continuar
¿Cuántas veces se reinició el contenedor web del pod? Escribe solo el número.
Ver pista de ayuda
Ejecuta `SELECT * FROM contenedores` y mira la columna de reinicios de la fila web.
Un pod declara sus volúmenes en su definición, y el tipo de cada uno dice de qué depende su vida. Para decidir qué copiar primero hay que saber cuáles son efímeros (atados al pod) y cuáles persistentes. Los que son efímeros se pierden al borrar el pod; los demás, no.
Responde para continuar
¿Cómo se llama el volumen de tipo emptyDir del pod?
Ver pista de ayuda
Ejecuta `SELECT * FROM volumenes` y busca el tipo emptyDir.
Por defecto, el kubelet conserva el registro de un solo contenedor terminado por cada contenedor del pod, y los registros del contenedor actual se rotan por tamaño. Si el pod se desaloja o se borra, sus registros en el nodo se van con él. Un registro con huecos no se puede leer como si estuviera completo: lo que ocurrió en el hueco simplemente no se sabe.
Se mide el hueco como el tiempo entre la hora de la alerta y la primera línea que conserva el registro del contenedor actual.
Responde para continuar
¿Cuántos minutos hay entre la hora de la alerta y la primera línea conservada del registro del contenedor web actual? Escribe solo el número.
Ver pista de ayuda
Ejecuta `SELECT * FROM caso` para la hora de la alerta y `SELECT * FROM registros_conservados` para el inicio del registro actual.
La tentación es borrar el pod para que el Deployment cree uno limpio y «ver si vuelve a pasar». Eso destruye lo único que queda: el emptyDir, el registro del último contenedor terminado y el estado del pod. La regla es la de toda evidencia volátil: primero se copia lo que sobrevive y se anota el estado, después se decide qué cambiar, y con autorización.
Responde para continuar
El pod sigue en marcha, con un contenedor reiniciado y poco registro. ¿Qué se hace primero?
Whoami-Labs Pro
Whoami-Labs Pro utiliza cookies
Utilizamos cookies y almacenamiento local para el funcionamiento del sitio, seguridad de sesión y, si lo autorizas, analítica y marketing. Puedes aceptar, rechazar o personalizar. Política de Privacidad
Preferencias
Configuraciones de cookies
Elige qué categorías permitir. Las esenciales siempre están activas. Consulta la Política de Privacidad.
Esenciales
Siempre activas · sesión, CSRF, tema y esta preferencia
Necesarias para iniciar sesión, proteger formularios (CSRF) y recordar tu elección de cookies y tema. Sin ellas la plataforma no funciona de forma segura.
Analíticos
Hoy no activos en la plataforma; listos para cuando se conecten
Nos ayudan a entender uso de cursos y páginas. Si los activas, se usarán cuando conectemos analítica; hasta entonces no se carga ningún tracker.
Marketing
Hoy no activos; campañas futuras solo con tu permiso
Comunicaciones o campañas. No activos hoy en la plataforma; quedarán listos si los conectamos y solo si los permites.