Kubernetes 1.28: Sidecar Containers as First-Class Citizens

Actualizado: 2026-05-03

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

Key Takeaways

• Sidecars weren’t first-class citizens in Kubernetes: no guaranteed startup order, no correct shutdown sequencing.
• KEP-753 adds restartPolicy: Always to initContainers, turning an init container into a sidecar.
• The change arrives as alpha in 1.28 (feature gate SidecarContainers).
• Immediate beneficiaries: Istio, Linkerd, observability agents, and CronJobs with sidecars.
• The pattern simplifies existing code — a rare case where Kubernetes removes complexity instead of adding it.

The Problem It Solves

Sidecar containers weren’t first-class citizens in Kubernetes. Three concrete pathologies:

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^[1] 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), with beta expected in 1.29 and GA in 1.30 or 1.31.

Service-Mesh Impact

Istio^[2] and Linkerd^[3] 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^[4] 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^[5], Vector^[6], OpenTelemetry Collector^[7]) 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 the coverage of Pixie as an eBPF alternative to observability sidecars — both philosophies will coexist. The decision to use sidecars vs plain eBPF depends on the isolation level and VRAM overhead each team can accept.

How to Prepare

In alpha, the feature shouldn’t be used in production yet, but preparation starts with these three steps:

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 coming 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^[8] for the total set of 45+ KEPs included.

Conclusion

Native sidecars are one of the changes with the 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.

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