Das passende Training Kubernetes Networking Training – 3 Tage Praxis & Debugging
Pod-Traffic zwischen Nodes ist Klartext: So verschlüsselst du ihn mit WireGuard in Calico

Das passende Training Kubernetes Networking Training – 3 Tage Praxis & Debugging

Im Kubernetes-Cluster reist dein Traffic auf Postkarten

Ganz ehrlich: Der Traffic zwischen Pods auf verschiedenen Nodes läuft in Kubernetes standardmäßig im Klartext. Wer im Rechenzentrum einen Mitschnitt am Netzwerk ziehen kann, liest mit, und auf deine VMs muss er dafür nie. Meine einfachste Antwort heißt WireGuard in Calico. Das schaltest du im laufenden Betrieb ein.

Die Frage aus der Firmenschulung

In einer Firmenschulung erzählt mir ein Teilnehmer von seinem Problem. Seine Firma betreibt Workloads in einem fremden Rechenzentrum. Ein Teil davon spricht unverschlüsselt miteinander, altes Zeug, das keiner anfassen darf.

Seine Frage: Wie sorge ich dafür, dass der Infrastruktur-Admin im Rechenzentrum nicht mitliest? Auf die VMs kommt der nicht. Ans Netzwerk schon.

Postkarte statt Brief

Genau da liegt der Knackpunkt. Kubernetes verschlüsselt den Traffic zwischen den Nodes nicht, und das Netzwerk-Plugin tut es mit den üblichen Einstellungen auch nicht. Dein Traffic reist auf einer Postkarte, wie das Kubernetes-Secret schon. Wer den Postsack anfasst, liest mit. In dein Haus muss er dafür nicht.

Auch der Ingress macht keinen Brief daraus. Von außen kommt der Traffic per TLS an. Beendest du die Verschlüsselung am Ingress, geht es im Cluster im Klartext weiter.

Eine NetworkPolicy hilft hier nicht. Sie regelt, wer mit wem reden darf. Verschlüsselt wird dadurch nichts.

Meine Antwort: WireGuard in Calico

Calico und WireGuard, so mache ich das. WireGuard ist eigentlich simpel. Der Aufwand steckt in der Konfiguration, und die nimmt dir Calico ab: Schlüssel und Verbindungen zwischen den Nodes verwaltet es selbst. Und weil es im laufenden Betrieb geht, musst du dafür kein Cluster neu bauen.

Und so sieht der Zauber aus, laut Calico-Dokumentation:

kubectl patch felixconfiguration default --type='merge' \
  -p '{"spec":{"wireguardEnabled":true}}'

Ein Befehl, fertig. Auf den Nodes ist wg danach nicht installiert, ein wg show gibt es also nicht. Ob der Tunnel steht, siehst du am Interface wireguard.cali. Schau außerdem in die Doku auf die MTU, denn der Tunnel braucht Platz im Paket.

Was es kostet: gemessen statt geschätzt

Mein Eindruck aus dem Training: Der Durchsatz halbiert sich. Ich wollte es genau wissen und habe es nachgemessen, auf der Infrastruktur von DigitalOcean, mit iperf3 von Pod zu Pod über die Node-Grenze:

Messungohne WireGuardmit WireGuardAnteil
Pod zu Pod, 1 Stream1,86 Gbit/s (1,79 bis 1,89)0,74 Gbit/s (0,32 bis 0,97)40 %
Pod zu Pod, 4 Streams1,86 Gbit/s (1,77 bis 1,89)0,84 Gbit/s (0,75 bis 0,94)45 %
Node zu Node (hostNetwork)1,89 Gbit/s1,89 Gbit/s100 %

Eigene Messung vom 3. Oktober 2026. Getestet mit Kubernetes 1.37.1 (kubeadm), Calico 3.31.2, Ubuntu 24.04 mit Kernel 6.8, zwei DigitalOcean-Droplets vom Typ s-2vcpu-4gb in Frankfurt, beide im selben Subnetz. Je Variante fünf Läufe à zehn Sekunden, Mittelwert, in Klammern kleinster und größter Wert.

Mit WireGuard fällt der Pod-Traffic auf rund 40 bis 45 Prozent. Mehr als halbiert, mein Gefühl hat also gestimmt. Der Node-zu-Node-Traffic im Host-Netzwerk bleibt gleich schnell. Calico verschlüsselt ihn nicht, und die Messung zeigt es.

Die Zahlen gelten für diese Droplets und diesen Kernel. Auf anderer Hardware kann der Abstand anders ausfallen. Miss bei dir nach, das ist eine Sache von zehn Minuten.

Wo WireGuard aufhört

Seien wir fair: WireGuard verschlüsselt den Pod-Traffic auf der Leitung zwischen den Nodes. Wer root auf einem Node hat, sieht ihn dort weiter im Klartext, bevor er in den Tunnel geht. Gegen den Mitleser im Netz hilft das, gegen den Admin auf dem Node nicht.

Der Schalter oben gilt für IPv4. Bei IPv6 gibt es eine eigene Einstellung. Und was direkt im Netzwerk des Nodes läuft, zum Beispiel Pods mit hostNetwork, fasst er nicht von allein an.

Für den Teilnehmer war es trotzdem die richtige Antwort. Sein Admin kommt ans Netzwerk, aber nicht auf die VMs.

Und Cilium? Oder Istio?

Cilium kann das auch. Es verschlüsselt den Pod-Traffic zwischen den Nodes ebenfalls mit WireGuard. Bei der Verschlüsselung können Calico und Cilium also dasselbe, und es entscheidet, was du schon im Cluster hast. Läuft Calico, schaltest du es dort ein. Läuft Cilium, schaltest du es dort ein. Beides ist ein Schalter.

Wegen der Verschlüsselung allein wechselst du dein Netzwerk-Plugin nicht. Das wäre, als würdest du das ganze Kraftwerk kaufen, nur um ein Loch in die Wand zu bohren. Mehr zur Wahl steht in Calico oder Cilium.

Willst du mehr, als dass keiner mitliest? Sollen sich die Dienste zum Beispiel gegenseitig ausweisen, bevor sie miteinander reden? Dann brauchst du ein Service Mesh wie Istio. Cilium hat dafür auch etwas eingebaut, das ist aber noch Beta. Für die Frage aus der Firmenschulung brauchst du das nicht. Der Teilnehmer wollte nur, dass keiner mitliest.

Meine klare Ansage

Geh nicht davon aus, dass dein Pod-Traffic verschlüsselt ist. Frag dich: Wer kommt an meine Leitung? Ist das jemand, dem du nicht traust, machst du mit WireGuard aus der Postkarte einen Brief.

Läuft alles im eigenen Rechenzentrum mit eigenen Leuten, kann Klartext in Ordnung sein. Aber dann triff die Entscheidung bewusst. Lass sie dir nicht einfach passieren.

Wie du Cluster-Netzwerke, CNI-Plugins und Network Policies aufbaust und absicherst, üben wir im Training “Kubernetes Networking” am Live-Cluster.