Das Umwälzungspotenzial von eBPF geht über Containernetzwerke hinaus.MOLPIX | shutterstock.com „Niemand ist eine Insel“, schrieb Dichter John Donne. Im Gegensatz dazu sind Container sehr wohl in sich selbst geschlossen und dabei mit allem ausgestattet, was sie brauchen, um unabhängig zu funktionieren – Code, Abhängigkeiten und Laufzeitmodulen. Diese Autonomie ist aus Security-Perspektive zu begrüßen, ist aber eher störend, wenn es darum geht, Container zu vernetzen. Allerdings sind insbesondere verteilte Workloads auf Verbindungen zwischen den Containern angewiesen, wie Bill Mulligan, Head of Community bei Isovalent, dem Unternehmen hinter dem Open-Source-Projekt Cilium, erklärt: „In der Distributed-Computing-Welt läuft alles über das Netzwerk – es ist die entscheidende Komponente, damit Anwendungen funktionieren und zusammenwirken können.“ Bislang wurden Container über virtuelle Netzwerke miteinander verbunden. Diese Netzwerke auf Grundlage Software-basierter Netzwerkadapter, Switches, Firewalls und Load Balancer weisen allerdings Mängel hinsichtlich ihrer Effizienz, Usability und Programmierbarkeit auf. Die Lösung für dieses Problem besteht jedoch ausnahmsweise nicht darin, zu abstrahieren. Stattdessen gilt es, eine Ebene tiefer in den Stack abzutauchen: Der Extended Berkeley Packet Filter – kurz eBPF – ist eine Grundlagentechnologie, die ursprünglich dem Linux-Universum entsprungen ist. Sie steht inzwischen auch für Windows und macOS zur Verfügung – und ermöglicht es, Networking auf Betriebssystemebene zu implementieren. Das soll Containernetzwerke realisieren, die: effizienter funktionieren, transparenter sind und sich besser kontrollieren lassen. Dabei bietet sich die Technologie nicht nur als Lösung für Containernetzwerke, sondern für moderne Softwarenetzwerke im Allgemeinen an. In diesem Artikel werfen wir mit verschiedenen Experten einen Blick darauf, wie eBPF (nicht nur) Containernetzwerke verändert. Containernetzwerke und die eBPF-Revolution Bislang wurden Containernetzwerke vor allem über Legacy-Workarounds etabliert, die betriebliche Hürden aufwerfen können. IDC Research Manager Taranvir Singh ordnet ein: „Traditionelle Containernetzwerk-Stacks stützen sich hauptsächlich auf iptables und Sidecar-Proxys, um Netzwerk-Traffic zu managen. Sollen diese Ansätze skaliert werden, können sie wegen ihrer Komplexität und ihres enormen Prozess-Overheads ineffizient werden.“ Dazu kommen traditionelle Methoden, die ebenfalls dazu beitragen, dass unnötige Mehrarbeit anfällt, wie Liz Rice, Chief Open Source Officer bei Isovalent, erklärt. Da Container von Natur aus voneinander und vom Server isoliert sind, mache eine virtuelle Ethernet-Verbindung und einen Netzwerk-Stack auf beiden Seiten der Verbindung erforderlich: „Diese Redundanz führt zu unnötigem Overhead und höheren Latenzzeiten.“ Nicht zuletzt hingen Containernetzwerke bislang auch ganz wesentlich von der Deployment-Umgebung ab, berichtet ihr Isovalent-Kollege Mulligan: „Vor eBPF waren Leistungs- und Flexibilitätssteigerungen nur mit einem Kernel-Bypass oder Hardwarebeschleunigung zu erreichen. Das hat zwar Vorteile gebracht, dafür aber den Traum vom White-Box-Networking gekillt, weil die Performance stark davon abhängig war, wo die Dinge gelaufen sind.“ Heutzutage werden die meisten Implementierungen auf Plugins migriert, die auf dem Container-Network-Interface (CNI)-Standard basieren. „Dieser ermöglicht im Wesentlichen, Binärdateien auf Host-Ebene bereitzustellen, die das Netzwerk gemäß spezifischen Anforderungen und Präferenzen konfigurieren und dazu verschiedene Technologien nutzen“, erklärt Shane Utt, Senior Principal Software Enginneer bei Red Hat. Zu den populären CNI-Plugins zählen zum Beispiel: Flannel, Calico, Weave und inzwischen auch Cilium, das auf eBPF basiert. „eBPF ist revolutionär, weil es auf Kernel-Ebene arbeitet“, meint Rice und fügt erklärend hinzu: „Obwohl Container auf demselben Host ihre eigene isolierte Ansicht des Benutzerbereichs aufweisen, teilen sie sich gemeinsam mit dem Host den gleichen Kernel. Werden auf dieser Ebene neue Netzwerk-, Observability- oder Security-Funktionen hinzugefügt, stehen sie sofort und mit geringem Overhead allen containerisierten Anwendungen zur Verfügung.“ Damit Tools auf eBPF-Basis eingesetzt werden können, müssten Container weder neu konfiguriert noch neu gestartet werden, versichert die Managerin. Auch IDC-Mann Singh sieht eBPF besser positioniert als andere Cloud-Native-Technologien: „Dass Netzwerkrichtlinien und -prozesse wie Packet Routing, Filtering und Load Balancing auf Kernel-Ebene ablaufen, erschließt diverse potenzielle Benefits und ermöglicht es, Pakete effizienter zu verarbeiten – eine entscheidende Netzwerkanforderung moderner Applikations-Workloads“, konstatiert der Analyst. Zudem, so ergänzt er, bringe diese Nähe zur Infrastruktur auch den Vorteil, umfassende Observability ohne zusätzliche Monitoring-Proxys zu realisieren (dazu später mehr). Neue Strategien zielen ferner darauf ab, eBPF-Prozesse auf die Hardware auszulagern, um das Networking weiter zu optimieren und parallel die Sicherheit zu erhöhen. Laut Rice kann dazu eine Netzwerkkarte in Kombination mit dem High-Performance-Framework eXpress Data Path (XDP) zum Einsatz kommen: „Indem die Paketverarbeitung auf die Hardware verlagert wird, lassen sich ‚Ping of Death‘-Sicherheitslücken effizient minimieren. Diese werden von kriminellen Hackern genutzt, um fehlerhafte oder bösartige Pakete einzuschleusen.“ Riskanten Code eliminieren zu können, bevor er den Netzwerk-Stack des Kernels erreiche, optimiere die Isolierung und damit die Sicherheit enorm, hält die Isovalent-Managerin fest. eBPF kann nicht nur Networking Folglich wird eBPF nicht nur zu Networking-, sondern auch zu Security- und Observability-Zwecken eingesetzt – unter anderem. „eBPF geht inzwischen weit über seine Wurzeln im Netzwerkbereich hinaus und erstreckt sich auch auf Observability, Tracing, Profiling, Security und vieles mehr“, konstatiert Mulligan und verweist auf eine wachsende Zahl von eBPF-Fallstudien. Die Technologie, so der Isovalent-Manager, bringe wieder Innovation in Bereiche, in denen es seit Jahren oder Jahrzehnten keine größeren Änderungen oder Aktualisierungen mehr gegeben habe. Auch Lin Sun, Director of Open Source beim Connectivity-Spezialisten Solo.io, rechnet mit einer dynamischen eBPF-Entwicklung, die über Containernetzwerke hinausgeht: „eBPF könnte künftig in den Bereichen Observability, Sicherheit und Compliance eine noch wichtigere Rolle spielen, als im Networking“. Der Manager verweist auf diverse eBPF-Projekte mit Wachstumspotenzial in den genannten Bereichen – etwa: Kepler, Pixie Tetragon und KubeArmor. „Mit weiteren Integrationen von IaaS-Netzwerkdiensten lassen sich die Vorteile von eBPF auf den gesamten Netzwerk-Stack ausweiten“, führt IDC-Analyst Singh aus. Er ergänzt, eBPF könne heterogene Netzwerke – etwa Legacy-Datenbanken, die auf VMs laufen, die über verschiedene Clouds verteilt sind – standardmäßig um einen Networking-Layer ergänzen. Weitere kommerzielle und quelloffene Projekte, die auf eBPF setzen, sind etwa: Das bereits erwähnte Cilium, das auch in andere Projekte wie OpenTelemetry integriert ist. Mit dem Plugin lässt sich eBPF dazu nutzen, universelle Netzwerkrichtlinien dynamisch auf Kubernetes-Cluster anzuwenden. Confluent und eBay setzen beispielsweise auf diese Cloud-Native-Technologie. Ein weiteres, wichtiges eBPF-Projekt ist auch LoxiLB. Hier kommt eBPF zum Einsatz, um die Geschwindigkeit und Programmierbarkeit des Load Blancing bei Kubernetes zu optimieren. Bei Project Calico handelt es sich hingegen um eine Container-Netzwerk- und Sicherheitslösung, die eine „pluggable“ eBPF-Datenebene bietet. eBPF-Bedenken und die Zukunft Sie haben es vermutlich schon geahnt – auch mit Blick auf eBPF gibt es Herausforderungen. Zum Beispiel gehen die erheblichen Performance-Verbesserungen beim Networking mit einer erhöhten Komplexität einher, wie Red-Hat-Entwickler Utt berichtet: „Die operativen Herausforderungen, wenn es darum geht, containerisierte Workloads zu managen, sind beträchtlich und könnten letztlich sogar dazu beitragen, Containernetzwerke weniger transparent zu gestalten.“ Auch die Befürworter von Service-Meshes sind nicht in allen Anwendungsfällen vollständig von eBPF überzeugt. So auch Solo.io-Gründer Sun: „Es hat sich gezeigt, dass sich der Durchsatz um fünf bis zehn Prozent steigern lässt, wenn iptable-Regeln durch eBPF ersetzt werden. Für eine so umfassende Überarbeitung ist das eine eher geringfügige Verbesserung“, meint der Manager. Sun verweist zudem darauf, dass das Experten-Knowhow in Sachen eBPF noch sehr rar gesät sei und empfiehlt deshalb vorerst auf Nummer Sicher zu gehen: „Die Komplexität von eBPF ist nicht zu unterschätzen, beispielsweise wenn es um die Kernel-Anforderungen, Privilegien für eBPF-Programme oder Debugging geht. Es ist deshalb sinnvoll, für Service-Mesh-Projekte weiterhin iptables-Regeln zu verwenden“. Trotz der genannten Bedenken: eBPF ist auf dem besten Weg, sich als vorherrschendes Modell für Cloud-Netzwerke zu etablieren – und die vielen, einzelnen Container-„Inseln“ zu einem Kontinent zu verbinden, wie John Donne es (vielleicht) formulieren würde. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
Wie eBPF das Container-Game verändert
Das Umwälzungspotenzial von eBPF geht über Containernetzwerke hinaus.MOLPIX | shutterstock.com „Niemand ist eine Insel“, schrieb Dichter John Donne. Im Gegensatz dazu sind Container sehr wohl in sich selbst geschlossen und dabei mit allem ausgestattet, was sie brauchen, um unabhängig zu funktionieren – Code, Abhängigkeiten und Laufzeitmodulen. Diese Autonomie ist aus Security-Perspektive zu begrüßen, ist aber eher störend, wenn es darum geht, Container zu vernetzen. Allerdings sind insbesondere verteilte Workloads auf Verbindungen zwischen den Containern angewiesen, wie Bill Mulligan, Head of Community bei Isovalent, dem Unternehmen hinter dem Open-Source-Projekt Cilium, erklärt: „In der Distributed-Computing-Welt läuft alles über das Netzwerk – es ist die entscheidende Komponente, damit Anwendungen funktionieren und zusammenwirken können.“ Bislang wurden Container über virtuelle Netzwerke miteinander verbunden. Diese Netzwerke auf Grundlage Software-basierter Netzwerkadapter, Switches, Firewalls und Load Balancer weisen allerdings Mängel hinsichtlich ihrer Effizienz, Usability und Programmierbarkeit auf. Die Lösung für dieses Problem besteht jedoch ausnahmsweise nicht darin, zu abstrahieren. Stattdessen gilt es, eine Ebene tiefer in den Stack abzutauchen: Der Extended Berkeley Packet Filter – kurz eBPF – ist eine Grundlagentechnologie, die ursprünglich dem Linux-Universum entsprungen ist. Sie steht inzwischen auch für Windows und macOS zur Verfügung – und ermöglicht es, Networking auf Betriebssystemebene zu implementieren. Das soll Containernetzwerke realisieren, die: effizienter funktionieren, transparenter sind und sich besser kontrollieren lassen. Dabei bietet sich die Technologie nicht nur als Lösung für Containernetzwerke, sondern für moderne Softwarenetzwerke im Allgemeinen an. In diesem Artikel werfen wir mit verschiedenen Experten einen Blick darauf, wie eBPF (nicht nur) Containernetzwerke verändert. Containernetzwerke und die eBPF-Revolution Bislang wurden Containernetzwerke vor allem über Legacy-Workarounds etabliert, die betriebliche Hürden aufwerfen können. IDC Research Manager Taranvir Singh ordnet ein: „Traditionelle Containernetzwerk-Stacks stützen sich hauptsächlich auf iptables und Sidecar-Proxys, um Netzwerk-Traffic zu managen. Sollen diese Ansätze skaliert werden, können sie wegen ihrer Komplexität und ihres enormen Prozess-Overheads ineffizient werden.“ Dazu kommen traditionelle Methoden, die ebenfalls dazu beitragen, dass unnötige Mehrarbeit anfällt, wie Liz Rice, Chief Open Source Officer bei Isovalent, erklärt. Da Container von Natur aus voneinander und vom Server isoliert sind, mache eine virtuelle Ethernet-Verbindung und einen Netzwerk-Stack auf beiden Seiten der Verbindung erforderlich: „Diese Redundanz führt zu unnötigem Overhead und höheren Latenzzeiten.“ Nicht zuletzt hingen Containernetzwerke bislang auch ganz wesentlich von der Deployment-Umgebung ab, berichtet ihr Isovalent-Kollege Mulligan: „Vor eBPF waren Leistungs- und Flexibilitätssteigerungen nur mit einem Kernel-Bypass oder Hardwarebeschleunigung zu erreichen. Das hat zwar Vorteile gebracht, dafür aber den Traum vom White-Box-Networking gekillt, weil die Performance stark davon abhängig war, wo die Dinge gelaufen sind.“ Heutzutage werden die meisten Implementierungen auf Plugins migriert, die auf dem Container-Network-Interface (CNI)-Standard basieren. „Dieser ermöglicht im Wesentlichen, Binärdateien auf Host-Ebene bereitzustellen, die das Netzwerk gemäß spezifischen Anforderungen und Präferenzen konfigurieren und dazu verschiedene Technologien nutzen“, erklärt Shane Utt, Senior Principal Software Enginneer bei Red Hat. Zu den populären CNI-Plugins zählen zum Beispiel: Flannel, Calico, Weave und inzwischen auch Cilium, das auf eBPF basiert. „eBPF ist revolutionär, weil es auf Kernel-Ebene arbeitet“, meint Rice und fügt erklärend hinzu: „Obwohl Container auf demselben Host ihre eigene isolierte Ansicht des Benutzerbereichs aufweisen, teilen sie sich gemeinsam mit dem Host den gleichen Kernel. Werden auf dieser Ebene neue Netzwerk-, Observability- oder Security-Funktionen hinzugefügt, stehen sie sofort und mit geringem Overhead allen containerisierten Anwendungen zur Verfügung.“ Damit Tools auf eBPF-Basis eingesetzt werden können, müssten Container weder neu konfiguriert noch neu gestartet werden, versichert die Managerin. Auch IDC-Mann Singh sieht eBPF besser positioniert als andere Cloud-Native-Technologien: „Dass Netzwerkrichtlinien und -prozesse wie Packet Routing, Filtering und Load Balancing auf Kernel-Ebene ablaufen, erschließt diverse potenzielle Benefits und ermöglicht es, Pakete effizienter zu verarbeiten – eine entscheidende Netzwerkanforderung moderner Applikations-Workloads“, konstatiert der Analyst. Zudem, so ergänzt er, bringe diese Nähe zur Infrastruktur auch den Vorteil, umfassende Observability ohne zusätzliche Monitoring-Proxys zu realisieren (dazu später mehr). Neue Strategien zielen ferner darauf ab, eBPF-Prozesse auf die Hardware auszulagern, um das Networking weiter zu optimieren und parallel die Sicherheit zu erhöhen. Laut Rice kann dazu eine Netzwerkkarte in Kombination mit dem High-Performance-Framework eXpress Data Path (XDP) zum Einsatz kommen: „Indem die Paketverarbeitung auf die Hardware verlagert wird, lassen sich ‚Ping of Death‘-Sicherheitslücken effizient minimieren. Diese werden von kriminellen Hackern genutzt, um fehlerhafte oder bösartige Pakete einzuschleusen.“ Riskanten Code eliminieren zu können, bevor er den Netzwerk-Stack des Kernels erreiche, optimiere die Isolierung und damit die Sicherheit enorm, hält die Isovalent-Managerin fest. eBPF kann nicht nur Networking Folglich wird eBPF nicht nur zu Networking-, sondern auch zu Security- und Observability-Zwecken eingesetzt – unter anderem. „eBPF geht inzwischen weit über seine Wurzeln im Netzwerkbereich hinaus und erstreckt sich auch auf Observability, Tracing, Profiling, Security und vieles mehr“, konstatiert Mulligan und verweist auf eine wachsende Zahl von eBPF-Fallstudien. Die Technologie, so der Isovalent-Manager, bringe wieder Innovation in Bereiche, in denen es seit Jahren oder Jahrzehnten keine größeren Änderungen oder Aktualisierungen mehr gegeben habe. Auch Lin Sun, Director of Open Source beim Connectivity-Spezialisten Solo.io, rechnet mit einer dynamischen eBPF-Entwicklung, die über Containernetzwerke hinausgeht: „eBPF könnte künftig in den Bereichen Observability, Sicherheit und Compliance eine noch wichtigere Rolle spielen, als im Networking“. Der Manager verweist auf diverse eBPF-Projekte mit Wachstumspotenzial in den genannten Bereichen – etwa: Kepler, Pixie Tetragon und KubeArmor. „Mit weiteren Integrationen von IaaS-Netzwerkdiensten lassen sich die Vorteile von eBPF auf den gesamten Netzwerk-Stack ausweiten“, führt IDC-Analyst Singh aus. Er ergänzt, eBPF könne heterogene Netzwerke – etwa Legacy-Datenbanken, die auf VMs laufen, die über verschiedene Clouds verteilt sind – standardmäßig um einen Networking-Layer ergänzen. Weitere kommerzielle und quelloffene Projekte, die auf eBPF setzen, sind etwa: Das bereits erwähnte Cilium, das auch in andere Projekte wie OpenTelemetry integriert ist. Mit dem Plugin lässt sich eBPF dazu nutzen, universelle Netzwerkrichtlinien dynamisch auf Kubernetes-Cluster anzuwenden. Confluent und eBay setzen beispielsweise auf diese Cloud-Native-Technologie. Ein weiteres, wichtiges eBPF-Projekt ist auch LoxiLB. Hier kommt eBPF zum Einsatz, um die Geschwindigkeit und Programmierbarkeit des Load Blancing bei Kubernetes zu optimieren. Bei Project Calico handelt es sich hingegen um eine Container-Netzwerk- und Sicherheitslösung, die eine „pluggable“ eBPF-Datenebene bietet. eBPF-Bedenken und die Zukunft Sie haben es vermutlich schon geahnt – auch mit Blick auf eBPF gibt es Herausforderungen. Zum Beispiel gehen die erheblichen Performance-Verbesserungen beim Networking mit einer erhöhten Komplexität einher, wie Red-Hat-Entwickler Utt berichtet: „Die operativen Herausforderungen, wenn es darum geht, containerisierte Workloads zu managen, sind beträchtlich und könnten letztlich sogar dazu beitragen, Containernetzwerke weniger transparent zu gestalten.“ Auch die Befürworter von Service-Meshes sind nicht in allen Anwendungsfällen vollständig von eBPF überzeugt. So auch Solo.io-Gründer Sun: „Es hat sich gezeigt, dass sich der Durchsatz um fünf bis zehn Prozent steigern lässt, wenn iptable-Regeln durch eBPF ersetzt werden. Für eine so umfassende Überarbeitung ist das eine eher geringfügige Verbesserung“, meint der Manager. Sun verweist zudem darauf, dass das Experten-Knowhow in Sachen eBPF noch sehr rar gesät sei und empfiehlt deshalb vorerst auf Nummer Sicher zu gehen: „Die Komplexität von eBPF ist nicht zu unterschätzen, beispielsweise wenn es um die Kernel-Anforderungen, Privilegien für eBPF-Programme oder Debugging geht. Es ist deshalb sinnvoll, für Service-Mesh-Projekte weiterhin iptables-Regeln zu verwenden“. Trotz der genannten Bedenken: eBPF ist auf dem besten Weg, sich als vorherrschendes Modell für Cloud-Netzwerke zu etablieren – und die vielen, einzelnen Container-„Inseln“ zu einem Kontinent zu verbinden, wie John Donne es (vielleicht) formulieren würde. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
Wie eBPF das Container-Game verändert Das Umwälzungspotenzial von eBPF geht über Containernetzwerke hinaus.MOLPIX | shutterstock.com „Niemand ist eine Insel“, schrieb Dichter John Donne. Im Gegensatz dazu sind Container sehr wohl in sich selbst geschlossen und dabei mit allem ausgestattet, was sie brauchen, um unabhängig zu funktionieren – Code, Abhängigkeiten und Laufzeitmodulen. Diese Autonomie ist aus Security-Perspektive zu begrüßen, ist aber eher störend, wenn es darum geht, Container zu vernetzen. Allerdings sind insbesondere verteilte Workloads auf Verbindungen zwischen den Containern angewiesen, wie Bill Mulligan, Head of Community bei Isovalent, dem Unternehmen hinter dem Open-Source-Projekt Cilium, erklärt: „In der Distributed-Computing-Welt läuft alles über das Netzwerk – es ist die entscheidende Komponente, damit Anwendungen funktionieren und zusammenwirken können.“ Bislang wurden Container über virtuelle Netzwerke miteinander verbunden. Diese Netzwerke auf Grundlage Software-basierter Netzwerkadapter, Switches, Firewalls und Load Balancer weisen allerdings Mängel hinsichtlich ihrer Effizienz, Usability und Programmierbarkeit auf. Die Lösung für dieses Problem besteht jedoch ausnahmsweise nicht darin, zu abstrahieren. Stattdessen gilt es, eine Ebene tiefer in den Stack abzutauchen: Der Extended Berkeley Packet Filter – kurz eBPF – ist eine Grundlagentechnologie, die ursprünglich dem Linux-Universum entsprungen ist. Sie steht inzwischen auch für Windows und macOS zur Verfügung – und ermöglicht es, Networking auf Betriebssystemebene zu implementieren. Das soll Containernetzwerke realisieren, die: effizienter funktionieren, transparenter sind und sich besser kontrollieren lassen. Dabei bietet sich die Technologie nicht nur als Lösung für Containernetzwerke, sondern für moderne Softwarenetzwerke im Allgemeinen an. In diesem Artikel werfen wir mit verschiedenen Experten einen Blick darauf, wie eBPF (nicht nur) Containernetzwerke verändert. Containernetzwerke und die eBPF-Revolution Bislang wurden Containernetzwerke vor allem über Legacy-Workarounds etabliert, die betriebliche Hürden aufwerfen können. IDC Research Manager Taranvir Singh ordnet ein: „Traditionelle Containernetzwerk-Stacks stützen sich hauptsächlich auf iptables und Sidecar-Proxys, um Netzwerk-Traffic zu managen. Sollen diese Ansätze skaliert werden, können sie wegen ihrer Komplexität und ihres enormen Prozess-Overheads ineffizient werden.“ Dazu kommen traditionelle Methoden, die ebenfalls dazu beitragen, dass unnötige Mehrarbeit anfällt, wie Liz Rice, Chief Open Source Officer bei Isovalent, erklärt. Da Container von Natur aus voneinander und vom Server isoliert sind, mache eine virtuelle Ethernet-Verbindung und einen Netzwerk-Stack auf beiden Seiten der Verbindung erforderlich: „Diese Redundanz führt zu unnötigem Overhead und höheren Latenzzeiten.“ Nicht zuletzt hingen Containernetzwerke bislang auch ganz wesentlich von der Deployment-Umgebung ab, berichtet ihr Isovalent-Kollege Mulligan: „Vor eBPF waren Leistungs- und Flexibilitätssteigerungen nur mit einem Kernel-Bypass oder Hardwarebeschleunigung zu erreichen. Das hat zwar Vorteile gebracht, dafür aber den Traum vom White-Box-Networking gekillt, weil die Performance stark davon abhängig war, wo die Dinge gelaufen sind.“ Heutzutage werden die meisten Implementierungen auf Plugins migriert, die auf dem Container-Network-Interface (CNI)-Standard basieren. „Dieser ermöglicht im Wesentlichen, Binärdateien auf Host-Ebene bereitzustellen, die das Netzwerk gemäß spezifischen Anforderungen und Präferenzen konfigurieren und dazu verschiedene Technologien nutzen“, erklärt Shane Utt, Senior Principal Software Enginneer bei Red Hat. Zu den populären CNI-Plugins zählen zum Beispiel: Flannel, Calico, Weave und inzwischen auch Cilium, das auf eBPF basiert. „eBPF ist revolutionär, weil es auf Kernel-Ebene arbeitet“, meint Rice und fügt erklärend hinzu: „Obwohl Container auf demselben Host ihre eigene isolierte Ansicht des Benutzerbereichs aufweisen, teilen sie sich gemeinsam mit dem Host den gleichen Kernel. Werden auf dieser Ebene neue Netzwerk-, Observability- oder Security-Funktionen hinzugefügt, stehen sie sofort und mit geringem Overhead allen containerisierten Anwendungen zur Verfügung.“ Damit Tools auf eBPF-Basis eingesetzt werden können, müssten Container weder neu konfiguriert noch neu gestartet werden, versichert die Managerin. Auch IDC-Mann Singh sieht eBPF besser positioniert als andere Cloud-Native-Technologien: „Dass Netzwerkrichtlinien und -prozesse wie Packet Routing, Filtering und Load Balancing auf Kernel-Ebene ablaufen, erschließt diverse potenzielle Benefits und ermöglicht es, Pakete effizienter zu verarbeiten – eine entscheidende Netzwerkanforderung moderner Applikations-Workloads“, konstatiert der Analyst. Zudem, so ergänzt er, bringe diese Nähe zur Infrastruktur auch den Vorteil, umfassende Observability ohne zusätzliche Monitoring-Proxys zu realisieren (dazu später mehr). Neue Strategien zielen ferner darauf ab, eBPF-Prozesse auf die Hardware auszulagern, um das Networking weiter zu optimieren und parallel die Sicherheit zu erhöhen. Laut Rice kann dazu eine Netzwerkkarte in Kombination mit dem High-Performance-Framework eXpress Data Path (XDP) zum Einsatz kommen: „Indem die Paketverarbeitung auf die Hardware verlagert wird, lassen sich ‚Ping of Death‘-Sicherheitslücken effizient minimieren. Diese werden von kriminellen Hackern genutzt, um fehlerhafte oder bösartige Pakete einzuschleusen.“ Riskanten Code eliminieren zu können, bevor er den Netzwerk-Stack des Kernels erreiche, optimiere die Isolierung und damit die Sicherheit enorm, hält die Isovalent-Managerin fest. eBPF kann nicht nur Networking Folglich wird eBPF nicht nur zu Networking-, sondern auch zu Security- und Observability-Zwecken eingesetzt – unter anderem. „eBPF geht inzwischen weit über seine Wurzeln im Netzwerkbereich hinaus und erstreckt sich auch auf Observability, Tracing, Profiling, Security und vieles mehr“, konstatiert Mulligan und verweist auf eine wachsende Zahl von eBPF-Fallstudien. Die Technologie, so der Isovalent-Manager, bringe wieder Innovation in Bereiche, in denen es seit Jahren oder Jahrzehnten keine größeren Änderungen oder Aktualisierungen mehr gegeben habe. Auch Lin Sun, Director of Open Source beim Connectivity-Spezialisten Solo.io, rechnet mit einer dynamischen eBPF-Entwicklung, die über Containernetzwerke hinausgeht: „eBPF könnte künftig in den Bereichen Observability, Sicherheit und Compliance eine noch wichtigere Rolle spielen, als im Networking“. Der Manager verweist auf diverse eBPF-Projekte mit Wachstumspotenzial in den genannten Bereichen – etwa: Kepler, Pixie Tetragon und KubeArmor. „Mit weiteren Integrationen von IaaS-Netzwerkdiensten lassen sich die Vorteile von eBPF auf den gesamten Netzwerk-Stack ausweiten“, führt IDC-Analyst Singh aus. Er ergänzt, eBPF könne heterogene Netzwerke – etwa Legacy-Datenbanken, die auf VMs laufen, die über verschiedene Clouds verteilt sind – standardmäßig um einen Networking-Layer ergänzen. Weitere kommerzielle und quelloffene Projekte, die auf eBPF setzen, sind etwa: Das bereits erwähnte Cilium, das auch in andere Projekte wie OpenTelemetry integriert ist. Mit dem Plugin lässt sich eBPF dazu nutzen, universelle Netzwerkrichtlinien dynamisch auf Kubernetes-Cluster anzuwenden. Confluent und eBay setzen beispielsweise auf diese Cloud-Native-Technologie. Ein weiteres, wichtiges eBPF-Projekt ist auch LoxiLB. Hier kommt eBPF zum Einsatz, um die Geschwindigkeit und Programmierbarkeit des Load Blancing bei Kubernetes zu optimieren. Bei Project Calico handelt es sich hingegen um eine Container-Netzwerk- und Sicherheitslösung, die eine „pluggable“ eBPF-Datenebene bietet. eBPF-Bedenken und die Zukunft Sie haben es vermutlich schon geahnt – auch mit Blick auf eBPF gibt es Herausforderungen. Zum Beispiel gehen die erheblichen Performance-Verbesserungen beim Networking mit einer erhöhten Komplexität einher, wie Red-Hat-Entwickler Utt berichtet: „Die operativen Herausforderungen, wenn es darum geht, containerisierte Workloads zu managen, sind beträchtlich und könnten letztlich sogar dazu beitragen, Containernetzwerke weniger transparent zu gestalten.“ Auch die Befürworter von Service-Meshes sind nicht in allen Anwendungsfällen vollständig von eBPF überzeugt. So auch Solo.io-Gründer Sun: „Es hat sich gezeigt, dass sich der Durchsatz um fünf bis zehn Prozent steigern lässt, wenn iptable-Regeln durch eBPF ersetzt werden. Für eine so umfassende Überarbeitung ist das eine eher geringfügige Verbesserung“, meint der Manager. Sun verweist zudem darauf, dass das Experten-Knowhow in Sachen eBPF noch sehr rar gesät sei und empfiehlt deshalb vorerst auf Nummer Sicher zu gehen: „Die Komplexität von eBPF ist nicht zu unterschätzen, beispielsweise wenn es um die Kernel-Anforderungen, Privilegien für eBPF-Programme oder Debugging geht. Es ist deshalb sinnvoll, für Service-Mesh-Projekte weiterhin iptables-Regeln zu verwenden“. Trotz der genannten Bedenken: eBPF ist auf dem besten Weg, sich als vorherrschendes Modell für Cloud-Netzwerke zu etablieren – und die vielen, einzelnen Container-„Inseln“ zu einem Kontinent zu verbinden, wie John Donne es (vielleicht) formulieren würde. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!