Kubernetes 1.28: Sidecar Containers as First-Class Citizens

javi
Estructura de contenedores en arquitectura Kubernetes

Kubernetes 1.28, scheduled for August 2023, introduces one of the most-anticipated improvements for teams operating service meshes: native sidecar containers. Until now the sidecar pattern — an additional container in the pod to add network proxy, logging, or security functionality — was implemented with regular containers, with heavy implications for startup order, graceful shutdown, and Job handling.

The Problem It Solves

Sidecars weren’t first-class citizens in Kubernetes. Specifically:

  1. No guaranteed startup order. Istio’s envoy proxy could start after the app container, which tried to connect to the network before the proxy was ready.
  2. Inverted shutdown order. On pod termination, the sidecar could close before the app, cutting traces, metrics, or logs of the last seconds.
  3. Jobs that never finish. A Job using a sidecar stays “Running” forever because the sidecar never terminates even when the application does.

Each problem had workarounds: preStop hooks, wrapper scripts, or Istio’s holdApplicationUntilProxyStarts mechanism. All fragile, all with sharp edges.

What 1.28 Introduces

KEP-753 adds a new restartPolicy: Always value to containers inside initContainers. An init container with that policy behaves as a sidecar:

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

The result:

  • Ordered startup: the sidecar starts first and reaches Ready before the main containers start.
  • Ordered shutdown: main containers receive SIGTERM and have time to close. Then sidecars get SIGTERM.
  • Complete Jobs: when a Job’s main container terminates, sidecars stop automatically and the Job is considered completed.

The change is alpha in 1.28 (feature gate SidecarContainers). Expected beta in 1.29 (December 2023) and GA in 1.30 or 1.31.

Service-Mesh Impact

Istio and Linkerd are the biggest beneficiaries. Both have spent years handling order problems manually. With native sidecars:

  • Istio can remove its holdApplicationUntilProxyStarts logic medium-term.
  • Jobs and CronJobs with sidecar injection no longer need traffic.sidecar.istio.io/excludeOutboundPorts to terminate.
  • Istio’s ambient mesh transition — which removes sidecars — remains valid, but for teams that don’t want to migrate to ambient, native sidecars are a substantial improvement without architectural change.

Observability Impact

The sidecar pattern for observability agents (Fluent Bit, Vector, OpenTelemetry Collector) also benefits:

  • An agent sidecar can now consume the pod’s last logs on shutdown, without losing data from the shutdown moment.
  • Security sidecars (Vault Agent, Falco) start before the app makes its first request.

Related, see our coverage of Pixie as an eBPF alternative to observability sidecars — both philosophies will coexist.

How to Prepare

In alpha, the feature shouldn’t be used in production yet, but preparation starts now:

  1. Test in staging with 1.28. Create a cluster with the SidecarContainers=true feature gate and rewrite 1-2 critical stacks (one with Istio, one with Jobs) using the new syntax.
  2. Identify workarounds that can be removed. Search your manifests for preStop, holdApplicationUntilProxyStarts, shareProcessNamespace: true with trap scripts. Document them for post-GA cleanup.
  3. Coordinate with service-mesh vendors. Istio and Linkerd will publish migration guides in the next 6-12 months.

Additional 1.28 Changes

Other notable changes accompanying sidecars in 1.28:

  • Features graduating to stable: volume expansion, pod topology spread constraints, validating admission policy.
  • Cgroup v2 stable: no longer experimental, removes many memory-accounting surprises.
  • Scheduling improvements: pod scheduling readiness, better DRA (Dynamic Resource Allocation) handling for GPUs.

See the full Kubernetes 1.28 changelog for the total set of 45+ KEPs included.

Conclusion

Native sidecars are one of the changes with biggest impact on established deployment patterns, worth early attention even in alpha. For teams operating service meshes or pipelines with CronJobs and sidecars, the transition simplifies code and runbooks — a rare case where a Kubernetes feature removes complexity instead of adding it.

Follow us on jacar.es for more on Kubernetes, platform engineering, and cloud-native architecture.

Entradas relacionadas