Neu in Istio

Ab 1.31 veröffentlicht Istio nichts mehr auf gcr.io/istio-release, registry.istio.io und istio-release.storage.googleapis.com. Images liegen auf docker.io/istio, Helm-Charts auf blob.istio.io/istio-release/charts, OCI-Charts auf ghcr.io/istio/release/charts. Betroffen sind auch bestehende 1.30-Cluster, deren Default-Hub registry.istio.io/release ist. Die alten Orte gehen im Dezember 2026 vom Netz. Vorher gibt es Scream-Tests, in denen Pulls scheitern: am 13.10. (15 bis 18 Uhr UTC), am 17.11. (15 bis 21 Uhr UTC) und vom 08.12. 15 Uhr UTC für 24 Stunden. Ab 1.31.1 sind Images mit istio-key-v2.pub signiert.

Istio 1.31 baut auf Gateway API v1.6.0, in der TCPRoute auf v1 graduiert ist. istiod verarbeitet TCPRoute nur noch, wenn das CRD-Bundle mindestens v1.6.0 ist (TLSRoute mindestens v1.5.0, BackendTLSPolicy mindestens v1.4.0). Ressourcen aus älteren CRDs filtert istiod heraus. Neu meldet istioctl analyze das als IST0176, und istiod loggt es auf warn statt info. CRDs vor dem Istio-Upgrade einspielen.

istiod sendet unhealthy Endpoints jetzt standardmäßig mit, außer für Ziele, deren DestinationRule outlierDetection.minHealthPercent > 0 setzt (PILOT_AUTO_SEND_UNHEALTHY_ENDPOINTS). Ist kein Panic-Threshold konfiguriert, setzt Istio ihn dabei auf 0, Envoy routet also nicht auf unready Pods. PILOT_ENABLE_STRICT_GATEWAY_MERGING verhindert, dass Istio-Gateway-Ressourcen aus anderen Namespaces mit verwalteten Gateway-API-Gateways zusammengeführt werden. Beides nimmt das Helm-Profil compatibilityVersion=1.30 zurück. Der XDS-api-Generator verlangt eine Control-Plane-Identität, Rückweg nur über ENABLE_XDS_API_GENERATOR_AUTH=false. PILOT_SPAWN_UPSTREAM_SPAN_FOR_GATEWAY ist entfernt, der eigene Upstream-Span je Gateway-Request ist immer aktiv und hat kein Opt-out mehr.

Das HBONE-Label networking.istio.io/tunnel=http wird nur beim Anlegen einer auto-registrierten WorkloadEntry gesetzt. VM-Workloads, die vor dem Upgrade registriert wurden, werden weiter im Klartext erreicht, bis sie sich neu registrieren oder das Label von Hand an der bestehenden WorkloadEntry gesetzt wird.

MeshConfig.defaultTrafficPolicy setzt connectionPool und outlierDetection als Baseline für alle Outbound-Cluster. Eine DestinationRule überschreibt nur die Blöcke, die sie selbst setzt. zoneAwareLbSetting (DestinationRule und MeshConfig) überlässt Envoy das Routing in die eigene Zone mit Überlauf nach Kapazität. Das gilt nur im Sidecar-Modus und braucht ISTIO_META_ENABLE_SELF_DISCOVERY="true" in proxyMetadata. Neu ist auch der Outbound-Modus ALLOW_ANY_DYNAMIC_DNS: Klartext-HTTP zu unbekannten Hosts läuft ohne ServiceEntry über Envoys Dynamic Forward Proxy, TLS und TCP weiter über PassthroughCluster. Nur für Sidecars, nicht im Sidecar-CRD.

Ein Service oder Namespace kann über die Labels istio.io/use-waypoint-canary und istio.io/use-waypoint-canary-namespace zusätzlich einen Canary-Waypoint referenzieren. Die Annotation istio.io/use-waypoint-canary-weight steuert den Anteil der Verbindungen, ohne Änderung am Client. Die GatewayClass istio-agentgateway-waypoint setzt agentgateway als Waypoint ein. Ab etwa 40.000 Workloads überschreitet der WDS-Reconnect von ztunnel das gRPC-Limit von 4 MiB. Dann ISTIO_GPRC_MAXRECVMSGSIZE an istiod hochsetzen.

COMPLIANCE_POLICY=fips-140-3 erzwingt TLS 1.2/1.3 mit FIPS-konformen Cipher-Suites und den Kurven P-256/P-384, Envoy nutzt dafür FIPS_202205. istiod und istio-agent müssen mit Go 1.24+ und GOFIPS140=v1.0.0 gebaut sein, GOEXPERIMENT=boringcrypto ist damit unverträglich. In AuthorizationPolicy filtern source.trustDomains und notTrustDomains nach der Trust-Domain aus dem Peer-Zertifikat.

Istio 1.30 liest TLSRoute und ReferenceGrant aus dem Standard-Channel von Gateway API v1.5.1. Wer Istio hochzieht, ohne die CRDs mitzuziehen, verliert diese Ressourcen still: bestehende TLS-Passthrough-Listener melden attachedRoutes: 0 und der Envoy-Listener wird nicht programmiert. CRDs vor dem Istio-Upgrade anwenden.

Bei mehrdeutigen Hostnamen über mehrere Namespaces bevorzugen Sidecars jetzt einen Kubernetes-Service und fallen sonst auf den ältesten Nicht-K8s-Service zurück, statt alphabetisch den ersten sichtbaren Namespace zu nehmen. Das kann Traffic still auf eine andere Instanz umlenken. Rückweg: PILOT_SIDECAR_PICK_BEST_SERVICE_NAMESPACE=false oder compatibilityVersion 1.28.

syncz und config_dump verlangen jetzt Authentifizierung, gesteuert über ENABLE_DEBUG_ENDPOINT_AUTH mit Default true. Das trifft istioctl mit --plaintext und eigene Tools, die Plaintext-XDS sprechen. DEBUG_ENDPOINT_AUTH_ALLOWED_NAMESPACES erlaubt zusätzliche Namespaces.

Erstmals ein dokumentierter, schrittweiser Pfad von einem bestehenden Sidecar-Mesh nach Ambient, inklusive Policy-Migration und Aktivierung pro Namespace. Sidecar- und Ambient-Workloads koexistieren während der Umstellung, der Weg ist umkehrbar.

Eine einheitliche Alpha-API für Wasm-Module aus OCI-Registries und inline-Lua auf Sidecars, Gateways und Waypoints. Löst WasmPlugin als empfohlenen Erweiterungsmechanismus ab und macht EnvoyFilter für Lua-Skripte überflüssig. Bestehende WasmPlugin-Ressourcen laufen weiter, Istio übersetzt sie intern.

Mit der Annotation ambient.istio.io/xfcc-include-client-identity synthetisiert der Waypoint x-forwarded-client-cert aus der von ztunnel gelieferten SPIFFE-Identität, damit Anwendungen den ursprünglichen Client sehen. ServiceEntry akzeptiert jetzt CIDR-Adressen, ambient routet damit ganze IP-Bereiche per Longest-Prefix-Match ohne Einzel-Workloads.

Experimenteller Support für agentgateway, aktiviert über PILOT_ENABLE_AGENTGATEWAY. Der Proxy ersetzt Envoy auf dem Gateway-Pod, hängt als eigene GatewayClass istio-agentgateway ein und zielt auf AI-Agent- und MCP-Server-Traffic. Nur als Gateway, nicht als Sidecar oder Waypoint.

1.30 stellt den Default-Hub auf registry.istio.io/release um, doch beide bisherigen Registries werden im Dezember 2026 abgeschaltet, gcr.io/istio-release ebenso wie registry.istio.io/release. Vorher gibt es Scream-Tests mit Ausfällen. 1.30 ist die letzte Minor, die dort veröffentlicht wird. Zielbild ist docker.io/istio, sinnvollerweise hinter einem Pull-Through-Cache.

DNS-Capture ist für Ambient-Workloads jetzt per Default an, ebenso die iptables-Reconciliation beim Start des istio-cni-DaemonSet. Letzteres ersetzt den bisherigen manuellen Eingriff, damit bereits eingebundene Pods nach einem CNI-Upgrade aktuelle Regeln bekommen. Bestehende Pods bekommen DNS-Capture über diese Reconciliation beim Upgrade von istio-cni; ist sie abgeschaltet, brauchen sie einen Neustart.

Der Schwerpunkt lag auf Telemetrie: Waypoints werden korrekt in L4-Metriken gemeldet, Peer-Metadaten werden im Ambient-Datenpfad ausgetauscht, sodass Requests über ein East-West-Gateway vollständig attribuiert sind.

Von Alpha auf Beta gehoben, konform zu v1.0.1 der Spezifikation, aktiviert über ENABLE_GATEWAY_API_INFERENCE_EXTENSION. Die InferencePool-CRD kombiniert mit Gateway und HTTPRoute steuert die Lastverteilung auf selbst gehostete Modelle.

ztunnel prüft Certificate Revocation Lists und weist widerrufene Zertifikate ab, relevant bei eingebrachten externen CAs. Zusätzlich lassen sich Default-NetworkPolicies für istiod, istio-cni und ztunnel mit ausrollen.

Auf Port 15014 sind Nicht-System-Namespaces auf config_dump, ndsz und edsz beschränkt und dürfen nur Proxies im eigenen Namespace abfragen. Das trifft Kiali und eigene Monitoring-Tools. 1.30 zieht dieselbe Logik auf Port 15010 nach.

Die in früheren Releases nach istiod kopierten Konfigurationen sind aus dem base-Chart verschwunden. ClusterRole istiod heißt jetzt istiod-clusterrole, ClusterRole istiod-reader wird istio-reader-clusterrole, ServiceAccount istiod-service-account wird istiod. Auch das Suffix-Schema wechselt vom Istio-Namespace auf die Revision.

IPv4/IPv6-Dual-Stack ist von Alpha auf Beta gehoben und damit für Umgebungen einsetzbar, die beide Protokollversionen parallel fahren. Die InferencePool-API erreicht v1.0.0, Alpha- und Release-Candidate-Versionen werden nicht mehr unterstützt.

Ambient kann die Verkehrsumlenkung über nftables statt iptables regeln, aktiviert mit values.global.nativeNftables. Ergänzt den bereits vorhandenen nftables-Support im Sidecar-Modus.

BackendTLSPolicy v1 mit vollem Gateway-API-1.4-Support, ServiceEntry als targetRef in BackendTLSPolicy für externe Dienste, und FrontendTLSValidation für mTLS am Ingress-Gateway. RequestAuthentication akzeptiert über spaceDelimitedClaims eigene leerzeichengetrennte JWT-Claims neben scope und permission.

Nur noch v1 BackendTLSPolicy wird gelesen. Bei InferencePool wandert endpointPickerRef.portNumber nach endpointPickerRef.port.number, das Feld ist Pflicht und Port 9002 wird nicht mehr angenommen.

Die Pilot-Umgebungsvariablen METRIC_ROTATION_INTERVAL und METRIC_GRACEFUL_DELETION_INTERVAL sind entfernt. Ersatz ist die Pod-Annotation sidecar.istio.io/statsEvictionInterval mit der neuen Stats-Eviction-API.