Native sidecars let Istio express the proxy's dependency role

An application and its mesh proxy share a pod but do not have equivalent lifecycle roles. The application may need the proxy before it can reach the network. The proxy has no reason to keep the pod active after the application has completed its work. Treating both as ordinary containers leaves Kubernetes without an explicit description of that dependency.

The August 15 Istio native-sidecar demonstration uses Kubernetes 1.28's new alpha sidecar-container support. It places istio-proxy among the init containers with restartPolicy: Always. The proxy starts in the ordered init sequence and keeps running while application work proceeds. The demonstration uses an Istio 1.19 prerelease because the integration has not yet shipped in an Istio release.

I regard the extra lifecycle machinery around a proxy as part of the cost of choosing a mesh. Native support is useful because it lets Kubernetes represent a relationship that otherwise needs coordination outside the ordinary container model. It also benefits helpers unrelated to Istio.

An init container can become a continuing dependency

The Kubernetes 1.28 announcement introduces the new restart policy specifically for init containers. Without that field, an init container retains its ordinary run-to-completion role. With Always, Kubernetes advances after startup instead of waiting for the container to exit.

That gives the proxy an appropriate position before application init work. Istio's example shows an init list containing istio-init, then istio-proxy, then an application init container. The application init container can make a network request after the proxy has started. Previously, an ordinary proxy container would not start until init work had completed.

The distinction is between finishing preparation and establishing a dependency that remains available. A regular init container cannot act as a long-running proxy because the next stage waits for it to finish. A restartable init container can establish the proxy early while leaving it running during later stages.

The Istio article traces a formal Kubernetes proposal to 2019 and describes a later restart of that work before the 1.28 alpha. That history explains why this event changes the platform model instead of adding another Istio-specific workaround. Applications using other kinds of helpers have the same mismatch between an ordinary container and a supporting process.

The source lists loss of network access at both ends of the application lifetime as an existing concern. A faster-starting application can run before its proxy, and a still-running application can lose the proxy during shutdown. These are opposite ends of the same declared dependency. Kubernetes needs to know that the helper's lifetime is related to the application's work, instead of treating their schedules as unrelated.

Kubernetes describes startup through the container's started state, including any configured startup probe and post-start handling. The Istio integration uses that lifecycle to hold later containers until its proxy is ready for the sequence to continue. The underlying mechanism is Kubernetes ordering, with Istio supplying the proxy-specific container definition.

The experiment has two activation points

The demonstration requires Kubernetes 1.28 with the SidecarContainers feature gate enabled. The Kubernetes feature is alpha and disabled by default. Its example then installs Istio 1.19.0-beta.0 with values.pilot.env.ENABLE_NATIVE_SIDECARS=true, enabling the corresponding Istio integration.

Those requirements prevent an overly broad reading of the event. Running Kubernetes 1.28 does not automatically transform an existing Istio sidecar into the native representation. The Kubernetes gate enables the API behaviour, while Istio's flag selects the injection behaviour that uses it. Both components must participate in the experiment.

The useful inspection is the resulting pod definition. Istio's article shows istio-proxy in spec.initContainers while the application remains in spec.containers. A familiar ready-container count alone does not reveal that distinction. The field location explains which lifecycle rules Kubernetes applies.

A read-only inspection can make the relationship visible.

kubectl --context=sidecar-test get pod example \
  -o jsonpath='{.spec.initContainers[*].name}'

The pod name and context are examples. This inspects the init list, following the article's inspection of the generated pod. The relevant evidence is that the proxy has the new representation, not simply that an installation command completed.

Bounded work can complete without a proxy exit convention

The demonstration also creates a pod whose application sleeps for one second and exits under pod restart policy Never. Its proxy remains a native sidecar. After the application exits, Kubernetes lets the pod transition to Completed and the sidecar exits shortly afterwards.

The important difference is that the proxy's continued execution no longer defines unfinished application work. A long-running ordinary container can keep a pod running after its main task ends. Native sidecar classification tells Kubernetes that this helper supports the main containers and should not prevent their completion.

That is useful for Jobs because their intended work has an end. A proxy cannot independently infer that end merely from being healthy or idle. Encoding the relationship in the pod lifecycle gives Kubernetes the information needed to stop the supporting process after the regular containers complete.

The article also discusses shutdown ordering and crashing-sidecar backoff as areas where the Kubernetes team wants feedback. Those requests are part of the alpha's status. They should not be replaced with claims about fully settled shutdown behaviour that belongs to a later release.

Ambient addresses a different coupling

Istio's ambient mode moves proxies outside application pods. Native sidecars keep the proxy in the pod while improving its lifecycle semantics. Solving startup and completion problems does not make the two deployment models identical. They place the data plane in different operating units.

I find the native change useful even when a fleet is evaluating ambient. A workload that retains a sidecar still benefits from a more explicit dependency relationship. Other helper containers can also need startup ordering and completion handling without being mesh proxies at all.

The August event remains a demonstration of prerelease integration. It provides concrete evidence that init-container networking and bounded pod completion can use the new model. Production recommendations remain constrained by the alpha Kubernetes feature and the unshipped Istio integration described in the article.