Entrevista general: ¿Cómo migrarías después de que Kubernetes v1.36 deshabilite permanentemente los volúmenes gitRepo?

Planteamiento y alcance

Un equipo utiliza un volumen gitRepo para que un repositorio se clone en un punto de montaje cuando se inicia un Pod. Kubernetes v1.36 deshabilita permanentemente este plugin de volumen y no proporciona una compuerta de funcionalidad (feature gate) como vía de escape. Diseña la migración: inventaría las cargas de trabajo y las dependencias de repositorios, elige entre un init container, un sincronizador externo o el empaquetado en tiempo de compilación, y verifica la integridad de los commits, las credenciales, el comportamiento de red, la semántica de actualización y la reversión (rollback).

Kubernetes documenta que gitRepo ha estado en desuso durante años y que la implementación anterior podía permitir que un atacante ejecutara código como root en un nodo. Después de que la v1.36 deshabilite el plugin, reprogramar un Pod antiguo no restaura la compatibilidad. Separa el cambio de API, el lanzamiento de la imagen y las rutas de obtención en tiempo de ejecución.

Contexto y límites

Enfócate en el ciclo de vida del plugin de volumen, el orden de inicio del Pod, la confianza en la cadena de suministro y la verificación de la migración. El alojamiento de Git, un registro de imágenes, la salida de red (egress) y la gestión de secretos son dependencias de la plataforma; define el commit fijado, la credencial de privilegio mínimo, la política ante fallas de red y el objetivo de actualización de datos.

Lo que evalúa el entrevistador

Si reconoces gitRepo como un plugin de volumen en lugar de una capa de imagen o un ConfigMap.
Si comparas el empaquetado en tiempo de compilación, los init containers y los sincronizadores continuos según su reproducibilidad, frescura y semántica de fallas.
Si sabes manejar repositorios privados, known hosts, tokens, proxies y la integridad de los commits.
Si diseñas un escaneo previo a la actualización, bloqueo por admisión, nodos canarios y reversión.
Si explicas el uso compartido mediante emptyDir, los permisos de montaje, el consumo de solo lectura y la dependencia durante el inicio.

Respuesta de 30 segundos

«Escanearía los Pods, plantillas y generadores en busca de gitRepo, registrando el repositorio, la revisión, la ruta de montaje, las credenciales y los requisitos de frescura. El contenido fijo debe empaquetarse en una imagen inmutable en tiempo de compilación. Si se requiere la obtención en tiempo de ejecución, un init container con privilegios mínimos escribe un commit fijado en un emptyDir, y el contenedor principal lo monta como solo lectura. Las actualizaciones continuas requieren un sincronizador controlado con cambio atómico de versiones, retención de versiones anteriores y comprobaciones de integridad. Antes de la actualización, una política bloquea nuevos usos; los reinicios canarios prueban fallas de red y reversiones antes de eliminar las plantillas antiguas».

Solución paso a paso

Inventariar las dependencias reales. Busca en Pods, Deployments, StatefulSets, Jobs, charts de Helm, Kustomize, generadores y mutaciones de admisión la presencia de gitRepo. Registra el repositorio, la revisión, la ruta, las lecturas en el inicio, el tamaño del repositorio, el intervalo de actualización, el origen de las credenciales y la ruta de salida de red.

Clasificar la semántica de frescura. Empaqueta configuraciones o plantillas fijas en tiempo de compilación. Usa un init container para el contenido necesario al inicio. Considera un sincronizador únicamente para el contenido que deba cambiar durante la ejecución. «Obtener en cada inicio» y «actualización en caliente» son requisitos distintos.

Empaquetar en tiempo de compilación. En una red de CI de confianza, obtén el contenido por el digest del commit, escanéalo, compila una imagen inmutable y adjunta su procedencia. Despliega mediante el digest de la imagen para que el inicio no dependa de la disponibilidad de Git; la reversión restaura el digest anterior.

Utilizar un init container como reemplazo. Asigna al init container una ServiceAccount o Secret dedicada, monta las credenciales en modo de solo lectura y escribe el commit fijado en un emptyDir. El contenedor principal monta el mismo directorio como solo lectura. Un fallo al obtener el contenido evita que el Pod pase al estado Ready en lugar de exponer contenido parcial.

yaml

volumes:
- name: repo-data
  emptyDir: {}
initContainers:
- name: fetch-repo
  image: platform/git-sync:approved
  volumeMounts:
  - name: repo-data
    mountPath: /work
containers:
- name: app
  volumeMounts:
  - name: repo-data
    mountPath: /app/config
    readOnly: true

Esta es únicamente una guía estructural. La imagen, la proyección de credenciales, la política de red, el comando de validación y el comando de obtención deben definirse según el estándar de la plataforma antes de usarse en producción.

Operar un sincronizador cuando sea necesario. Para actualizaciones en caliente, utiliza un sidecar controlado o un sincronizador externo. Descarga en un directorio temporal, verifica el commit, el manifiesto de archivos y los permisos, y luego cambia de forma atómica el directorio de versión. En caso de fallo, conserva la versión válida actual. La aplicación debe admitir la recarga o una ventana de reinicio definida.

Proteger la cadena de suministro. Nunca coloques tokens de larga duración en especificaciones de Pods ni en logs. Restringe repositorios, ramas y salidas de red; valida TLS, known hosts, firmas de commits o digests de confianza. El sincronizador no debe modificar rutas del host como root; los montajes de la aplicación deben ser de solo lectura.

Pruebas canario, bloqueo y reversión. Antes de actualizar, escanea las salidas de CI y usa una ValidatingAdmissionPolicy para bloquear nuevos Pods con gitRepo, manteniendo una lista de permitidos para la migración. Reinicia cargas de trabajo en un conjunto reducido de nodos y prueba inicios en frío, pérdida de red, rotación de credenciales de repositorios privados, reprogramaciones y escalabilidad. Elimina las plantillas antiguas solo después de que la nueva imagen sea estable. La reversión restaura una imagen o sincronizador anterior, nunca el plugin v1.36 deshabilitado.

Respuesta modelo

Haría un inventario de gitRepo en los objetos de la API y en las plantillas de Pod renderizadas, clasificando luego cada carga de trabajo como contenido fijo, obtención al inicio o actualización en caliente. El contenido fijo se incluye en una imagen inmutable compilada en CI y desplegada por digest. El contenido de inicio utiliza un init container con privilegios mínimos para escribir un commit fijado en emptyDir, montado como solo lectura por el contenedor principal. Las actualizaciones en caliente usan un sincronizador que valida la nueva versión en un directorio temporal y la intercambia atómicamente, reteniendo la versión anterior en caso de fallo.

Cada ruta delimita el repositorio, el commit, las credenciales, la red y los permisos. Los tokens se mantienen fuera de las especificaciones y de los logs; el contenido descargado se valida mediante TLS, known hosts y procedencia del commit o la imagen. Antes de la actualización, se escanean las plantillas y se bloquea el uso de nuevos gitRepo; luego se realizan reinicios y reprogramaciones canario mientras se observa el tiempo de inicio, fallas de obtención, digest del contenido, estado Ready y el éxito de la reversión. Dado que la v1.36 deshabilita permanentemente el plugin, la reversión debe emplear el reemplazo o una versión anterior del clúster, no una compuerta de funcionalidad.

Errores comunes

Error: Colocar la URL de un repositorio en un ConfigMap y esperar actualizaciones → Por qué falla: Los ConfigMaps no obtienen datos de Git ni verifican versiones → Solución: Asigna la responsabilidad al empaquetado en compilación, a un init container o a un sincronizador.
Error: Hacer que el init container descargue la rama por defecto → Por qué falla: Los reinicios no son reproducibles y la reversión es imposible de garantizar → Solución: Fija un commit y registra su digest y procedencia.
Error: Ejecutar un sincronizador como root sobre una ruta compartida del host → Por qué falla: Amplía la superficie de ataque del nodo y elude el aislamiento del Pod → Solución: Usa volúmenes locales al Pod, ejecución sin privilegios de root, mínimo privilegio y consumo de solo lectura.
Error: Sobrescribir el directorio que la aplicación está leyendo → Por qué falla: La aplicación puede observar un árbol de archivos parcial → Solución: Valida en un directorio temporal y cambia las versiones de forma atómica.
Error: Intentar rehabilitar GitRepoVolumeDriver después de la v1.36 → Por qué falla: El plugin está deshabilitado permanentemente y el riesgo de seguridad persiste → Solución: Revierte al reemplazo o a la versión anterior del clúster mientras continúas con la migración.

Preguntas de seguimiento y respuestas

¿Por qué validar el contenido cuando el commit está fijado?

Fijar un commit hace que la referencia sea estable, pero no demuestra que el repositorio, las dependencias o el entorno de compilación sean de confianza. El CI aún debe verificar firmas, procedencia, manifiestos de archivos, escaneos de malware y digests de imágenes, vinculando las pruebas a la versión entregada.

¿Dónde deben almacenarse las credenciales de un repositorio privado?

Usa un Secret dedicado o un proveedor externo de secretos delimitado al namespace y repositorio de destino. Inyéctalo a través de una variable de entorno o un archivo montado, nunca en una imagen, anotación o log, y asegura el soporte para rotación y revocación.

¿Qué sucede cuando falla el init container?

El Pod no pasa a estar disponible y el contenedor principal no se inicia normalmente. Expón la causa, aplica reintentos y retroceso exponencial (backoff), y decide si una imagen antigua o una caché precargada proporciona un mecanismo de respaldo válido para el negocio.

¿Cómo pueden las actualizaciones en caliente evitar contenido parcial?

Descargando en un directorio de nueva versión, completando las comprobaciones de commit, manifiesto y permisos, y luego renombrando o cambiando atómicamente un enlace simbólico. La aplicación requiere un contrato de recarga o una política de reinicio; un fallo en el cambio mantiene la versión actual.

¿Cómo encontrar un uso inadvertido de gitRepo?

Escanea objetos de API, fuentes de Helm/Kustomize, salidas renderizadas y mutaciones de admisión. Monitorea advertencias de obsolescencia o errores de campos desconocidos después de la actualización, y mantén el escaneo en el CI para que ninguna plantilla nueva vuelva a introducir el plugin.

Referencias

Avance de Kubernetes v1.36 (Blog de Kubernetes)
Documentación de volúmenes (Documentación de Kubernetes)
Configuración de volúmenes proyectados (Documentación de Kubernetes)
Política de obsolescencia de Kubernetes (Documentación de Kubernetes)

Lista de verificación para la entrevista

Separa la semántica de contenido fijo, obtención al inicio y actualización en caliente; luego diseña la imagen, el init container, el sincronizador, los permisos, la validación, el despliegue canario y la reversión para cada caso.

Conclusión en una sola frase

La migración de gitRepo reemplaza la clonación implícita de Git del lado del nodo por una cadena de entrega de contenido reproducible, verificable y con privilegios mínimos.

Sigue practicando

Si el repositorio contiene modelos de varios gigabytes y configuraciones que cambian frecuentemente, compara capas de imágenes, almacenamiento de objetos, init containers y sincronizadores en términos de costo y consistencia.