Neu bei Istio, Linkerd und Cilium

Ab 1.31 veröffentlicht Istio nichts mehr nach gcr.io/istio-release, registry.istio.io und istio-release.storage.googleapis.com, abgeschaltet werden diese Quellen im Dezember 2026. Images kommen von docker.io/istio, Helm-Charts von blob.istio.io/istio-release/charts oder als OCI von ghcr.io/istio/release/charts. Die verbleibenden Scream-Tests schalten die alten Quellen zeitweise ab, jeweils ab 15:00 UTC: am 13.10. (3 h), 17.11. (6 h) und vom 08. auf den 09.12.2026 (24 h). Ab 1.31.1 sind die Images mit einem neuen Schlüssel signiert, Signaturprüfungen brauchen istio-key-v2.pub.

Beim Reconnect meldet ztunnel jetzt zu jeder WDS-Ressource auch die Version. Die Anfrage kann damit schon ab rund 40.000 Workloads das 4-MiB-Empfangslimit von istiod überschreiten, bisher lag die Grenze bei etwa 55.000, mit langen Ressourcennamen oder vielen Services früher. ztunnel hängt dann mit ResourceExhausted in einer Reconnect-Schleife. Gegenmittel ist ISTIO_GPRC_MAXRECVMSGSIZE an istiod, etwa 1 MiB je 10.000 Workloads und Services.

istiod schickt nicht bereite Endpunkte jetzt standardmäßig mit an die Proxies, außer dort, wo die DestinationRule outlierDetection.minHealthPercent > 0 setzt. Das alte Verhalten liefert PILOT_AUTO_SEND_UNHEALTHY_ENDPOINTS=false oder ein Kompatibilitätsprofil zurück. Außerdem ist PILOT_SPAWN_UPSTREAM_SPAN_FOR_GATEWAY entfernt, der eigene Upstream-Span am Gateway ist damit immer aktiv.

PILOT_ENABLE_STRICT_GATEWAY_MERGING ist neu und per Default an. Istio-Gateway-Ressourcen aus anderen Namespaces werden nicht mehr mit den Proxies gemanagter Gateway-API-Gateways zusammengeführt. Wer bei der Umstellung auf Gateway API alte networking.istio.io-Gateways aus einem anderen Namespace per Selector an die neuen Gateway-Pods gehängt hat, verliert diese Listener. Manuell deployte Gateways sind nicht betroffen, false stellt das alte Verhalten her.

COMPLIANCE_POLICY=fips-140-3 erzwingt TLS 1.2 oder 1.3 mit FIPS-konformen AES-GCM-Cipher-Suites und beschränkt den Schlüsselaustausch auf P-256 und P-384; Envoy nutzt dafür die native Policy FIPS_202205. istiod und istio-agent müssen mit Go 1.24+ und GOFIPS140=v1.0.0 gebaut sein, GOEXPERIMENT=boringcrypto (FIPS 140-2) ist damit nicht kombinierbar. Gesetzt wird die Policy per Helm, etwa --set pilot.env.COMPLIANCE_POLICY=fips-140-3.

meshConfig.defaultTrafficPolicy setzt eine Baseline für connectionPool und outlierDetection, die alle ausgehenden Cluster erben. Die Vererbung gilt je Block: Setzt eine DestinationRule einen der beiden Blöcke, ersetzt sie die Baseline dafür vollständig; einen Block, den sie nicht setzt, erbt sie jetzt von der Mesh-Baseline statt von den Istio-Defaults. Die connectionPool-Baseline gilt auch für Inbound und den Passthrough-Cluster.

Der neue Modus ALLOW_ANY_DYNAMIC_DNS in meshConfig.outboundTrafficPolicy.mode löst unbekannte Ziele zur Laufzeit über den Host-Header auf (Envoy Dynamic Forward Proxy). Das gilt nur für Klartext-HTTP aus Sidecars, TLS und TCP laufen weiter über den PassthroughCluster, in der Sidecar-CRD wird der Modus nicht unterstützt. TLS-Origination ist optional über meshConfig.outboundTrafficPolicy.tls. In reinen IPv6-Clustern funktioniert der Modus erst ab 1.31.1.

Ein Service oder Namespace kann über die Labels istio.io/use-waypoint-canary bzw. istio.io/use-waypoint-canary-namespace zusätzlich einen Canary-Waypoint referenzieren. Die Annotation istio.io/use-waypoint-canary-weight lenkt einen einstellbaren Anteil der Verbindungen im Mesh dorthin, ohne Änderung an den Clients. Erst 1.31.1 unterwirft den Canary derselben Namespace-Isolation von serviceEntryVisibility wie den primären Waypoint.

Ab edge-26.9.1 dürfen Cluster-Credentials-Secrets für Multicluster keinen exec-Auth-Provider mehr enthalten, linkerd multicluster link erzeugt ohnehin Token-Auth. Link-Ressourcen werden nur noch im Namespace linkerd-multicluster gesucht. Wer die Secrets selbst mit exec-Plugin erzeugt, muss auf Token umstellen.

Erst edge-26.8.2 hebt die Gateway-API-Bindings von v1.2.1 auf v1.5.1. Bis edge-26.8.3 war TLSRoute fest an v1alpha2 gebunden, der Standard-Channel ab v1.5 liefert TLSRoute aber nur noch als v1 aus, die Routen wurden dann still ignoriert. edge-26.8.4 handelt die Version beim Start aus und bevorzugt v1. TCPRoute bleibt an v1alpha2 gebunden.

Ab edge-26.7.1 werden Verbindungen zu Ports, die ein Service nicht definiert, auch dann abgewiesen, wenn für den Service ein ServiceProfile existiert. Bisher lief dieser Traffic über die GetProfile-API durch, nur ohne ServiceProfile griff die Sperre. Wer sich darauf verlassen hat, sieht nach dem Upgrade abgewiesene Verbindungen.

Der Proxy wird jetzt als Init-Container mit restartPolicy: Always injiziert statt als regulärer Container. Das löst die alten Probleme mit Jobs, die nicht terminieren, und Startup-Races mit Init-Containern. Eingeführt in 2.15, Beta in 2.19, hier Default.

Die EWMA-Lastverteilung wertete HTTP 429 und gRPC RESOURCE_EXHAUSTED bisher als Erfolg und schickte wegen der niedrigen Latenz sogar mehr Traffic auf gedrosselte Endpunkte. Der neue Load Biaser setzt stattdessen einen Strafwert als Latenz an (load-biaser-penalty, Default 5 s), bei HTTP 429, 503, allen anderen 5xx und gRPC-Fehlercodes, und berücksichtigt Retry-After bis load-biaser-max-retry-after (Default 300 s). Opt-in je Service über die Annotation penalize-failures. Als experimentell markiert sind nur die Erfolgsquoten-Parameter des neuen Unified Failure Accrual (alpha-Präfix).

Die interne Zustandsverwaltung wurde umgebaut, der Speicherverbrauch fällt bei hohem Pod-Churn um bis zu 85 Prozent. Der Controller dominiert normalerweise den Speicherbedarf der Control Plane, das ist also der relevante Hebel in großen Clustern.

Ab edge-26.5.1 ist Kubernetes 1.31 die Untergrenze, 2.19 lag noch bei 1.23. Unterstützt bis 1.35. Zusätzlich wurde das proxy-init-Image in das proxy-Image gemergt: wer es explizit referenziert, etwa in einer Registry-Spiegelung oder Admission-Policy, muss die Referenz umstellen.

Cilium verlangt mindestens Gateway API v1.6.1, weil TLSRoute von v1alpha2 auf v1 gehoben wurde. Wer TLSRoute nutzt, muss die Experimental-Variante der CRD installieren, die v1alpha2 weiterhin enthält. Mit der Standard-Variante liest der API-Server bestehende TLSRoute-Objekte nicht mehr aus etcd und sie verschwinden faktisch aus dem Cluster.

Zusätzliche Listener-Gruppen docken als ListenerSet an ein Gateway an: das Plattform-Team betreibt das Gateway, Anwendungsteams halten ihre Listener und Zertifikate im eigenen Namespace. Dazu TLS bis zum Backend sowie TCP- und UDP-Routen, und TLSRoute ist nicht mehr als experimentell markiert.

Die SPIFFE-basierte Mutual Authentication ist abgekündigt, ein Entfernungstermin ist nicht genannt. Als Alternative nennt der Upgrade-Guide die in 1.19 als Beta eingeführte Ztunnel Transparent Encryption und bittet um Rückmeldung, ob sie die Anwendungsfälle abdeckt: ein Proxy pro Knoten übernimmt L4-mTLS zwischen Cilium-verwalteten Endpunkten. Nicht kompatibel mit Cluster Mesh.

Wer Authentifizierungsregeln in Policies nutzt und das Flag nicht ausdrücklich setzt, bekommt Verkehr ohne Authentifizierung weitergeleitet. Die Policy wird dann nur mit einer Validierungswarnung markiert. Beim Upgrade also explizit setzen.

Istio 1.31 baut gegen Gateway API v1.6.0 und installiert in der Doku v1.6.0, Cilium 1.20 verlangt mit aktiviertem Gateway-API-Support mindestens v1.6.1, Linkerd 2.20 ist nur bis v1.5.1 freigegeben. Die CRDs sind clusterweit, es gibt nur eine Version davon. Mit den v1.6-Standard-CRDs serviert der API-Server TCPRoute und TLSRoute nur noch als v1: Linkerd liest TCPRoute weiter als v1alpha2 und überspringt sie bis auf eine Log-Warnung, TLSRoute versteht es erst ab edge-26.8.4 (der Meilenstein 2.20 kennt nur v1alpha2). Die mitgelieferten CRDs aus linkerd-crds (seit 2.19 per Default aus, Bundle v1.1.1) blockt die safe-upgrades-Policy der Gateway API. HTTPRoute und GRPCRoute sind nicht betroffen. Wer Linkerd neben Istio-Ingress oder Cilium-Gateway-API fährt, bleibt bei HTTPRoute/GRPCRoute oder installiert den Experimental-Channel.

Seit Februar 2024 liefert das Open-Source-Projekt keine Stable-Artefakte mehr. Frei verfügbar sind die wöchentlichen Edge-Releases, ein Meilenstein wie 2.20 ist per Definition ein bestimmtes Edge-Release. Stable-Builds kommen von Vendoren. In regulierten Umgebungen entscheidet das die Auswahl häufig vor jedem Feature-Vergleich.