Istio 1.26 adds a supported path for generated gateway customization

An automatically created gateway Deployment still needs an operational configuration. Its owner may need a disruption budget or autoscaling settings that the controller's initial defaults do not express. Editing the generated object directly leaves an awkward question about whether the controller will preserve the edit during its next reconciliation.

The Istio 1.26 announcement on May 8 adds a supported customization path for resources created through Gateway API. A ConfigMap supplies parameters for the generated resources. This applies to ingress and egress gateways as well as ambient waypoints.

I find this kind of declarative customization more valuable than another way to patch a running proxy. Istio already requires managing an additional distributed system. Its operational settings should be inputs to the component that owns the generated objects, with a clear distinction between supported configuration and implementation-specific escape mechanisms.

Generated objects need declared inputs

Creating a Gateway or waypoint through Gateway API can cause Istio to create a Service and Deployment automatically. Those objects implement the requested gateway, but they also carry settings with consequences for availability and resource consumption. The gateway's routing rules do not answer every question about how its Pods should run.

The 1.26 change notes list Service, Deployment and ServiceAccount among the customizable generated resources. They also include HorizontalPodAutoscaler and PodDisruptionBudget. When configuration for the latter resources is supplied, the controller creates them as well.

That is a broader change than copying labels onto an existing Deployment. The controller can manage additional objects associated with the gateway's lifecycle. Their desired settings become part of the input used to provision the implementation, rather than independent manual changes someone must remember after recreation.

The important ownership relationship is between the Gateway, its customization parameters and the generated objects. A controller needs a source from which it can reconstruct the desired deployment. Configuring the generated object alone may not express that source. Supplying parameters gives reconciliation an explicit statement of the customization it should preserve.

This is especially useful for waypoints because their operational requirements can differ from an edge gateway's. A shared mechanism does not require identical replica or disruption settings. It provides the same supported place to declare the settings appropriate for each role.

The release also adds a separate control over manual gateway deployments. ENABLE_GATEWAY_API_MANUAL_DEPLOYMENT can disable automatic attachment of Gateway API resources to existing gateway deployments when set to false. Its default remains true for compatibility. This is another ownership decision, separate from customizing resources the controller creates itself.

EnvoyFilter is not a substitute for the supported waypoint API

The announcement explicitly states that EnvoyFilter is unsupported with waypoint proxies in every existing Istio version. Some limited configurations may happen to work, but maintainers discourage relying on them. The API is alpha and can change as waypoint support evolves.

That statement needs to be read alongside the new customization support. A ConfigMap that controls generated Kubernetes resources changes the gateway's deployment configuration. An EnvoyFilter changes Envoy configuration at a different level. They are not interchangeable ways to express the same supported contract.

The release adds the ability for EnvoyFilter to match a VirtualHost by domain name. That addition does not override the explicit waypoint limitation. A feature added to the API in one supported context cannot be assumed to establish support in every proxy role that also uses Envoy.

This matters during ambient adoption. An existing sidecar installation may rely on detailed EnvoyFilter behavior. Moving its traffic through a waypoint is not evidence that the same filter patch remains supported merely because the proxy binary is related. The support boundary depends on the role and configuration path.

I consider the explicit limitation useful. It makes a migration dependency visible before a particular generated filter arrangement becomes part of an application's assumptions. Supported policy and routing APIs need to carry the required behavior, or the dependency remains an unsupported one.

New Gateway API capabilities have separate maturity controls

Istio 1.26 adds TCPRoute support to waypoint proxies, enabling TCP traffic shifting in ambient mode. That extends the traffic-management role of a waypoint beyond HTTP-specific routing. It does not imply that TCP traffic gains HTTP request metadata or that all HTTP-oriented policy operations apply to the connection.

The change notes also introduce initial support for BackendTLSPolicy and XBackendTrafficPolicy from Gateway API. These are experimental capabilities and are disabled by default. They require PILOT_ENABLE_ALPHA_GATEWAY_API to be true. The announcement describes retry constraints as a direction of the backend traffic policy implementation, rather than presenting the whole intended behavior as complete.

This creates several independent compatibility decisions. A gateway can use the supported generated-resource customization while leaving experimental policy support disabled. A waypoint can gain TCPRoute behavior without establishing support for an arbitrary EnvoyFilter. Each capability has its own activation and support conditions.

Keeping those distinctions explicit is important because a release announcement naturally groups changes under Gateway API. The API family name is not a maturity level. The specific resource and feature gate determine which contract is being adopted.

Trust-bundle integration is experimental

The release adds experimental support for Kubernetes ClusterTrustBundle. The detailed notes identify the v1alpha1 API and the ENABLE_CLUSTER_TRUST_BUNDLE_API setting in the pilot environment. They also require the corresponding Kubernetes feature gates, so enabling the Istio side alone is insufficient.

This is an integration with another API's lifecycle. An Istio installation cannot assume that the Kubernetes cluster serves the required resource simply because the mesh recognizes it. The cluster configuration and mesh configuration must agree about availability.

The feature should also be distinguished from ordinary use of certificates already supported by Istio. Adding a new way to obtain trust information is not a declaration that every existing certificate path now depends on ClusterTrustBundle. It is an optional integration with explicit experimental status.

The change notes separately permit a DestinationRule in SIMPLE TLS mode to reference a ConfigMap when only a CA certificate is required. That distinguishes public trust material from the credentials normally associated with a Secret reference. It is another concrete configuration improvement, with a narrower scope than a wholesale replacement of certificate management.

Installation changes can alter resource identity

The upgrade notes reverse a ztunnel chart naming change from 1.25. The chart again defaults to a static ztunnel resource name because release-derived naming required coordination with the istiod chart and caused problems. A resourceName override remains available.

This is relevant to automation that assumes the Helm release name determines every resource name. The generated Kubernetes identity is part of the installation contract. A change in that identity can affect references independently of whether the desired proxy version is correct.

The CNI agent also stops requiring hostNetwork by default. The change notes describe dynamic switching into the host network when needed, with a temporary compatibility setting to restore the earlier approach. This reduces conflicts with other host services without removing the agent's need to perform node-level networking work.

The Kubernetes support statement has a similarly specific boundary. Istio 1.26.0 officially supports Kubernetes 1.29 through 1.32. The announcement expects 1.33 to work but says testing and formal support are planned before 1.26.1. Expected compatibility is useful information, but it is not the same statement as completed support for the initial release. An installation record should preserve which combination actually has the project's support commitment.

Telemetry has a separate upcoming transition. The upgrade notes identify Lightstep and OpenCensus providers as deprecated and scheduled for removal in 1.27, with OpenTelemetry as their replacement. This is advance notice of a future removal, not a claim that both providers disappear in 1.26. The change notes add warnings to make that dependency visible now. Gateway deployment customization does not migrate a tracing provider, so an installation can adopt the new configuration mechanism while still needing a separate telemetry change before its next minor upgrade.

These changes show several forms of configuration becoming more explicit. Generated gateways gain declared operational parameters. Waypoint extensions receive a clear support boundary. Trust-bundle support requires coordinated feature availability, and chart naming retains a deliberate override. The practical task for an installation is to identify which of those inputs it relies on, so a supported customization does not conceal a separate experimental dependency.