Istio 1.27 changes sidecar lifecycle while expanding ambient scope

A proxy's position in a Pod specification can affect more than how it starts. Other controllers and mutating webhooks may locate that proxy under the ordinary containers list and modify it there. Moving the proxy into initContainers gives Kubernetes a better lifecycle contract, but it also changes the object those integrations expect to find.

The Istio 1.27 release on August 11 includes several traffic-management additions. Its upgrade notes identify a particularly consequential default change. Native sidecars are now enabled for eligible Pods, so istio-proxy becomes an init container in those workloads. This is an installation behavior change with effects beyond the proxy executable itself.

I value consistent traffic policy across applications, but that consistency depends on several components agreeing about the Pod they manage. Native lifecycle support is useful. The migration also needs an accurate account of which controllers inspect or change the injected proxy.

The injection output changes its contract with other controllers

The 1.27 upgrade notes explicitly warn about mutating webhooks and controllers that expect istio-proxy as an ordinary container. Such an integration can be logically independent of Istio's traffic policies while still depending on the structure produced by injection.

The default therefore changes what a later admission component sees. An integration that adds settings to spec.containers by matching the proxy name may no longer reach that proxy. A resource accepted by Kubernetes can still differ from what the integration author intended if the integration never examines initContainers.

This is a compatibility issue at the Pod-model boundary. It should not be reduced to whether the proxy binary starts successfully. The injected manifest is an interface consumed by other software, and changing its structure requires those consumers to support the new location.

The detailed change notes identify ENABLE_NATIVE_SIDECARS as defaulting to true. Compatibility profiles for earlier releases also gain a value allowing users to retain the earlier default. This creates a deliberate transition control, rather than requiring every installation to infer its behavior from the version alone.

The release describes the default in terms of eligible Pods. It does not claim every existing proxy is rewritten in place during a control plane upgrade. Injection is associated with Pod creation, so the relevant input for an integration is the manifest produced for the workload being admitted.

Native nftables is a separate sidecar option

Istio 1.27 also adds native nftables support for sidecar traffic redirection. This changes how network rules steer traffic to and from Envoy. It is independent of whether the proxy is represented as a native sidecar in the Pod lifecycle.

The announcement explicitly limits native nftables support to sidecar mode. Ambient support remains under development. An installation that uses ambient cannot infer native nftables support from the shared release number, and a sidecar installation does not select the backend automatically merely because the capability exists.

The change notes give an installation value for opting in. This fragment is an argument to an existing istioctl installation configuration, not a complete installation command.

--set values.global.nativeNftables=true

This is native use of the nftables backend for Istio's redirection rules. It should be distinguished from a system using an iptables command that happens to target nftables through a compatibility layer. The announcement's purpose is direct support for the newer rule-management framework.

It should also be distinguished from the kube-proxy Service backend. Kubernetes Service dispatch and Istio's transparent proxy redirection have different responsibilities. Changing one does not establish that the other component now uses the same implementation. A node networking inventory needs to record which component owns each set of rules.

These distinctions keep the release's scope concrete. Native sidecars concern lifecycle ordering. Native nftables concerns interception. Both can affect a sidecar workload, but enabling one does not imply that the other has been enabled or validated.

Ambient multicluster begins with a constrained topology

Ambient multicluster support arrives as alpha. The release says testing has focused on multi-network, multi-primary deployments in which every cluster runs its own control plane. More complicated topologies are future work. This is a particular supported testing focus for an early feature, not a promise that every sidecar multicluster arrangement can immediately migrate unchanged.

Connecting clusters expands the set of services that a data plane may discover. The release adds ServiceScope in MeshConfig for choosing local or global scope. A local service is discoverable only by data planes in its own cluster. A global service is discoverable across the connected clusters.

That is a discovery decision, which is distinct from an authorization rule. Making a service visible does not describe every caller permitted to use it. Likewise, excluding it from remote discovery is not a replacement for correctly enforcing access at its workload. Both concerns need a precise statement when a mesh spans cluster boundaries.

The change notes say service-scope selectors also affect the configuration shared with waypoints and east-west gateways. Scope therefore contributes to the generated traffic path, rather than serving only as a label shown to an operator. A declaration about visibility becomes input to which listeners and clusters the proxies receive.

Ambient capture also gains an opt-in protection for node restart. The change notes describe an Istio-owned CNI configuration containing the primary CNI configuration and the Istio plugin. Its purpose is to prevent traffic bypass when the agent or plugin is not ready or invoked. Enabling it requires ambient and chained CNI operation, plus an appropriately ordered configuration filename. This is another independent installation choice. Expanding discovery across clusters does not by itself guarantee that every newly started local Pod has entered the intended capture path.

I see the alpha boundary as useful information about where the integration has evidence. The existing appeal of workload identity extends across clusters only when discovery, transport and policy agree about that larger scope. The announcement identifies a baseline topology without claiming that every possible arrangement already has that agreement.

Inference support is present but remains opt-in

The release includes Gateway API Inference Extension for ingress traffic controlled through Gateway API. It describes a compliant implementation for that use. The detailed notes also say the feature is off by default and requires SUPPORT_GATEWAY_API_INFERENCE_EXTENSION to enable it.

Those statements answer different questions. Compliance describes how the implementation follows the extension's contract. The environment setting determines whether the installation activates it. Upgrading a gateway without changing that setting does not establish that an endpoint picker now makes its backend decisions.

The July introduction describes model-aware selection through a separate picker. The August release supplies the implementation in a release version. It does not remove the need for the extension's resources, serving metrics or picker service. Those remain part of the configured request path.

This also preserves the distinction between an ingress gateway and an ambient waypoint. The headline feature is scoped to cluster ingress through Gateway API. It should not be generalized into a claim that every ambient traffic path gains inference routing with the upgrade.

Trust and installation details still require precise inputs

Certificate Revocation List support is added for plugged-in certificate authorities. The change notes describe watching ca-crl.pem and distributing the revocation information so proxies can reject revoked certificates. This adds a revocation path for that CA configuration, rather than replacing the identity model of all mesh installations.

The release also repairs a dangerous fallback in plugged-in CA handling. An incomplete cacerts bundle previously allowed istiod to fall back silently to a self-signed CA. The new behavior validates the required files and returns an error when the bundle is incomplete. That makes a mistaken trust configuration visible instead of substituting another authority.

Multiple gateway certificate types are another separate addition. The upgrade notes explain that RSA and ECDSA certificates can be configured together so clients select an appropriate type. That concerns client compatibility at the gateway and does not itself supply revocation data or correct an incomplete CA bundle.

Taken together, these changes expand Istio while changing some established installation assumptions. The native-sidecar default affects consumers of the Pod structure. Nftables and inference support require opt-in settings, while ambient multicluster has an explicit alpha topology focus. The practical value of the release depends on recording those choices separately, so the presence of one capability is not mistaken for activation or maturity of another.