Actualizado: 2026-07-07

Kubernetes 1.28 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.

Puntos clave

  • Los sidecars no tenían soporte nativo en Kubernetes: sin orden garantizado de arranque ni apagado correcto.

  • KEP-753 añade restartPolicy: Always a initContainers, que convierte un init container en sidecar.

  • El cambio llega en alpha en 1.28 (feature gate SidecarContainers).

  • Beneficiarios inmediatos: Istio, Linkerd, agentes de observabilidad y CronJobs con sidecars.

  • El patrón simplifica código existente; raro caso donde Kubernetes elimina complejidad en lugar de añadirla.

El problema que resuelve

Los contenedores sidecar no estaban integrados de primer nivel en Kubernetes. Tres patologías concretas:

  • Sin 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.

  • 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.

  • 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 problema 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[1] 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), con beta esperada en 1.29 y GA en 1.30 o 1.31.

Impacto en service meshes

Istio[2] y Linkerd[3] 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[4] 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[5], Vector[6], OpenTelemetry Collector[7]) también se beneficia:

  • Un agent sidecar puede ahora consumir los últimos logs del pod al apagarse, sin perder datos del momento de shutdown.

  • Sidecars de seguridad (Vault Agent, Falco) arrancan antes de que la app haga su primer request.

Logotipo de containerd, el runtime subyacente que gestiona el ciclo de vida de los sidecar containers en KubernetesLogotipo de containerd, el runtime subyacente que gestiona el ciclo de vida de los sidecar containers en Kubernetes

Relacionado, ver la cobertura sobre Pixie como alternativa eBPF a sidecars de observabilidad. Ambas filosofías coexistirán. La decisión de usar sidecars o eBPF plano depende del nivel de aislamiento y del overhead de VRAM que cada equipo pueda asumir.

Cómo prepararse

En alpha, la feature no debe usarse en producción todavía, pero la preparación empieza con estos tres pasos:

  • Prueba 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.

  • Identifica workarounds que se podrán eliminar. Busca en tus manifests preStop, holdApplicationUntilProxyStarts, shareProcessNamespace: true con scripts de traps. Documéntalos para limpieza post-GA.

  • Coordina con proveedores de service mesh. Istio y Linkerd publicarán guías de migración en los próximos meses.

Cambios adicionales en 1.28

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

  • Graduación a 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[8] 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, raro caso donde una feature de Kubernetes elimina complejidad en lugar de añadirla.

Fuentes

  1. KEP-753
  2. Istio
  3. Linkerd
  4. ambient mesh
  5. Fluent Bit
  6. Vector
  7. OpenTelemetry Collector
  8. changelog completo de Kubernetes 1.28