Istio 1.6 gives control plane upgrades a canary boundary

Istio can direct a small share of application traffic to a new deployment, but upgrading the mesh itself has exposed a broader set of workloads at once. The old control plane upgrade arrangement put old and new instances behind the same Service. A proxy could reach either version without the operator choosing that relationship. Istio 1.6 introduces revisions to make the proxy's control plane selection explicit.

The May 21 release announcement combines that lifecycle change with completion of the istiod transition. Separate Citadel, Galley, and sidecar injector deployments are removed after their functions moved into istiod. WorkloadEntry gives non-Kubernetes workloads an explicit mesh representation. These changes improve how the system is operated, but they address different kinds of state and ownership.

I find control plane canaries especially relevant to the cost of adopting a mesh. Moving application policy into Istio also makes application behavior depend on the mesh's configuration machinery. An upgrade mechanism that lets operators select which proxies receive a new control plane version reduces the scope of that dependency during a transition.

A revision identifies a proxy's control plane

John Howard's May 19 description of canary control planes explains the mechanism. Each independent control plane has an istio.io/rev label. A new version can run alongside the existing version, and proxies do not connect to it until the operator selects it for workloads.

Selection occurs through the sidecar injection webhook. A revision's webhook selects namespaces with the matching label and configures injected proxies to connect to that control plane. The resulting proxy stays with the same revision for its lifetime. This avoids changing control plane versions simply because another instance behind a shared endpoint receives the connection.

A namespace intended for a revision named canary therefore has the following label. It replaces istio-injection=enabled when using the revision model described in the article.

metadata:
  labels:
    istio.io/rev: canary

This fragment expresses selection, not the installation of the revision itself. It also does not claim that modifying a namespace changes the configuration of an already running proxy. The explanation ties selection to injection and says a proxy retains its revision during its lifetime. Workload lifecycle and control plane installation remain separate steps in the transition.

That relationship is the useful canary boundary. Operators can migrate workloads gradually and compare their behavior through telemetry. A new control plane deployment no longer implies that every proxy might use it immediately. The release also retains an in-place istioctl upgrade path, so a revision-based transition is a specific operating choice.

Consolidation removes the old deployments

Istio 1.5 introduced istiod and disabled several separate deployments by default. The 1.6 change notes now remove those deployments and the legacy istio-pilot configuration, including its Service. The release completes the packaging transition instead of continuing to ship parallel arrangements for the same functions.

The practical effect is a smaller set of control plane components to install and understand. It does not remove the distinction between certificate provisioning, injection, and configuration distribution. Those responsibilities still exist inside the consolidated implementation, and their clients still need the correct configuration to reach it.

Installation also gains an explicit istioctl install command replacing istioctl manifest apply. Installation state can be saved in a custom resource in the cluster. These changes make the installed arrangement more inspectable and give the command-line workflow a direct name for the operation it performs.

The old Helm charts are removed. The upgrade notes say users migrating from that legacy installation method need a control plane revision and a canary upgrade rather than an in-place upgrade. They also state that skip-level upgrades are unsupported, so a 1.4 installation must pass through 1.5 before 1.6.

Alpha security policies no longer enforce policy

The security API transition is more consequential than an installation command rename. Istio 1.6 stops supporting the alpha authentication and RBAC policy APIs. The upgrade notes explicitly say it ignores those resources. An old policy remaining visible in the Kubernetes API therefore does not establish enforcement by the upgraded mesh.

The replacements are the beta request authentication, peer authentication, and authorization policy APIs. Operators need to migrate old policy before upgrading. This is a semantic migration because the new APIs express the relevant responsibilities through different resource types. Keeping old YAML in a repository cannot substitute for that conversion.

The notes also remove the global.mtls.enabled installation configuration and direct users to peer authentication policy for strict mTLS. That puts enforcement intent in the security policy API. It is distinct from the automatic mutual TLS transport behavior introduced earlier, and the distinction remains necessary when assessing which connections the mesh accepts.

I prefer enforcement to be stated in the policy object that owns it. That makes the intent easier to locate than an installation flag whose meaning can be mistaken for a universal access rule. In this release, the old resource and flag behavior is explicitly documented, so an upgrade needs to account for what the new implementation actually reads.

WorkloadEntry represents a workload beyond its address

The release introduces WorkloadEntry for workloads outside Kubernetes, including those on VMs or bare metal. The announcement describes its aim as giving those workloads a first-class representation comparable to a Pod in the mesh, instead of representing them only as IP endpoints. A Service can then have a mix of pod and VM backends.

That matters for incremental migration. A service does not have to move every instance into Kubernetes at the same time to participate in the same mesh service. The announcement presents heterogeneous backends as a way to move VM workloads while preserving traffic relationships. The common representation supplies a place for the non-Kubernetes workload in configuration.

This is not a claim that declaring a WorkloadEntry alone performs every installation or connectivity step on a VM. It describes a new API object and the service model it supports. The workload still needs the runtime and network arrangement required to participate in the mesh. Representation and successful communication are separate parts of the integration.

Telemetry configuration stops trusting arbitrary host labels

The change notes describe a concrete telemetry correction at gateways. Default Telemetry v2 no longer extracts the destination service name from the request's host header. The stated reason is avoiding unbounded metric cardinality derived from an untrusted value. Requests reaching blackhole or passthrough handling consequently omit destination service labels at the gateway.

That is a tradeoff in the information model. A label that appears descriptive can become an uncontrolled source of distinct time series when a requester chooses its value. Removing that derivation makes the default metric behavior more bounded, while reducing those labels for the specified requests. This is a mechanism-specific observability change, not a general promise about all metric cardinality.

The release also adds standard Prometheus scrape annotations to proxies and control plane workloads. It permits operators to add or remove labels in Istio metrics through expressions over request and response attributes. That provides more control over telemetry while making the chosen labels an explicit configuration responsibility.

Readiness changes affect infrastructure outside the mesh

Gateway readiness moves from port 15020 to 15021. The upgrade notes call out Kubernetes network load balancers checking the old port as affected integrations. Changing the mesh's internal health endpoint can therefore require a corresponding change in infrastructure that probes it. An unchanged external check can fail even if the new gateway behaves as designed.

The change notes also enable gateway SDS by default, while retaining file-mounted certificate support for transition. Those certificate delivery options are separate from the readiness endpoint and revision selection. Each integration has to use the interface the release now exposes.

Istio also accepts Kubernetes 1.18's alpha appProtocol field for port protocol selection. That offers an explicit protocol declaration in place of encoding the protocol in a Service port's name, when the relevant Kubernetes feature is available.

The revision model supplies the release's main improvement to upgrade control. Its guarantee is specific to the association configured for injected proxies, which remain on one revision for their lifetime. Policy migration and external health checks still need their documented changes, because limiting which workloads adopt a new control plane does not make ignored alpha policies or an obsolete probe port behave like the previous release.