La eficiencia operativa y la resiliencia del sistema son aspectos cruciales al operar plataformas a gran escala. En el contexto de Kubernetes, la recuperación de fallas de software ha representado un desafío, ya que requería recrear todo el objeto Pod para reiniciar los contenedores, lo que resultaba en un desperdicio significativo de recursos. Para abordar esta problemática, la función «Restart All Containers on Container Exits» ha avanzado a la fase beta y se habilita por defecto en la versión v1.36 de Kubernetes. Desarrollada en colaboración con la comunidad CNCF, esta capacidad refleja el compromiso de Google con los proyectos de código abierto liderados por fundaciones. Al compartir prácticas recomendadas desde la gestión interna de sistemas distribuidos a gran escala, se busca construir un ecosistema más eficiente y resiliente. Permitir que los contenedores se reinicien mientras se conserva la identidad de tiempo de ejecución del Pod proporciona un método integrado para realizar la recuperación in situ del Pod, mejorando la fiabilidad de las aplicaciones y reduciendo los costos de recursos.
Históricamente, Kubernetes gestionaba las fallas mediante políticas de reinicio a nivel de pod. Aunque suficientes para servicios simples, los Pods modernos con múltiples contenedores tienen dependencias complejas. Cuando una falla requería un reinicio total del entorno, la única opción era eliminar y recrear el Pod completo, lo que introducía un gran volumen de operaciones en el plano de control, causando latencia y presión sobre el backend etcd durante fallas significativas.
Entre los inconvenientes de este enfoque estaba la necesidad de reinicializar dependencias, la interoperabilidad con sidecars observadores que requerían la recreación completa del Pod y sus infraestructuras, como el sandbox, y estados obsoletos que, al reiniciar un proxy lateral de base de datos, podían causar bloqueos en la aplicación principal. Además, los trabajos grandes enfrentaban condiciones de carrera de recursos, donde la recreación de Pods podía llevar a que otros Pods pendientes tomaran los recursos iniciales. Los reinicios in situ eliminan este riesgo.
Para resolver estas fallas previamente, se necesitaba destruir todo el Pod, lo que, para cargas de trabajo masivas o de IA/ML, donde miles de Pods podían fallar simultáneamente, causaba un incremento en las solicitudes de programación, retrasando la recuperación y desperdiciando recursos computacionales costosos como GPU/TPU.
Kubernetes v1.35 introduce la acción «RestartAllContainers», habilitada por la función «RestartAllContainersOnContainerExits», que pasó a beta en la versión 1.36 junto con sus dependencias «ContainerRestartRules» y «NodeDeclaredFeatures». Esto permite que el comportamiento de salida de un contenedor desencadene un reinicio rápido e in situ de todo el Pod en su nodo existente. En este proceso, el Kubelet detiene todos los contenedores mientras mantiene intacto el sandbox del Pod, preservando infraestructuras críticas.
Entre las ventajas operativas de los reinicios in situ se encuentra la eliminación de la sobrecarga del plano de control, la preservación de la localidad del nodo y la maximización de la eficiencia del hardware. Específicamente, en el entrenamiento distribuido de IA, perder un nodo detiene todo el trabajo, pero mantener aceleradores como GPUs/TPUs enlazados permite que las cargas de trabajo continúen entrenando mucho más rápido, reduciendo directamente los costos computacionales.
Para monitorear estos reinicios, Kubernetes v1.35 introduce la condición de Pod «AllContainersRestarting», la cual se establece en «True» durante los reinicios y alerta a los SREs y autoscaladores. Para utilizar con éxito los reinicios in situ, se recomienda un cambio de mentalidad hacia «sandboxes persistentes» y seguir prácticas recomendadas como garantizar reentrancia, planificar el manejo de terminaciones y preparar el tooling externo.
Esta capacidad beta es un paso importante hacia una gestión más fluida de cargas de trabajo y sienta las bases para características comunitarias avanzadas como los reinicios in situ de JobSet. El trabajo dentro de KEP-5532 refleja un compromiso con una gobernanza transparente de código abierto, mostrando un diseño, metas e intenciones claras mientras se construye sobre prácticas compartidas que benefician a todos. Se alienta a experimentar con Kubernetes v1.35 y compartir retroalimentación con la comunidad.
vÃa: Google Blog Open Source
