Ich hoffe, der Beitrag zu eBPF in Teil 1 hat Ihnen gefallen! Sehen wir uns nun Cilium als verbreitete eBPF-Lösung für K8s an und klären, in welchem Verhältnis es zu Dataplane V2 steht.
Cilium 🐝 ist eine angesagte Technologie auf Basis von eBPF. Wenn von eBPF die Rede ist, fällt der Name oft als Erstes – insbesondere im Kubernetes-Umfeld. Cilium ist im Kern eine Open-Source-Software, die als CNI-Plugin für Kubernetes fungiert. Sie liefert eBPF-basiertes Networking, Observability und Security mit optimaler Skalierbarkeit und Performance für Plattformteams, die Kubernetes-Umgebungen in der Cloud und on-premise betreiben.
Auf Basis des Extended Berkeley Packet Filter (eBPF) bringt Cilium eine Reihe spannender Funktionen nach K8s. Schauen wir genauer hin.
Network Policies 🕸
Bei der Kommunikation zwischen K8s-Pods empfiehlt es sich, das Least-Privilege-Prinzip umzusetzen. Die einfachen K8s Network Policies (auf L3/L4) leisten dabei gute Arbeit – mit Cilium Network Policies (auf L3–L7) lässt sich darauf aber noch deutlich mehr aufbauen.
Im Umfeld von K8s und Microservices ist das besonders nützlich, denn das Untersuchen und Steuern von Netzwerkverkehr allein anhand von Metadaten wie IPs und Ports bringt wenig Mehrwert. IPs und Ports ändern sich ständig, wenn Services kommen und gehen. Mit Cilium können Sie den Traffic zusätzlich auf Basis von Pod-, HTTP-, gRPC-, Kafka-, DNS- und weiteren Metadaten steuern.
So lassen sich beispielsweise HTTP-Regeln definieren, die einen bestimmten API-Aufruf aus einem bestimmten Pod nur über bestimmte Pfade, Header und Request-Methoden zulassen. Ein weiteres Beispiel sind DNS-Regeln auf Basis von FQDNs, sodass nur Anfragen an eine bestimmte Domain erlaubt werden. Auf diese Weise lassen sich Sicherheitsrichtlinien definieren, die in realen Szenarien tatsächlich nützlich und praktikabel sind.
Multi-Cluster-Konnektivität 🔗
Über ein Cluster Mesh ermöglicht Cilium, dass K8s-Pods clusterübergreifend miteinander kommunizieren und sich gegenseitig finden. Typische Anwendungsfälle sind Hochverfügbarkeit und Multi-Cloud (Verbindung von K8s-Clustern über mehrere Cloud-Anbieter hinweg).
Load Balancing ⚖️
Cilium ersetzt kube-proxy durch BPF. kube-proxy setzt auf iptables, das zugunsten von BPF abgelöst wird. Das steigert die Performance erheblich.
Weitere Features
- Transparente Verschlüsselung zwischen Pods – mit Unterstützung für IPsec/Wireguard
- Höhere Netzwerk-Performance
- Hohe Skalierbarkeit der Infrastruktur
- Tiefere Einblicke in Traffic Flows – nicht nur über IPs und Ports, sondern auch über L7-Protokolle. Werfen Sie einen Blick auf diesen Blogbeitrag zu einer interessanten DNS-Debugging-Session
- Monitoring und bessere Sichtbarkeit von Netzwerkfehlern zwischen Microservices. Cilium liefert Prometheus-kompatible Metriken
Ein paar Worte zu den Alternativen: Es gibt weitere leistungsfähige CNI-Plugins am Markt. Hier ein Vergleich (möglicherweise nicht ganz neutral). Auch Calico hat kürzlich eine eBPF-Dataplane vorgestellt.
Dataplane V2 ✈
Die Google Cloud Platform hält GKE (Google Kubernetes Engine) am Puls der Zeit, indem sie Cilium in einen eigenen Mechanismus namens Dataplane V2 einbettet. Aber ist Dataplane V2 wirklich ein von Google verwaltetes Cilium für GKE? Wir alle schätzen Managed Services, oder? Da lohnt sich ein genauerer Blick.
In Googles Dokumentation zu den Dataplane-V2-Konzepten findet sich (Stand dieses Beitrags) kein Hinweis und kein Verweis auf das Cilium-Projekt. Im offiziellen Blogbeitrag und in einigen Dokumenten gibt es allerdings vereinzelte kleine Erwähnungen.
Die Control Plane von Dataplane V2 wird als K8s-DaemonSet namens anetd ausgerollt. Ein kurzes kubectl describe daemonsets.apps -n kube-system anetd zeigt, dass dabei das Image gke.gcr.io/cilium/cilium:v1.9.4-gke.17 zum Einsatz kommt.
Ist das also tatsächlich Cilium? Führen wir kubectl exec -n kube-system -ti ds/anetd — cilium version aus. Die Ausgabe lautet:
Client: 1.9.4 609a63dfb 2021-04-12T15:01:54-07:00 go version go1.15.7 linux/amd64
Tatsächlich – es ist Cilium 1.9.4! Vergleicht man es jedoch mit dem offiziellen Cilium-Image v1.9.4, ergibt sich ein leicht abweichendes Bild:
Client: 1.9.4 07b62884c 2021-02-03T11:45:44-08:00 go version go1.15.7 linux/amd64
Vergleichen wir nun die Docker-Images gke.gcr.io/cilium/cilium:v1.9.4-gke.17 und quay.io/cilium/cilium:v1.9.4 mit einem Tool wie Dive. Es gibt offenbar Unterschiede in den Layern, aber für mich ist schwer zu beurteilen, ob es größere logische Abweichungen beim Funktionsumfang von Cilium gibt.
Erwähnenswert ist außerdem, dass laut diesem Blogbeitrag Google sich aktiv eingebracht und eine Reihe relevanter Features zum Cilium-Projekt beigesteuert hat. Das zeigt schon ein gewisses Maß an Commitment.
Also: Dataplane V2 = Managed Cilium?
Bisher kann ich nicht abschließend beurteilen, ob Dataplane V2 ein verwaltetes Cilium für GKE ist. Ohne diese offizielle Bestätigung lässt sich zumindest sagen: Als Produkt ist Dataplane V2 ≠ Cilium. Es sieht so aus, als käme Cilium unter der Haube zum Einsatz – nur verweist Googles Dokumentation eben nicht auf die Cilium-Dokumente. Es handelt sich um ein eigenständiges Angebot.
In meinen Tests scheinen einige Cilium-Features auch unter Dataplane V2 zu funktionieren. Es gibt allerdings keinen offiziellen Google-Support dafür. Klar ist: "Inoffizielle" Cilium-Features auf Dataplane V2 funktionieren heute vielleicht, könnten aber jederzeit unerwartet ausfallen. Wagen Sie sich also besser nicht in unbekannte Gewässer. Halten Sie sich an die offizielle Doku und gehen Sie auf Nummer sicher.
Vanilla Cilium oder Dataplane V2? 🤔
Hier ein Funktionsvergleich:
Aktuell teilen sich Cilium und Dataplane V2 folgende Funktionen:
- K8s Network Policies (nicht CiliumNetworkPolicy, auch wenn Dataplane V2 sie aktuell offenbar nicht zurückweist),
- Ablösung von
kube-proxydurch eBPF, - Network Policy Logging. Streng genommen kein Cilium-Feature, basiert aber auf Cilium. Damit lässt sich nachvollziehen, wie Ihre Network Policies greifen.
Meine Einschätzung 💭
Ich entscheide mich grundsätzlich gern für die einfachste mögliche Lösung. Ist sie auch noch managed – umso besser! Das spart auf allen Seiten kostbare Zeit. Dataplane V2 wirkt wie die einfachere und unkompliziertere Managed-Lösung, wenn Sie lediglich K8s Network Policies, einen eBPF-Ersatz für kube-proxy für mehr Performance und Skalierbarkeit sowie das komfortable Logging der Network-Policy-Ergebnisse brauchen.
Behalten Sie dabei aber die Einschränkungen im Blick. Wenn Sie weitergehende Cilium-Features wie Hubble, Cilium L7 Network Policies, Cluster Mesh oder einen Self-Hosted-/anderen Cloud-Provider-Betrieb benötigen, sind Sie mit Vanilla Cilium besser bedient.
Dataplane V2: Die Vorteile 👍
- Erstens: einfache Installation. Hängen Sie beim Anlegen eines neuen GKE-Clusters via
gcloud container clusters createeinfach das Flag—enable-dataplane-v2an. - Es basiert auf dem Open-Source-Projekt Cilium.
- Dataplane V2 bildet die Grundlage für das Network Policy Logging in GKE. Ein praktisches Feature, das Logs erzeugt, wenn eine Verbindung durch eine Network Policy zugelassen oder blockiert wird.
- Das
anetd-Plugin als Bestandteil von Dataplane V2 (basierend auf Cilium) wird von Google verwaltet und ist aktuell in GA (General Availability). Es ist also bereit für produktive workloads – inklusive laufender Updates und Support. - Es ist anzunehmen, dass Google weitere Integrationen mit GKE-nativen Funktionen – und vielleicht auch mit Cilium-eigenen Features – ergänzen wird. Das macht die Wahl umso attraktiver, wenn Sie langfristig planen.
Dataplane V2: Die Nachteile 👎
- Bis dato habe ich keinen Weg gefunden, Hubble mit Dataplane V2 zu nutzen. Hubble ist ein hervorragendes Observability-Tool von Cilium, das mithilfe von Cilium-eBPF wertvolle Einblicke liefert. Den Status können Sie hier verfolgen.
- Offiziell ist Dataplane V2 keine Managed-Cilium-Lösung. Sie können sich also nicht auf Cilium-Features verlassen, die heute zufällig mit Dataplane V2 funktionieren – mit der Zeit drohen unter Umständen Brüche.
- Aktivieren lässt es sich nur in einem neu erstellten GKE-Cluster. In bestehenden GKE-Clustern lässt es sich nicht nachrüsten.
- Es gibt einige weitere Einschränkungen, die Sie kennen sollten.
Loslegen 🏃🏽♀️
Für den Einstieg in Cilium auf K8s – hier klicken.
Für den Einstieg in Dataplane V2 auf GKE – hier klicken.
Profi-Tipp: Wenn Sie Manifeste für K8s-/Cilium-Network-Policies schreiben oder planen, nutzen Sie den Cilium Editor – für eine angenehme und sichere Arbeitsweise.
Die Zukunft von eBPF
So bahnbrechend diese Technologie ist – ich gehe fest davon aus, dass wir noch viele weitere Lösungen und spannende Entwicklungen rund um eBPF sehen werden.
Ein potenzielles Einflussfeld ist die Welt der Service Meshes. Die meisten heutigen Service-Mesh-Lösungen (z. B. Istio, Linkerd) setzen auf Sidecar-Proxies, die an Ihre Pods angehängt werden. Das beeinträchtigt die Performance, erhöht die Komplexität und schafft zusätzliche Fehlerquellen. eBPF hat das Potenzial, Service-Mesh-Funktionalität bereitzustellen, indem die Sidecar-Proxies durch eBPF-Logik ersetzt werden – und Service Meshes so für weitere Einsatzszenarien zugänglich zu machen.
Bleiben Sie dran!
Danke fürs Lesen! Bleiben Sie in Kontakt – folgen Sie uns auf dem DoiT Engineering Blog, dem DoiT LinkedIn-Kanal und dem DoiT Twitter-Kanal. Karrieremöglichkeiten finden Sie unter https://careers.doit-intl.com.