📋 Recommended Actions
✅ No Immediate Action Required
No immediate action required for most users. OpenShift users leveraging TPROXY mode should review the update for critical fixes. All Gateway API users should be aware of internal VirtualService naming changes for generated resources.
📝 Summary
Istio 1.26.2 delivers targeted fixes and crucial consistency improvements, especially for OpenShift and Gateway API users. A significant bug has been resolved for OpenShift deployments utilizing TPROXY mode, which previously suffered from incorrect UID and GID assignments for sidecar containers. This fix ensures proper operation and security context enforcement. The release also brings enhanced robustness to Gateway API status reconciliation. Internal logic now intelligently compares desired and live states before writing, dramatically reducing redundant status updates and handling concurrent modifications more gracefully. This means a more stable control plane experience. Furthermore, the naming convention for auto-generated VirtualServices from HTTPRoutes has been refined for consistency, adopting a new scheme that directly reflects the merge key. While an internal detail, this can impact tools relying on generated resource names. Finally, internal integration tests gain greater flexibility with a new flag to control Gateway API deployment, alongside a fix for Kind cluster registry redirection. This patch release focuses on improving stability and correctness for specific deployment scenarios and advanced users.
🐛 OpenShift TPROXY Sidecar Injection Fix
OpenShift users leveraging TPROXY mode can now breathe a sigh of relief. This release addresses a critical bug where the istio-proxy and istio-validation containers were assigned incorrect User IDs (UIDs) and Group IDs (GIDs) when using TPROXY interception mode. This fix ensures that sidecar containers are injected with the correct security contexts, resolving deployment failures and maintaining expected permissions.
The fix involves a conditional logic update within the sidecar injection template. Specifically, when sidecar.istio.io/interceptionMode is set to TPROXY, the runAsUser and runAsGroup for the istio-proxy container, and the -u argument for the istio-iptables init container, are explicitly set to 1337. Previously, these values could be incorrectly derived or left as defaults, leading to permission issues on OpenShift’s more restrictive security contexts.yaml# Excerpt from manifests/charts/istio-control/istio-discovery/files/injection-template.yaml# For istio-iptables initContainer- "-u"- {{ if $tproxy }} "1337" {{ else }} {{ .ProxyUID | default "1337" | quote }} {{ end }}# For istio-proxy containersecurityContext: runAsGroup: {{ if $tproxy }} 1337 {{ else }} {{ .ProxyGID | default "1337" }} {{ end }} runAsUser: {{ if $tproxy }} 1337 {{ else }} {{ .ProxyUID | default "1337" }} {{ end }}
Source:
manifests/charts/istio-control/istio-discovery/files/injection-template.yaml(94-97, 167-170, 388-395)releasenotes/notes/56577.yaml(1-6)
✨ More Resilient Gateway API Status Updates
Keeping your Gateway API resources in sync is crucial, and Istio 1.26.2 makes this process even more robust. This release introduces significant enhancements to how the Istio Gateway API controller manages status updates, reducing unnecessary writes and improving conflict handling. This means a more stable and efficient control plane, especially in dynamic environments with frequent resource changes.
The internal KRT (Kubernetes Resource Table) library, used for processing and reconciling Kubernetes resources, now performs a smarter equality check before pushing status updates. Specifically, the registerStatus function now explicitly compares the liveStatus of an object with its desiredStatus. If they are identical, the write is suppressed. Additionally, optimistic locking conflicts (kerrors.IsConflict) are now logged at a debug level rather than error, preventing log spam in scenarios where concurrent updates are expected. A new generic GetStatus function streamlines status extraction for various Gateway API types.go// Excerpt from pilot/pkg/config/kube/gateway/status.gofunc registerStatus[I controllers.Object, IS any](c *Controller, statusCol krt.StatusCollection[I, IS], getStatus func(I) IS) { reg := func(statusWriter status.Queue) krt.HandlerRegistration { h := statusCol.Register(func(o krt.Event[krt.ObjectWithStatus[I, IS]]) { l := o.Latest() liveStatus := getStatus(l.Obj) // Extract live status if krt.Equal(liveStatus, l.Status) { // Compare live vs desired log.Debugf("suppress change for %v %v", l.ResourceName(), l.Obj.GetResourceVersion()) return } // ... enqueue status for writing ... }) return h } // ...}// Excerpt from pilot/pkg/status/manager.goif err != nil { if kerrors.IsConflict(err) { scope.Debugf("warning: object has changed %s/%s: %v", m.Namespace, m.Name, err) } else { // ... log error ... } return}
Source:
pilot/pkg/config/kube/gateway/backend_policies.go(84, 87, 90)pilot/pkg/config/kube/gateway/controller.go(217, 260, 263, 267, 271, 275, 279, 291)pilot/pkg/config/kube/gateway/conversion.go(2173-2195)pilot/pkg/config/kube/gateway/gatewayclass.go(102)pilot/pkg/config/kube/gateway/gatewayclass_collection.go(42-43)pilot/pkg/config/kube/gateway/status.go(65-88)pilot/pkg/config/kube/gateway/status_test.go(46-48)pilot/pkg/status/manager.go(39-47)pkg/kube/krt/collection.go(479)pkg/kube/krt/status.go(102-113)pkg/kube/krt/internal.go(159)pkg/kube/krt/static.go(112, 168)pkg/kube/krt/util.go(30)
🔄 Gateway API VirtualService Naming Refinement
For users relying on Istio’s Gateway API controller, this release introduces a subtle but important change to how auto-generated VirtualService resources are named. To improve internal consistency and ensure accurate mapping within the Kubernetes Resource Table (KRT) system, these generated names now incorporate the full “merge key” of the originating HTTPRoute resources. While primarily an internal change, it’s essential for anyone who might inspect or automate based on these generated resource names.
Previously, when multiple HTTPRoutes were processed, or even a single HTTPRoute was converted, the resulting VirtualService might have a name like http-0-istio-autogenerated-k8s-gateway. Now, the mergeHTTPRoutes function explicitly modifies the Meta.Name of the generated VirtualService to include the full KRT object.Key, with slashes replaced by tildes (~). This ensures that each generated VirtualService has a unique and descriptive name that reflects the specific combination of Gateway API routes it represents, preventing potential state corruption when multiple inputs map to the same output key.go// Excerpt from pilot/pkg/config/kube/gateway/route_collections.go// When dealing with a merge, we MUST take into account the merge key into the name.// Otherwise, we end up with broken state, where two inputs map to the same output which is not allowed by krt.// Because a lot of code assumes the object key is 'namespace/name', and the key always has slashes, we also translate the /nm.Name = strings.ReplaceAll(object.Key, "/", "~")
Source:
pilot/pkg/config/kube/gateway/route_collections.go(595-601, 608)pilot/pkg/config/kube/gateway/testdata/delegated.yaml.golden(43-43)pilot/pkg/config/kube/gateway/testdata/grpc.yaml.golden(24-24)pilot/pkg/config/kube/gateway/testdata/http.yaml.golden(21-21)pilot/pkg/config/kube/gateway/testdata/invalid.yaml.golden(62-62)pilot/pkg/config/kube/gateway/testdata/isolation.yaml.golden(81-81)pilot/pkg/config/kube/gateway/testdata/mesh.yaml.golden(21-21)pilot/pkg/config/kube/gateway/testdata/reference-policy-service.yaml.golden(21-21)pilot/pkg/config/kube/gateway/testdata/reference-policy-tls.yaml.golden(27-27)pilot/pkg/config/kube/gateway/testdata/route-binding.yaml.golden(303-303)pilot/pkg/config/kube/gateway/testdata/route-precedence.yaml.golden(22-22)pilot/pkg/config/kube/gateway/testdata/serviceentry.yaml.golden(24-24)pilot/pkg/config/kube/gateway/testdata/tls.yaml.golden(112-112)pilot/pkg/config/kube/gateway/testdata/valid-invalid-parent-ref.yaml.golden(24-24)pilot/pkg/config/kube/gateway/testdata/weighted.yaml.golden(43-43)pilot/pkg/config/kube/gateway/testdata/zero.yaml.golden(43-43)
⚙️ Enhanced Integration Test Control
Developers and contributors to Istio will find greater flexibility in running integration tests with this release. A new configuration option allows explicit control over the deployment of Gateway API resources during testing, streamlining test environments and reducing overhead when Gateway API is not the focus.
The Istio test framework now includes a DeployGatewayAPI boolean flag in its Config struct, defaulting to true. This enables test runners to disable Gateway API deployment via a command-line flag (--istio.test.kube.deployGatewayAPI=false), preventing unnecessary resource creation and potential conflicts in specific test scenarios. Additionally, the Kind cluster registry redirector setup has been refined to only apply its configuration if the cluster is indeed a Kind cluster, addressing issues observed in IPv6-only Kind environments.
Source:
pkg/test/framework/components/crd/gateway.go(55-57)pkg/test/framework/components/istio/config.go(105, 213-214)pkg/test/framework/components/istio/flags.go(73-76)tests/integration/README.md(560-560)tests/integration/ambient/registry_setup_test.go(35-51)
Minor Updates & Housekeeping
This release includes dependency updates for istio.io/api and istio.io/client-go to v1.26.2, a proxy dependency SHA update, and an adjustment to the BASE_VERSION in the Makefile. Additionally, a fix was applied to the base image builder script, and DeepCopy methods for Config objects now correctly handle Meta fields, ensuring robust object duplication.