Weniger Ressourcen verbrauchen im Istio Ambient Mode
Ballast abwerfen
Veröffentlicht in Ausgabe 08/2026 - PRAXIS
Wer heute Microservices auf Kubernetes betreibt, stößt schnell auf Anforderungen, die sich mit Bordmitteln nicht oder nur umständlich umsetzen lassen. Durchgängige Verschlüsselung des internen Traffics, feingranulare Zugriffskontrolle zwischen Services, einheitliches Tracing über Servicegrenzen hinweg sowie intelligentes Trafficmanagement wie Canary Deployments gehören dazu. All das soll idealerweise geschehen, ohne eine einzige Zeile Code in der eigentlichen Anwendung zu ändern. Genau hier setzt ein Service Mesh an.
Ein Service Mesh schiebt sich als transparente Infrastrukturschicht zwischen die kommunizierenden Services. Mutual TLS (mTLS) sorgt für verschlüsselte Kommunikation zwischen allen Pods, ohne dass Entwickler sich darum kümmern müssen. Authorization Policies definieren, welcher Service welchen anderen aufrufen darf – auf Basis kryptografisch verifizierter Workload-Identitäten statt flüchtiger IP-Adressen in dynamischen Umgebungen. Zudem liefern Observability-Funktionen HTTP-Metriken, Traces und Access Logs, ohne dass in den Anwendungen ein SDK integriert werden muss.
Istio [1] hat sich seit seinem ersten Release im Jahr 2017 als De-facto-Standard in diesem Feld etabliert. Gründe dafür sind das breite Featureset, die enge Kubernetes-Integration und eine starke Community mit Beteiligung von Google, Red Hat, Solo.io, Intel und Microsoft. Doch Istio brachte von Beginn an eine architektonische Entscheidung mit, die sich über die Jahre zunehmend als Belastung herausstellte: das Sidecar-Pattern. Seit November 2024 gibt es mit Ambient Mode einen grundlegend anderen Ansatz, der dieses Muster nicht nur verbessert, sondern überwindet. Mit Istio 1.24 hat dieser den GA-Status erreicht und ist produktionsreif für Single-Cluster-Deployments.
Wer heute Microservices auf Kubernetes betreibt, stößt schnell auf Anforderungen, die sich mit Bordmitteln nicht oder nur umständlich umsetzen lassen. Durchgängige Verschlüsselung des internen Traffics, feingranulare Zugriffskontrolle zwischen Services, einheitliches Tracing über Servicegrenzen hinweg sowie intelligentes Trafficmanagement wie Canary Deployments gehören dazu. All das soll idealerweise geschehen, ohne eine einzige Zeile Code in der eigentlichen Anwendung zu ändern. Genau hier setzt ein Service Mesh an.
Ein Service Mesh schiebt sich als transparente Infrastrukturschicht zwischen die kommunizierenden Services. Mutual TLS (mTLS) sorgt für verschlüsselte Kommunikation zwischen allen Pods, ohne dass Entwickler sich darum kümmern müssen. Authorization Policies definieren, welcher Service welchen anderen aufrufen darf – auf Basis kryptografisch verifizierter Workload-Identitäten statt flüchtiger IP-Adressen in dynamischen Umgebungen. Zudem liefern Observability-Funktionen HTTP-Metriken, Traces und Access Logs, ohne dass in den Anwendungen ein SDK integriert werden muss.
Istio [1] hat sich seit seinem ersten Release im Jahr 2017 als De-facto-Standard in diesem Feld etabliert. Gründe dafür sind das breite Featureset, die enge Kubernetes-Integration und eine starke Community mit Beteiligung von Google, Red Hat, Solo.io, Intel und Microsoft. Doch Istio brachte von Beginn an eine architektonische Entscheidung mit, die sich über die Jahre zunehmend als Belastung herausstellte: das Sidecar-Pattern. Seit November 2024 gibt es mit Ambient Mode einen grundlegend anderen Ansatz, der dieses Muster nicht nur verbessert, sondern überwindet. Mit Istio 1.24 hat dieser den GA-Status erreicht und ist produktionsreif für Single-Cluster-Deployments.
Die operativen Kosten des Sidecar-Pattern
In der klassischen Istio-Architektur wird in jeden Pod, der am Mesh teilnimmt, automatisch ein zweiter Container injiziert: der Envoy-Proxy als Sidecar. Dieser Proxy fängt sämtlichen ein- und ausgehenden Traffic ab, kümmert sich um mTLS, setzt Policys durch und liefert Telemetriedaten. Das klingt elegant und ist es konzeptionell auch. Doch die praktischen Konsequenzen summieren sich zu einer erheblichen operativen Last.
Der offensichtlichste Kostenpunkt ist der Ressourcenverbrauch. Jeder Envoy-Sidecar benötigt typischerweise rund 0,20 vCPU und 60 MByte Arbeitsspeicher als Baseline-Reservation. In einer Umgebung mit 70 Pods bedeutet das rund 14 reservierte vCPU-Kerne und etwa 4,2 GByte Arbeitsspeicher, die ausschließlich für Proxys vorgehalten werden. Auf Managed-Kubernetes-Diensten wie AKS, GKE oder EKS zahlen Admins für diese Kapazität jeden Monat. Konkret: Auf AKS mit Standard_D4s_v3-Instanzen (4 vCPU, 16 GByte RAM, circa 140 Euro/Monat) bedeuten 14 reservierte vCPU für Sidecar-Proxys rechnerisch rund 490 Euro monatlichen Overhead für eine Infrastruktur, die keinen Anwendungscode ausführt.
Dazu kommt ein strukturelles Problem bei Updates. Wenn Istio eine neue Version des Envoy-Proxys ausliefert, müssen Admins alle Pods in der Infrastruktur neu starten. In großen Produktionsumgebungen ist das kein trivialer Vorgang, da Rolling Restarts über Hunderte von Deployments, die Koordination mit Entwicklungsteams und das Monitoring auf Fehler während des Rollouts anstehen. Das dritte Problem ist der Blast Radius: Stürzt der Envoy-Prozess ab, ist der gesamte Pod betroffen. Die Anwendung selbst mag fehlerfrei laufen, ist aber nicht mehr erreichbar.
Architektur des Zwei-Schichten-Modells
Der entscheidende Unterschied zum Side- car-Mode: Ambient Mode löst den Proxy vollständig aus dem Pod heraus und verteilt seine Aufgaben auf zwei gemeinsam genutzte Komponenten: Einen auf Node-Ebene laufenden L4-Proxy für alle Workloads und einen optionalen L7-Proxy für Services, die HTTP-Funktionalität benötigen.
Die erste und fundamentale Schicht ist der ztunnel. Er läuft als Kubernetes-DaemonSet mit genau einem ztunnel-Pod pro Node im Cluster. Der ztunnel ist in Rust implementiert: Memory-Safe- ty ohne Garbage-Collector bedeutet vorhersehbare Latenz bei minimalem Footprint. Dies sind zwei Eigenschaften, die für einen auf jedem Node laufenden Shared-Proxy nicht verhandelbar sind.
Der ztunnel ist bewusst auf Layer 4 beschränkt: Er sieht TCP-Verbindungen, keine HTTP-Requests. Er kann mTLS aufbauen, Workload-Identitäten über SPIFFE/X.509-Zertifikate verifizieren, einfache L4-Authorization-Policys durchsetzen und Verbindungstelemetrie liefern. Was er explizit nicht tut: HTTP-Header lesen, URL-Pfade parsen oder Cookies inspizieren. Dieser bewusste Scope ist sicherheitstechnisch kein Nachteil, sondern ein Designprinzip: Da der ztunnel niemals Anwendungsschichtdaten zu Gesicht bekommt, kann er gefahrlos als Shared-Component auf Node-Ebene laufen. Kein Workload muss befürchten, dass seine HTTP-Payloads durch denselben Proxyprozess laufen wie die eines anderen Teams auf demselben Node.
Die Kommunikation zwischen ztunnel-Instanzen läuft über HBONE (HTTP-Based Overlay Network Encapsulation). HBONE nutzt "HTTP CONNECT" als Tunneling-Mechanismus und multiplext darüber mehrere TCP-Streams über eine einzige mTLS-verschlüsselte HTTP/2-Verbindung. Statt für jede Verbindung einen neuen TLS-Hand-shake durchzuführen, teilen sich viele Verbindungen eine bereits etablierte HBONE-Session. Das reduziert Latenz und CPU-Last gegenüber nativen mTLS-Implementierungen.
Dass der ztunnel außerhalb der Pods läuft, stellt eine technische Herausforderung dar: Wie kommt der Traffic der Pods überhaupt zum ztunnel? Der istio-cni-Node-Agent löst das über einen Linux-Kernel-Mechanismus. Ein Prozess kann Sockets in einem fremden Network-Namespace erstellen und dort auf Verbindungen horchen. Der ztunnel öffnet so Listening-Sockets direkt im Network-Namespace der Anwendungspods, ohne iptables-Regeln, die den Traffic durch den Host-Namespace schleusen müssen. istio-cni ist im Ambient Mode eine Pflichtkomponente und kompatibel mit den CNI-Implementierungen von AWS, Azure und GKE sowie Calico und Cilium.
Die zweite Schicht ist der Waypoint-Proxy – optional, Envoy-basiert und deployt über das Kubernetes-Gateway-API mit der GatewayClass "istio-waypoint". Er kann für einen gesamten Namespace, für einen einzelnen Service oder für einen spezifischen Pod konfiguriert werden. Wenn der ztunnel Traffic zu einem Workload mit Waypoint routen soll, leitet er automatisch dorthin weiter.
Wann ein Waypoint-Proxy erforderlich ist
Die häufigste Fehlannahme bei der Einführung des Ambient Mode ist, dass Admins für alle Szenarien einen Waypoint-Proxy benötigen. Für einen überraschend großen Anteil typischer Service-Mesh-Anforderungen reicht der ztunnel vollständig aus. Dieser liefert:
- Automatisches mTLS für jeden Pod im Namespace
- Workload-Authentifizierung über SPIFFE-Identitäten
- Authorization Policies auf Basis von Source-Identity, Namespace und Zielport
- Verbindungstelemetrie
- Round-Robin-Loadbalancing
Einen Waypoint-Proxy benötigen IT-Verantwortliche erst, wenn ein HTTP-Routing auf Basis von URL-Pfaden, Methoden oder Headern erforderlich ist. Das gilt auch für Traffic-Splitting zwischen Serviceversionen bei Canary Deployments, für Retries, Timeouts, Circuit Breaking und Fault Injection sowie für Authorization Policies, die HTTP-Primitive auswerten, oder Distributed Tracing auf Request-Ebene.
Doch aufgepasst: Ein "VirtualService" in einem Namespace ohne Waypoint Proxy hat in Ambient Mode keinerlei Wirkung. ztunnel ignoriert diese Ressourcen vollständig – ohne Fehlermeldung oder Warnung. Dieser Silent-Fail ist einer der häufigsten Stolpersteine bei der Migration von Sidecar-Mode zu Ambient.
Für die meisten Szenarien gilt: Namespace zunächst ohne Waypoint aufschalten, mTLS und L4-Policys validieren, Way- point erst deployen, wenn konkrete L7-Anforderungen entstehen.
Zero Trust ohne Konfigurationsaufwand
Der Ambient Mode macht Zero Trust zur Grundeinstellung: Sobald Sie einen Namespace mit dem Label "istio.io/dataplane-mode=ambient" versehen, läuft jeder Traffic zwischen Pods über mTLS – ohne dass ein Operator irgendetwas konfigurieren muss. Die Grundlage dafür sind SPIFFE-Identitäten. SPIFFE (Secure Production Identity Framework For Everyone) ist ein offener Standard für Workload-Identitäten in dynamischen Umgebungen.
Statt IP-Adressen oder Servicenamen, die in Kubernetes-Clustern flüchtig und manipulierbar sind, erhält jeder Workload ein kryptografisch gebundenes Zertifikat, das seinen Service Account eindeutig belegt. Istio stellt dieses X.509-Zertifikat automatisch aus, und zwar in der Form ""spiffe://cluster.local/ns/<namespace>/sa/<serviceaccount>". Diese Zertifikate haben eine Gültigkeit (TTL) von 24 Stunden und werden automatisch rotiert.
Da Sie den Zugang zum Mesh ausschließlich über das Namespace-Label steuern, harmoniert Ambient Mode besonders gut mit Policy-Engines wie Kyverno oder OPA Gatekeeper. Um sicherzustellen, dass jeder Namespace im Cluster zwingend am Mesh teilnimmt, hinterlegen Sie eine Kyverno-Policy, die das Label "istio.io/dataplane-mode=ambient" als Pflichtfeld auf Name- space-Ebene durchsetzt. So wird die Netzwerksicherheit nicht mehr durch manuelle Konfiguration, sondern durch automatisierte Governance erzwungen – ein wichtiger Schritt in Richtung Zero Trust über die gesamte Infrastruktur hinweg.
Der wichtigste API-Unterschied betrifft die Authorization Policy. Im Sidecar-Mode werden Policys über einen "selector" an Pods gebunden. Im Ambient Mode wird stattdessen "targetRef" verwendet, das auf einen Service, einen Namespace oder einen Service Account zeigt (Listing 1).
Listing 1: targetRef im Ambient Mode
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: allow-frontend
namespace: demo
spec:
targetRef:
group: ""
kind: Service
name: api-service
action: ALLOW
rules:
- from:
- source:
principals:
- cluster.local/ns/demo/sa/frontend
Müssen Sie bestehende Sidecar-Mode-Policys nach Ambient migrieren, hilft das "gloo ambient migrate"-Tool [2] weiter. Es liest die vorhandene Cluster-Konfiguration, erkennt, welche Policys einen Waypoint benötigen und generiert automatisch neue "targetRef"-basierte Policys als YAML-Vorschlag – ohne dabei selbst Änderungen am Cluster vorzunehmen. Die empfohlenen Richtlinien landen in einer Datei und lassen sich nach einem Review manuell einspielen. L7-Authorization-Policys, die auf HTTP-Pfade oder -Methoden prüfen, können nur von einem Waypoint-Proxy durchgesetzt werden. Eine Policy mit "request.method == GET" in einem Namespace ohne Waypoint wird schlicht nicht angewendet.
Performance und Ressourcen im Vergleich
Ein Benchmark-Test von 25 Namespaces (jeweils im Sidecar-Mode und im Ambient Mode ohne Waypoint) ergab 73 Prozent weniger CPU-Verbrauch und eine Einsparung von 32 CPU-Kernen. Dies entspricht rund 1100 US-Dollar pro Monat auf typischen Cloudinstanzen. Beim Speicherbedarf benötigt ein Envoy-Sidecar circa 60 MByte pro Pod, während der ztunnel mit rund 12 MByte pro Node auskommt. Für 70 Pods bedeutet das den Unterschied zwischen 4,2 GByte und rund 1 GByte Proxyoverhead.
Im L4-only-Betrieb ist der Ambient Mode bei der Latenz kompetitiv zum Sidecar-Mode. Mit einem Waypoint kommt ein zusätzlicher Netzwerk-Hop hinzu, der sich in der Praxis im einstelligen Millisekundenbereich bewegt. Doch wenn Sie Waypoints in Multi-AZ-Clustern bereitstellen, sollten Sie auf das Placement achten: Liegt der Waypoint in Zone A, die Anwendungspods aber in Zone B, entstehen Cross-AZ-Datentransferkosten, die bei hohem Trafficaufkommen relevant werden können.
Ambient Mode mit kind aufsetzen
Kommen wir nun zur Praxis und bauen eine vollständige Ambient-Mesh-Infrastruktur auf. Unser Ziel: Eine Demoapplikation läuft in zwei Versionen im Mesh, ist per mTLS gesichert und der Traffic wird über einen Waypoint-Proxy gesteuert – mit einem gewichteten Split (90/10) und Header-basiertem Canary-Routing. Dieses Szenario ist mit reinem Kubernetes nicht umsetzbar, da dieses den Traffic zwischen Deployments immer nach Pod-Anzahl und nicht nach konfigurierten Gewichten verteilt. Alle YAML-Manifeste liegen im begleitenden GitHub-Repository [3] im Verzeichnis "ambient-istio".
Dazu benötigen wir Docker, kind, kubectl und istioctl. Wir starten mit kind, das wir über Homebrew oder direkt installieren:
brew install kind
curl -L https://istio.io/ downloadIstio | sh -
cd istio-1.24.2 && export PATH=$PWD/bin:$PATH
Unseren Drei-Node-Cluster bildet Cross-Node-Traffic-Flows realitätsnah ab:
cat <<EOF | kind create cluster --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: ambient
nodes:
role: control-plane
role: worker
role: worker
EOF
# Gateway API CRDs - in kind nicht vorinstalliert, für Waypoints Pflicht
kubectl apply --server-side -f
https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml
# Istio mit Ambient-Profil
istioctl install --set profile=ambient --skip-confirmation
Nach der Installation läuft auf jedem Node ein ztunnel-Pod und ein istio-cni-Pod:
kubectl get ds -n istio-system
NAME DESIRED CURRENT READY
ztunnel 3 3 3
istio-cni-node 3 3 3
Demoapplikation bereitstellen
Wir deployen zwei Versionen eines minimalen HTTP-API sowie einen Client-Pod für Tests. Das API antwortet schlicht mit "v1" oder "v2" – das macht das Canary-Routing später direkt ohne Loganalyse sichtbar. Entscheidend ist, was in den Manifesten nicht steht: keine Istio-Annotationen, keine Init-Container und keine Sidecar-Konfiguration. Ein Auszug aus "demo-app.yaml" zeigt die beiden Deployments [2]. Diese sind identisch bis auf das version-Label und den "-text"-Parameter (Listing 2).
Listing 2: Demoanwendung aufbauen
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-v1
namespace: demo
spec:
replicas: 2
selector:
matchLabels: {app: api-service, version: v1}
template:
metadata:
labels: {app: api-service, version: v1}
spec:
serviceAccountName: api-service
containers:
- name: api
image: hashicorp/http-echo
args: ["-text=v1", "-listen=:80"]
ports: [{containerPort: 80}]
api-v2: identisch, args: ["-text=v2", "-listen=:80"]
Ohne korrekte Service Accounts greift keine einzige Policy. Das vollständige Manifest inklusive Service Accounts, Client-Deployment und Service liegt im zuvor erwähnten Repository:
kubectl apply -f https://raw.githubusercontent.com/philiplorenz-code/heinemann/main/ ambient-istio/demo-app.yaml
Namespace in den Mesh aufnehmen und mTLS verifizieren
Ein einziges Label genügt, um alle Pods des Namespace in den Mesh aufzunehmen – ein Neustart der Pods ist nicht nötig. Der istio-cni-Agent erkennt das Label und konfiguriert die Trafficumleitung zum ztunnel automatisch:
kubectl label namespace demo istio.io/dataplane-mode=ambient
kubectl get pod -n demo -o
jsonpath="{range .items[*]}{.metadata.name}{"\t"}{.metadata.annotations.ambient.istio.io/redirection}{"\n"}{end}"
In der darauf folgenden Ausgabe zeigt sich der Status "HBONE" bei allen Demo-Pods. Das bedeutet, dass der Traffic ab sofort verschlüsselt über den ztunnel läuft. Es wurde kein Code geändert und kein Pod neu gestartet.
L4-Authorization-Policy auf Basis von Service Accounts
Der ztunnel kann ohne Waypoint bereits eine feingranulare Zugriffskontrolle durchsetzen – auf Basis kryptografisch verifizierter Service-Account-Identitäten (Listing 3). Der entscheidende Unterschied zum Sidecar-Mode: targetRef zeigt auf den Service, nicht auf Pod-Labels. Das entkoppelt die Policy von der Deployment-Struktur.
Listing 3: Auszug aus l4-policy.yaml
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: allow-client
namespace: demo
spec:
targetRef:
group: ""
kind: Service
name: api-service
action: ALLOW
rules:
from:
source:
principals: ["cluster.local/ns/demo/sa/client"]
Wenden Sie die Policy testweise an und prüfen per curl-Befehl, ob der Zugriff funktioniert:
kubectl apply -f https://raw.githubusercontent.com/philiplorenz-code/heinemann/main/ ambient-istio/l4-policy.yaml
CLIENT=$(kubectl get pod -n demo -l app=client -o jsonpath="{.items[0].metadata.name}")
kubectl exec -n demo $CLIENT -- curl -s http://api-service
Waypoint bereitstellen und Canary-Routing aktivieren
Für L7-Funktionalität benötigen Sie einen Waypoint-Proxy. Sie rollen diesen aus und nehmen gleichzeitig den Namespace auf:
istioctl waypoint apply --namespace demo --enroll-namespace
Ab diesem Moment greifen VirtualService und DestinationRule. Ohne Waypoint ignoriert der ztunnel diese Ressourcen stillschweigend – einer der häufigsten Stolpersteine bei der Migration aus dem Sidecar-Mode.
Ein Auszug der "canary-routing.yaml"-Datei (Listing 4) zeigt die zwei Routing-Regeln: Header-basiertes Routing auf v2 und gewichteter Split für normalen Traffic.
Listing 4: Routing-Regeln in canary-routing.yaml
spec:
hosts: [api-service]
http:
Requests mit Header "x-canary: true" immer auf v2
match:
headers:
x-canary: {exact: "true"}
route:
destination: {host: api-service, subset: v2}
Normaler Traffic: 90% v1, 10% v2 - unabhängig von Pod-Anzahl
route:
destination: {host: api-service, subset: v1}
weight: 90
destination: {host: api-service, subset: v2}
weight: 10
Wenden Sie das Skript aus Listing 4 testweise an (erneut über den "kubectl apply -f"-Befehl), zeigt sich der entscheidende Unterschied zu reinem Kubernetes: Die Gewichtung von 90/10 gilt unabhängig davon, wie viele Replicas von v1 und v2 laufen. Der Waypoint-Proxy erzwingt das Verhältnis auf Basis der VirtualService-Konfiguration.
Mit aktivem Waypoint lassen sich Policys auf HTTP-Ebene durchsetzen. Wichtig dabei ist, dass L7-Policys via targetRef auf das Waypoint-Gateway (Listing 5) zeigen, nicht auf den Service. Eine Policy, die auf "kind: Service" wirkt, landet beim ztunnel. Dieser kennt keine HTTP-Methoden und ignoriert sie schlicht.
Listing 5: targetRef in l7-policy.yaml
piVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: deny-non-get
namespace: demo
spec:
targetRef:
group: gateway.networking.k8s.io
kind: Gateway # Waypoint, nicht Service
name: waypoint
action: DENY
rules:
to:
operation:
methods: ["POST", "PUT", "DELETE", "PATCH"]
ports: ["80]
Fazit
Das Sidecar-Pattern war eine clevere Lösung für ein echtes Problem. Es hat Istio groß gemacht und Service Mesh in Produktions-Clustern etabliert. Aber es bedeutete immer einen Kompromiss: Proxyfunktionalität in jeden Pod zu laden, erzeugt universellen Overhead – unabhängig davon, ob ein Workload diese Kontrolle tatsächlich benötigt. Der Ambient Mode beendet diesen Kompromiss. Die Trennung von L4-Sicherheit und L7-Funktionalität folgt dem Prinzip "Pay for what you use": Wer nur mTLS und Zero-Trust-Networking benötigt, zahlt praktisch nichts. Wer Canary Deployments und Header-basierte Policys will, zahlt gezielt für die Infrastruktur, die das benötigt.
Die Handlungsempfehlung ist klar: Setzen Sie eine neue Umgebung mit Istio auf, starten Sie direkt mit der Option "--set profile=ambient". Wer bestehende Cluster betreibt, plant die Migration Namespace für Namespace – mit dem "gloo ambient migrate"-Werkzeug Unterstützung bei der Policykonvertierung. Das Sidecar stirbt nicht sofort, da das Istio-Projekt zugesagt hat, den Sidecar-Mode langfristig zu unterstützen. Aber die Richtung ist eindeutig und die Zahlen sprechen für sich: 73 Prozent weniger CPU, 70 Prozent weniger Speicher und kein Rolling Restart bei Proxy-Updates.
(jp)
Links
[1] Istio: https://it-a.eu/l7zb3
[2] gloo ambient migrate-Tool: https://it-a.eu/q8p41
[3] Repository zu diesem Artikel: https://it-a.eu/q8p42