Kubernetes 1.28: contenedores sidecar como ciudadanos de primera

javi
Estructura de contenedores en arquitectura Kubernetes

Kubernetes 1.28, programado para agosto de 2023, introduce una de las mejoras más esperadas por equipos que operan service meshes: sidecar containers nativos. Hasta ahora el patrón sidecar — un contenedor adicional en el pod para añadir funcionalidad como proxy de red, logging o seguridad — se implementaba con contenedores normales, con implicaciones pesadas en orden de arranque, gracia de apagado y manejo de Jobs.

El problema que resuelve

Los contenedores sidecar no eran ciudadanos de primera en Kubernetes. Concretamente:

  1. No hay orden garantizado de arranque. El proxy de Istio (envoy) puede arrancar después del contenedor de la aplicación, que intenta conectar a la red antes de que el proxy esté listo.
  2. Orden de apagado invertido. Al terminar el pod, el sidecar puede cerrarse antes que la aplicación, cortando trazas, métricas o logs de los últimos segundos.
  3. Jobs que nunca terminan. Un Job que usa sidecar se queda “Running” para siempre porque el sidecar nunca termina aunque la aplicación sí.

Cada uno de esos problemas tenía workarounds: hooks preStop, scripts wrapper, o el mecanismo de Istio con holdApplicationUntilProxyStarts. Todos frágiles, todos con esquinas agudas.

Qué introduce 1.28

La KEP-753 añade un nuevo valor restartPolicy: Always a los contenedores dentro de initContainers. Un init container con ese policy se comporta como un sidecar:

spec:
  initContainers:
  - name: envoy-proxy
    image: istio/proxyv2
    restartPolicy: Always   # ← nuevo en 1.28
  containers:
  - name: app
    image: my-app

El resultado:

  • Arranque ordenado: el sidecar se inicia primero y llega a Ready antes de que los containers principales arranquen.
  • Apagado ordenado: los containers principales reciben SIGTERM y tienen tiempo para cerrar. Luego los sidecars reciben SIGTERM.
  • Jobs completos: cuando el contenedor principal de un Job termina, los sidecars se paran automáticamente y el Job se considera completado.

El cambio es alpha en 1.28 (feature gate SidecarContainers). Se espera beta en 1.29 (diciembre 2023) y GA en 1.30 o 1.31.

Impacto en service meshes

Istio y Linkerd son los mayores beneficiarios. Ambos llevan años gestionando los problemas de orden manualmente. Con sidecars nativos:

  • Istio puede eliminar su lógica holdApplicationUntilProxyStarts a medio plazo.
  • Los Jobs y CronJobs con inyección de sidecar dejan de necesitar traffic.sidecar.istio.io/excludeOutboundPorts para terminar.
  • La transición ambient mesh de Istio — que elimina sidecars — sigue siendo válida, pero para equipos que no quieran migrar a ambient, los sidecars nativos son una mejora sustancial sin cambio de arquitectura.

Impacto en observabilidad

El patrón sidecar para agentes de observabilidad (Fluent Bit, Vector, OpenTelemetry Collector) también se beneficia:

  • Un agent sidecar puede ahora consumir los últimos logs del pod al apagarse, sin perder los datos del momento de shutdown.
  • Sidecars de seguridad (Vault Agent, Falco) arrancan antes de que la app haga su primer request.

Relacionado, ver nuestra cobertura sobre Pixie como alternativa eBPF a sidecars de observabilidad — ambas filosofías coexistirán.

Cómo prepararse

En alpha, la feature no debe usarse en producción todavía, pero la preparación empieza ahora:

  1. Testea en staging con 1.28. Crea un cluster con el feature gate SidecarContainers=true y reescribe 1-2 stacks críticos (uno con Istio, uno con Jobs) usando la nueva sintaxis.
  2. Identifica workarounds que se podrán eliminar. Busca en tus manifests preStop, holdApplicationUntilProxyStarts, shareProcessNamespace: true con scripts de traps. Documentarlos para limpieza post-GA.
  3. Coordina con proveedores de service mesh. Istio y Linkerd publicarán guías de migración en los próximos 6-12 meses.

Cambios adicionales en 1.28

Otros cambios notables que acompañan a sidecars en 1.28:

  • Graduación de features hacia stable: volume expansion, pod topology spread constraints, validating admission policy.
  • Cgroup v2 estable: ya no es experimental, elimina muchas sorpresas de memory accounting.
  • Mejoras en scheduling: pod scheduling readiness, mejor manejo de DRA (Dynamic Resource Allocation) para GPUs.

Ver el changelog completo de Kubernetes 1.28 para el conjunto total de 45+ KEPs incluidos.

Conclusión

Sidecars nativos son uno de los cambios con mayor impacto en patrones establecidos de despliegue, y merecen atención temprana aunque todavía estén en alpha. Para equipos que operan service meshes o pipelines con CronJobs y sidecars, la transición simplifica código y runbooks — un raro caso donde una feature de Kubernetes elimina complejidad en lugar de añadirla.

Síguenos en jacar.es para más sobre Kubernetes, platform engineering y arquitectura cloud-native.

Entradas relacionadas