Why Kubernetes 1.28 Finally Makes Sidecars First‑Class Citizens

Introduction

If you use Kubernetes you have probably heard the term sidecar . The concept underpins many cloud‑native building blocks, especially service meshes. Until Kubernetes 1.28 there was no built‑in sidecar concept; the merge of the sidecar KEP finally adds sidecars to the Kubernetes API.

Pods, containers, and init containers

Kubernetes organizes applications into Pods, the smallest addressable unit. A Pod contains one or more containers that share a unique IP address. Pods can also contain init containers , which run to completion before regular containers start. Init containers can terminate, and once all init containers finish, the regular containers run until the Pod itself terminates.

What is a sidecar?

A sidecar is a container that runs alongside the main application container within the same Pod, much like a motorcycle sidecar. Its sole distinction is its purpose: to augment the application at runtime without any code changes, while sharing the same operational and security context.

This model lets you add functionality—such as metrics collection, logging, or network proxies—without recompiling or relinking the application, and it benefits from the same failure handling, security policies, and resource accounting as the primary container.

Common sidecar use cases

Typical sidecars include metric agents that scrape application metrics, log aggregators that forward logs, and service‑mesh proxies that intercept all TCP traffic to provide features like mutual TLS, fine‑grained HTTP metrics, retries, and transparent cross‑cluster communication. Many meshes use Envoy; Linkerd uses a lightweight Rust‑based proxy.

Do we really need sidecars?

Sidecars are controversial. Some argue that service‑mesh functionality belongs in the network layer rather than inside each Pod, making the sidecar feel out of place. Alternatives such as eBPF‑based or HBONE‑based meshes move the core logic out of the Pod but still rely on a proxy somewhere in the node or namespace.

Problems with sidecars

Upgrading a sidecar requires restarting the whole Pod. Because Pods are immutable, any change to a container forces a full Pod restart, which can be disruptive despite Kubernetes’ rolling‑update mechanisms.

A sidecar can prevent a Job from terminating. Jobs lack a signal to tell a sidecar to stop, so a sidecar may keep the Pod alive indefinitely unless special work‑arounds (e.g., linkerd‑await ) are used.

A sidecar may race with the application at startup. Regular containers have no ordering guarantee, so an application cannot assume the sidecar is ready when it starts, potentially causing connection failures.

Work‑arounds include using the postStart hook to block subsequent containers until the sidecar is ready, and the “default container” feature introduced in Kubernetes 1.27 to make the application container the default for kubectl logs.

Kubernetes 1.28 changes

The sidecar KEP becomes an Alpha feature in 1.28 and introduces a new RestartPolicy field for init containers. The only allowed value is Always, which makes an init container behave like a sidecar: it starts before regular containers, restarts if it crashes, and terminates only after all regular containers have finished.

Now you can set RestartPolicy: Always for init containers.

This creates a sidecar container.

The sidecar starts before all regular containers and terminates after they finish.

If the sidecar dies while regular containers run, it is automatically restarted.

Other init containers do not wait for the sidecar to complete, avoiding long delays.

Effectively, this adds a “background container” pattern (akin to the historic TSR program) that solves the Job‑termination and startup‑race problems identified earlier.

Impact and future outlook

While the new KEP resolves two major pain points, challenges remain: sidecars are visible in every Pod, which can clash with traditional network thinking, and they consume noticeable resources. Linkerd’s Rust implementation keeps its footprint low, but broader adoption still faces visibility and resource‑usage concerns.

References

Buoyant blog: https://buoyant.io/blog/kubernetes-1-28-revenge-of-the-sidecars

Why Linkerd doesn’t use Envoy: https://linkerd.io/2020/12/03/why-linkerd-doesnt-use-envoy/

eBPF sidecars and the future of the service mesh: https://buoyant.io/blog/ebpf-sidecars-and-the-future-of-the-service-mesh

linkerd‑await: https://github.com/linkerd/linkerd-await

Sidecar KEP: https://github.com/kubernetes/enhancements/issues/753

TSR (Terminate‑and‑Stay‑Resident) program: https://en.wikipedia.org/wiki/Terminate-and-stay-resident_program

Tweet about removing sidecars from Linkerd: https://twitter.com/wm/status/1577081662848241664

Tweet explaining the joke: https://twitter.com/wm/status/1577437965969940480?lang=en