{"id":18953,"date":"2020-06-26T08:13:25","date_gmt":"2020-06-26T06:13:25","guid":{"rendered":"https:\/\/www.inovex.de\/blog\/?p=18953"},"modified":"2024-02-19T08:13:13","modified_gmt":"2024-02-19T07:13:13","slug":"kubernetes-networking-2-calico-cilium-weavenet","status":"publish","type":"post","link":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/","title":{"rendered":"Kubernetes Networking Teil 2: Vergleich von (CNI) Netzwerk-Plugins"},"content":{"rendered":"<p>Anwendungskomponenten, die mittels <a href=\"https:\/\/www.inovex.de\/de\/leistungen\/cloud\/kubernetes\/\">Kubernetes<\/a> als Pods ausgef\u00fchrt werden, k\u00f6nnen \u00fcber mehrere Knoten eines Clusters verteilt sein.\u00a0 Die knoten\u00fcbergreifende Netzwerkkommunikation stellt daher eine besondere Herausforderung dar. Aufgrund der Vielzahl unterschiedlicher Netzwerkumgebungen stellt Kubernetes zwar grundlegende Anforderungen an Netzwerkimplementierungen, setzt diese selbst aber nicht um. Stattdessen wird auf eine verbreitete Spezifikation, das Container Network Interface (CNI), f\u00fcr die Anbindung entsprechender Netzwerkimplementierungen zur\u00fcckgegriffen. Aufgrund dieser Entkopplung sowie der breiten Akzeptanz von CNI steht eine Vielzahl kompatibler Plugins f\u00fcr die Verwendung mit Kubernetes zur Verf\u00fcgung.<\/p>\n<p>Diese Artikelserie fasst die Untersuchungen meiner Bachelorthesis aus September 2019 zusammen, in der ich die Grundlagen des Kubernetes Networkings beleuchtet und die funktionalen und technischen Unterschiede dreier bekannter Netzwerk-Plugins aufgezeigt habe. Dar\u00fcber hinaus wurden m\u00f6gliche Kriterien dargelegt, die f\u00fcr den Vergleich weiterer Plugins oder die Entscheidungshilfe bei der Auswahl eines Plugins herangezogen werden k\u00f6nnen.<\/p>\n<p>Nachdem wir uns im <a href=\"https:\/\/www.inovex.de\/blog\/kubernetes-networking-1-essentials\/\">ersten Teil dieser Serie<\/a> \u00a0mit den Grundlagen des Container- und Kubernetes Networkings befasst haben, schauen wir uns in diesem Teil die CNI-kompatiblen Plugins <a href=\"https:\/\/www.projectcalico.org\/\">Project Calico<\/a>, <a href=\"https:\/\/cilium.io\/\">Cilium<\/a> und Weave Net einmal konkret an. Da die im Rahmen meiner Thesis get\u00e4tigten Untersuchungen sehr umfangreich waren und den Umfang eines Blogposts \u00fcbersteigen w\u00fcrden, beschr\u00e4nke ich mich hierbei auf eine Zusammenfassung der wichtigsten Erkenntnisse. Ausschnitte aus dem jeweiligen \u201eDeep Dive\u201c sowie die abschlie\u00dfende Vergleichsmatrix bieten dennoch einen detaillierten Einblick in das jeweilige Plugin. Einen kurzen \u00dcberblick \u00fcber die angewendete Methodik m\u00f6chte ich euch ebenso nicht vorenthalten.<\/p>\n<p><!--more--><\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_83 counter-hierarchy ez-toc-counter ez-toc-custom ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\"><p class=\"ez-toc-title\" style=\"cursor:inherit\"><\/p>\n<\/div><nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#Was-wurde-wie-verglichen\" >Was wurde wie verglichen?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#Project-Calico\" >Project Calico<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#Cilium\" >Cilium<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#Weave-Net\" >Weave Net<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#Vergleichsmatrix\" >Vergleichsmatrix<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#Bewertung-der-Eignung\" >Bewertung der Eignung<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#Zusammenfassung\" >Zusammenfassung<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"Was-wurde-wie-verglichen\"><\/span>Was wurde wie verglichen?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Bei meinen Untersuchungen habe ich mich f\u00fcr ein stufenweises Vorgehen entschieden. Ausgehend von einem Weitblick beziehungsweise \u201eHigh Level\u201c heraus habe ich mich schrittweise den technischen Details gen\u00e4hert und abschlie\u00dfend kleine Testszenarien mit jedem Plugin durchgef\u00fchrt.<\/p>\n<p>In der ersten Stufe wurden die Rahmendaten des Projekts gesichtet, wie etwa Anbieter, Reifegrad oder Lizenz. Prim\u00e4r an der jeweiligen Dokumentation orientiert wurden <strong>funktionale<\/strong> Merkmale herausgestellt und in die Kategorien <em>Konnektivit\u00e4t<\/em> und <em>Sicherheit<\/em> untergliedert.<\/p>\n<p>In der zweiten Stufe erfolgte die Herausstellung der <strong>technischen<\/strong> Merkmale. Es wurde der Frage nachgegangen, wie die zuvor beschriebenen funktionalen Merkmale technisch umgesetzt werden. Hierzu geh\u00f6rte insbesondere die Architektur, also welche grundlegenden Komponenten zur Umsetzung des Netzwerks ben\u00f6tigt werden und welche internen Mechanismen und Technologien dabei zum Einsatz kommen. Auch hierbei wurde sich noch prim\u00e4r an den Dokumentationen orientiert. Wo immer es an Dokumentation mangelte, wurde stellenweise bereits der Code der Plugins herangezogen.<\/p>\n<p>Stufe 3 umfasste einen Deep Dive, nachdem das jeweilige Plugin in einem Testcluster (Kubernetes v1.15, Docker 18.09) installiert wurde. Erzeugte Kubernetes-Ressourcen sowie virtuelle Netzwerkger\u00e4te (Schnittstellen, Bridges, <span class=\"lang:default decode:true crayon-inline\">veth<\/span>-Paare usw.) wurden mit verschiedenen Linux Tools untersucht, um die verwendeten Protokolle der Kommunikationsvorg\u00e4nge sowie die internen Datenpfade nachvollziehen zu k\u00f6nnen. Augenmerk lag auf der Umsetzung der knoteninternen und knoten\u00fcbergreifenden Kommunikation. Die Untersuchungen wurden in die Bereiche <em>Installation<\/em>, <em>erzeugte Architektur<\/em> und <em>Herstellung der Konnektivit\u00e4t<\/em> unterteilt.<\/p>\n<p>In der vierten und letzten Stufe wurden pro Plugin zwei einfache Testszenarien durchgef\u00fchrt, um einen ersten Eindruck der Plugins im Praxiseinsatz zu erhalten. Zum einen wurde eine bandbreitenintensive Daten\u00fcbertragung zwischen zwei Pods unterschiedlicher Knoten und zwei Pods desselben Knotens mit <a href=\"https:\/\/iperf.fr\/\">iperf3<\/a> simuliert und dabei die mittels <a href=\"https:\/\/github.com\/prometheus\/node_exporter\">Prometheus Node Exporter<\/a> exportierten Metriken \u00fcberwacht (Throughput Test). Zum anderen wurde eine latenzkritische verteilte Anwendung (Microservice Topologie) mit dem <a href=\"https:\/\/istio.io\/\">Istio<\/a> Tool <a href=\"https:\/\/github.com\/istio\/tools\/tree\/master\/isotope\">Isotope<\/a> simuliert (Mock-Up), die eingehende HTTP-Anfragen nach einem definierten Schema an verschiedene Microservices weiterleitet. Mittels <a href=\"https:\/\/github.com\/fortio\/fortio\">Fortio<\/a> wurde die Latenz bis zur Beantwortung der Anfrage an den Initiator gemessen (Latency Test). Der Testaufbau kann der folgenden Abbildung entnommen werden:<\/p>\n<figure id=\"attachment_18955\" aria-describedby=\"caption-attachment-18955\" style=\"width: 622px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Testaufbau.png\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-18955\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Testaufbau.png\" alt=\"\" width=\"622\" height=\"330\" srcset=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Testaufbau.png 1514w, https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Testaufbau-300x159.png 300w, https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Testaufbau-1024x542.png 1024w, https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Testaufbau-768x407.png 768w, https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Testaufbau-400x212.png 400w, https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Testaufbau-360x191.png 360w\" sizes=\"auto, (max-width: 622px) 100vw, 622px\" \/><\/a><figcaption id=\"caption-attachment-18955\" class=\"wp-caption-text\">Abbildung 1 &#8211; Testaufbau<\/figcaption><\/figure>\n<p>Besonders der mit <a href=\"https:\/\/github.com\/istio\/tools\/tree\/master\/isotope\">Isotope<\/a> bereitgestellte Topologiekonverter kann als Mock-Up-Tool zum Nachbilden von Microservice-Architekturen nachdr\u00fccklich empfohlen werden. In Kombination mit <a href=\"https:\/\/github.com\/fortio\/fortio\">Fortio<\/a> entsteht ein idealer Testaufbau zur Durchf\u00fchrung und Visualisierung von Belastungstests. Die genutzte Topologie wies die folgende Struktur auf:<\/p>\n<figure id=\"attachment_18956\" aria-describedby=\"caption-attachment-18956\" style=\"width: 1024px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/01_overview-test-microservice-architecture.png\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-18956 size-large\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/01_overview-test-microservice-architecture-1024x194.png\" alt=\"\" width=\"1024\" height=\"194\" \/><\/a><figcaption id=\"caption-attachment-18956\" class=\"wp-caption-text\">Abbildung 2 \u2013 Microservice Architektur<\/figcaption><\/figure>\n<p>Da hinsichtlich der Hardware der Testumgebung Einschr\u00e4nkungen bestanden (z.B. konnte lediglich in einem Gigabit-Netzwerk getestet werden), gaben die Testergebnisse in der Einzelbetrachtung wenig Aufschluss \u00fcber die Leistungsf\u00e4higkeit eines Plugins. Sie boten einen ersten Eindruck im direkten Vergleich zueinander, zeigten aber nicht die technischen Belastungsgrenzen auf \u2013 insbesondere bei den Durchsatztests. Prim\u00e4res Ziel war hingegen, einen m\u00f6glichen Testaufbau zu entwickeln und die Plugins im Praxiseinsatz zu testen und zu belasten.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Project-Calico\"><\/span>Project Calico<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Project Calico erzeugt ein clusterweites Layer-3-Netzwerk und stellt die Kommunikation zwischen den Knoten mittels klassischem IP-Routing und <a href=\"https:\/\/tools.ietf.org\/html\/rfc4271\">BGP<\/a> Route Distribution sicher. Dabei fungiert jeder Knoten gleichzeitig als Router und pflegt in seiner Kernel-Routing-Tabelle, welche Workloads auf welchen Knoten im Cluster erreichbar sind. Dazu existiert das DaemonSet <span class=\"lang:default decode:true crayon-inline\">calico-node<\/span>, das auf jedem Knoten einen Pod mit dem Agent <em>Felix<\/em> f\u00fcr die Konfiguration von Routing- und <span class=\"lang:default decode:true crayon-inline\">iptables<\/span>-Regeln sowie einem <a href=\"https:\/\/bird.network.cz\">BIRD<\/a> Daemon f\u00fcr die BGP-Funktionalit\u00e4ten ausf\u00fchrt. Felix erzeugt auf seinem jeweiligen Knoten Routingregeln f\u00fcr die lokal ausgef\u00fchrten Pods, bevor der BIRD Daemon diese per BGP an die \u00fcbrigen Knoten des Clusters propagiert. \u00a0Um die Komplexit\u00e4t des Routings gering zu halten und nicht f\u00fcr jeden Pod des Clusters eine eigene Routingregel implementieren zu m\u00fcssen, werden knotenspezifische Subnetze erzeugt, die eine Route Aggregation f\u00fcr alle Pods eines Knotens erm\u00f6glichen.<\/p>\n<p>Auf die Verwendung eines Overlays kann bei Project Calico vollst\u00e4ndig verzichtet werden, wodurch sich sowohl der Paket-Overhead als auch die Ressourcennutzung durch den Wegfall von Encapsulation und Decapsulation der Nutzdaten reduziert. Knotenintern wird durch die Aktivierung von <span class=\"lang:default decode:true crayon-inline\">proxy_arp<\/span>\u00a0auf den <span class=\"lang:default decode:true crayon-inline\">veth<\/span>-Paaren sichergestellt, dass jegliche ARP-Anfragen mit der MAC-Adresse des Hosts beantwortet werden und durch Pods initiierter Datenverkehr grunds\u00e4tzlich durch die im Linux Kernel integrierten Routing- und Filterfunktionen des Hosts auf Layer 3 verarbeitet wird. Dies erm\u00f6glicht eine zentrale Kontrolle der Datenfl\u00fcsse, was zugleich der Grund f\u00fcr den Verzicht auf eine Linux Bridge ist (=&gt; Umsetzbarkeit von Netzwerkrichtlinien zwischen zwei lokalen Pods). Durch die Nutzung von verbreiteten Standards wie BGP, ARP, Linux Kernel Routing oder <span class=\"lang:default decode:true crayon-inline\">iptables<\/span>\u00a0und den m\u00f6glichen Verzicht auf ein Overlay, l\u00e4sst sich Calico mit grundlegenden Netzwerkkenntnissen leicht administrieren und debuggen. Calico verfolgt nach eigenen Angaben ein What-You-See-Is-What-You-Get-Netzwerkmodell, bei dem jedes Paket klar definiert, woher es stammt und wohin es \u00fcbertragen wird. Falls durch das vorliegende Underlay-Netzwerk jedoch nicht anders m\u00f6glich, kann auch Calico auf <a href=\"https:\/\/tools.ietf.org\/html\/rfc1853\">IP-in-IP<\/a> und <a href=\"https:\/\/tools.ietf.org\/html\/rfc7348\">VXLAN<\/a> als Tunnelprotokolle zur\u00fcckgreifen. Project Calico implementiert neben den Kubernetes Network Policies zus\u00e4tzlich ein eigenes Netzwerkrichtlinienmodell in Form einer Custom Resource Definition: Es bietet einen erweiterten Funktionsumfang und neben <span class=\"lang:default decode:true crayon-inline \">allow<\/span>\u00a0auch die Aktionen <span class=\"lang:default decode:true crayon-inline\">deny<\/span>, <span class=\"lang:default decode:true crayon-inline \">log<\/span>\u00a0und <span class=\"lang:default decode:true crayon-inline \">pass<\/span>\u00a0sowie eine Priorisierung der Regeln \u00fcber deren Reihenfolge. Auf Anwendungsebene kann jedoch nativ, also ohne das Hinzuziehen zus\u00e4tzlicher L\u00f6sungen wie Istio, lediglich nach ICMP-Attributen gefiltert werden. Calico unterst\u00fctzt als einziges der betrachteten Plugins das automatische Propagieren von sonst lediglich intern verf\u00fcgbaren <span class=\"lang:default decode:true crayon-inline \">ClusterIPs<\/span>\u00a0mittels BPG, wodurch auf einen Load Balancer bzw. Ingres Controller zur Ver\u00f6ffentlichung von Services verzichtet werden k\u00f6nnte. Eine Lastenverteilung erfolgt dennoch, n\u00e4mlich \u00fcber mehrere Routen mit identischen Kosten (equal cost multi-path).<\/p>\n<p>Abbildung 3 veranschaulicht den Aufbau des Podnetzwerks sowie die durch <span class=\"lang:default decode:true crayon-inline\">tcpdump<\/span>\u00a0ermittelten Datenpfade bei der Verwendung von Project Calico v3.8.1 mit IP-in-IP.<\/p>\n<figure id=\"attachment_18957\" aria-describedby=\"caption-attachment-18957\" style=\"width: 656px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Calico.png\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-18957\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Calico.png\" alt=\"\" width=\"656\" height=\"500\" \/><\/a><figcaption id=\"caption-attachment-18957\" class=\"wp-caption-text\">Abbildung 3 &#8211; Project Calico &#8211; Umsetzung des Podnetzwerks mit IP-in-IP<\/figcaption><\/figure>\n<p>Eine Besonderheit im Vergleich zu der im <a href=\"https:\/\/www.inovex.de\/blog\/kubernetes-networking-1-essentials\/\">ersten Teil dieser Serie<\/a> aufgezeigten m\u00f6glichen Implementierung eines Podnetzwerks (Abbildung 4) fehlen hier aus beschrieben Gr\u00fcnden (<span class=\"lang:default decode:true crayon-inline\">proxy_arp<\/span>) die Bridges. <span class=\"lang:default decode:true crayon-inline \">tunl0<\/span>\u00a0stellt die Schnittstelle zu den \u00fcbrigen Knoten dar. Sie ist immer mit der ersten Hostadresse des jeweiligen Subnetzes versehen und kapselt das urspr\u00fcngliche IP-Paket in ein umschlie\u00dfendes IP-Paket, um die Nutzdaten ohne NAT \u00fcber das Underlay-Netzwerk \u00fcbertragen zu k\u00f6nnen. Durch die von Felix erzeugten Routingregeln wird also an ein entferntes Subnetz gerichteter Datenverkehr grunds\u00e4tzlich \u00fcber diese Schnittstelle weitergeleitet.<\/p>\n<p>Project Calico bietet seit <a href=\"https:\/\/www.projectcalico.org\/whats-new-in-calico-v3-13\/\">v3.13<\/a> eine alternative Implementierung der Data Plane auf Basis von <a href=\"https:\/\/www.projectcalico.org\/introducing-the-calico-ebpf-dataplane\/\">eBPF als Tech Preview<\/a>. Details zu eBPF werden im Folgenden im Kontext von Cilium erl\u00e4utert. Au\u00dferdem hat sich auch eine kostenpflichtige Variante (<a href=\"https:\/\/docs.projectcalico.org\/calico-enterprise\/\">Calico Enterprise<\/a>) etabliert, w\u00e4hrend Project Calico zum Zeitpunkt der Untersuchungen noch vollkommen kostenlos war. Mit <a href=\"https:\/\/www.projectcalico.org\/whats-new-in-calico-v3-14\/\">v3.14<\/a> wurde zudem eine <a href=\"https:\/\/www.projectcalico.org\/introducing-wireguard-encryption-with-calico\/\">Data Plane Encryption mit Wireguard<\/a> eingef\u00fchrt (Tech Preview). Zum Zeitpunkt der Untersuchungen (Mitte 2019) bot Project Calico als einziges der drei Plugins noch keine Verschl\u00fcsselung der Data Plane.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Cilium\"><\/span>Cilium<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Cilium implementiert ebenfalls ein Layer-3-Netzwerk mit knotenspezifischen Subnetzen, setzt jedoch auf den weniger verbreiteten extended Berkeley Packet Filter (eBPF). Dabei handelt es sich um eine neue Linux-Kerneltechnologie, mit der sich Datenfl\u00fcsse sehr flexibel und hardwarenah beeinflussen lassen. An verschiedenen Stellen im Kernel, den Hook Points, lassen sich BPF-Programme ausf\u00fchren, die Datenpakete abfangen und manipulieren (z.B. blocken oder weiterleiten) k\u00f6nnen. Diese BPF-Programme werden in CPU-Instruktionen kompiliert, sodass sich die Datenpfade mit klassischen Linux-Bordmitteln nicht ohne weiteres nachverfolgen lassen: W\u00e4hrend bei Calico die Ausf\u00fchrung von <span class=\"lang:default decode:true crayon-inline\">$ ip route<\/span>\u00a0bereits ausreicht, um die Funktionsweise des Podnetzwerks nachzuvollziehen, ist bei Cilium ein Studium der BPF-Programme notwendig. Diese werden durch den als DaemonSet ausgef\u00fchrten <em>Cilium Agent<\/em> in Abh\u00e4ngigkeit des Clusterzustandes (wie etwa aktiven Pods und Network Policies) generiert, kompiliert und in den Kernel injiziert.<\/p>\n<p>Standardm\u00e4\u00dfig setzt Cilium die knoten\u00fcbergreifende Kommunikation mit VXLAN um, <a href=\"https:\/\/tools.ietf.org\/html\/draft-ietf-nvo3-geneve-16\">Geneve<\/a> ist alternativ ebenfalls zur Encapsulation nutzbar. Falls es die Begebenheiten des zugrundeliegenden Netzwerks zulassen, kann jedoch auch bei Cilium auf ein Overlay verzichtet werden. Die BPF-Programme \u00fcberreichen dabei die Datenpakete an die Routing-Funktion des Linux Kernels, statt sie f\u00fcr die weitere \u00dcbertragung einzukapseln. So k\u00f6nnen sie \u00fcber die Kernel Routing-Tabelle weiterverarbeitet werden. Die Konfiguration der Routen \u00fcbernimmt Cilium jedoch nicht.<\/p>\n<p>Cilium setzt die Kubernetes Network Policies ebenfalls mit eBPF um und bietet ebenso wie Project Calico zus\u00e4tzlich ein eigenes Netzwerkrichtlinienmodell in Form einer Custom Resource Definition. Dar\u00fcber bestehen im Vergleich zu Project Calico und Weave Net die meisten M\u00f6glichkeiten zur Filterung auf Anwendungsebene, z.B. mittels HTTP-Attributen. Eine Besonderheit ist ein identit\u00e4tsbasierter Ansatz. So m\u00fcssen bei einer Netzwerkrichtlinie, die \u00fcber Labels auf eine <em>Gruppe<\/em> von Pods angewendet wird, klassischerweise die auf den Knoten erzeugten Filterregeln st\u00e4ndig mit den aktuellen IP-Adressen der zutreffenden Pods aktualisiert werden. Schlie\u00dflich k\u00f6nnen Pods h\u00e4ufiger hinzugef\u00fcgt und gel\u00f6scht werden. Bei Ciliums identit\u00e4tsbasierten Ansatz hingegen werden bei der Encapsulation der Nutzdaten von den Kubernetes Labels abgeleitete Identit\u00e4tslabels vorangestellt. Diese erm\u00f6glichen eine deutlich effizientere Verarbeitung durch die BPF-Programme, als bei der Auswertung des IP-Header. Cilium bietet au\u00dferdem eine integrierte Verschl\u00fcsselung mittels IPSec, die sich bei Verwendung mit Overlay aber noch im Betastadium befindet.<\/p>\n<p>Abbildung 6 fasst meine Untersuchungen hinsichtlich des Aufbaus und der mit <span class=\"lang:default decode:true crayon-inline\">tcpdump<\/span>\u00a0ermittelten Datenpfade bei der Nutzung von Cilium v1.5.5 mit VXLAN grafisch zusammen. Die durch Cilium verwendeten Hook Points sind ebenso wie die dort verkn\u00fcpften BPF-Programme an den entsprechenden Stellen markiert. Am <strong>Traffic Control (TC) Ingress <\/strong>beziehungsweise<strong> Egress Hook<\/strong> k\u00f6nnen Programme f\u00fcr den eingehenden beziehungsweise ausgehenden Datenverkehr einer Netzwerkschnittstelle ausgef\u00fchrt werden. Eingehend wird der Hook nach der initialen Verarbeitung eines Datenpakets durch den Netzwerkstack ausgef\u00fchrt, allerdings noch vor Erreichen von Layer 3. Er eignet sich f\u00fcr die knoteninterne Verarbeitung von Datenverkehr, z.B. die Weiterleitung an andere Workloads. Cilium kann zus\u00e4tzlich den <strong>Express Data Path (XDP) Hook<\/strong> nutzen, der sich z.B. bei der Verwendung von Network Policies f\u00fcr das fr\u00fchzeitige und effiziente Verwerfen von unerw\u00fcnschtem Datenverkehr anbietet: Entsprechende BPF-Programme werden \u00fcber den Netzwerktreiber einer Schnittstelle ausgef\u00fchrt, weshalb sich Datenpakete bereits vor Erreichen des Netzwerkstacks abgreifen lassen. F\u00fcr die Nutzung des <strong>Socket Operation Hook<\/strong> sowie des <strong>Socket send\/recv Hook<\/strong> muss <a href=\"https:\/\/cilium.io\/blog\/2019\/02\/12\/cilium-14\/#sockmap-bpf-based-sidecar-acceleration-alpha\">Sockmap Acceleration<\/a> aktiviert werden. Die Untersuchungen wurden mit dem Linux Tool <span class=\"lang:default decode:true crayon-inline \">tc<\/span>\u00a0zur Anzeige der Traffic-Control-Einstellungen im Kernel sowie mit <span class=\"lang:default decode:true crayon-inline \">bpftool<\/span>\u00a0durchgef\u00fchrt. Letzteres dient zur Anzeige von BPF-Programmen am TC- und XDP-Hook. Der Quellcode der BPF-Programme ist auf <a href=\"https:\/\/github.com\/cilium\/cilium\/tree\/master\/bpf\">GitHub<\/a> einsehbar. Weitere Erl\u00e4uterungen zu den Hook Points und BPF sind in der <a href=\"https:\/\/docs.cilium.io\/en\/stable\/bpf\/\">Dokumentation<\/a> zu finden.<\/p>\n<figure id=\"attachment_18958\" aria-describedby=\"caption-attachment-18958\" style=\"width: 722px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Cilium.png\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-18958\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Cilium.png\" alt=\"\" width=\"722\" height=\"500\" \/><\/a><figcaption id=\"caption-attachment-18958\" class=\"wp-caption-text\">Abbildung 4 &#8211; Cilium &#8211; Umsetzung des Podnetzwerks mit VXLAN<\/figcaption><\/figure>\n<p>Die dargestellte <span class=\"lang:default decode:true crayon-inline\">cilium_host<\/span>-Schnittstelle dient dem durch das Hostsystem initiierten Datenverkehr: Auf jedem Knoten existieren Routingregeln, nach denen an die knotenspezifischen Subnetze und somit an das Podnetzwerk gerichteter Datenverkehr \u00fcber <span class=\"lang:default decode:true crayon-inline \">cilium_host<\/span>\u00a0geleitet wird. Dies hat den Effekt, dass dem initiierten Datenpaketen eine valide Quell-IP-Adresse aus dem Podnetzwerk f\u00fcr nachfolgende Antwortpakete zugewiesen wird<\/p>\n<p>Seit meinen Untersuchungen Mitte 2019 sind auch bei Cilium viele Neuerungen und eine rege Weiterentwicklung zu beobachten. Mit <a href=\"https:\/\/github.com\/cilium\/hubble\">Hubble<\/a> existiert z.B. eine auf Cilium und eBPF aufbauende, verteilte Networking- und Observability-Plattform f\u00fcr cloudbasierte Workloads. Sie soll Einblicke in die Netzwerkinfrastruktur bieten sowie die Kommunikation zwischen Microservices transparenter machen. Auch die Verschl\u00fcsselung mittels IPSec ist derweil bei der Verwendung von nativem Routing (ohne Overlay) <a href=\"https:\/\/docs.cilium.io\/en\/v1.7\/gettingstarted\/encryption\/\">stable<\/a>. Seit <a href=\"https:\/\/cilium.io\/blog\/2019\/08\/20\/cilium-16\">v1.6<\/a> wird au\u00dferdem in Verbindung mit Kubernetes kein separater Key-Value Store mehr ben\u00f6tigt, w\u00e4hrend zuvor bei der Installation von Cilium ein dediziertes etcd-Cluster erzeugt wurde. Auch auf kube-proxy und die damit verbundene Vielzahl an\u00a0<span class=\"lang:default decode:true crayon-inline\">iptables<\/span>-Regeln f\u00fcr die Umsetzung von Services kann nun durch einen auf eBPF basierenden Ansatz vollst\u00e4ndig verzichtet werden. Mit <a href=\"https:\/\/cilium.io\/blog\/2020\/06\/22\/cilium-18\">v1.8<\/a>\u00a0(Juni 2020) wurden weitere auf\u00a0<span class=\"lang:default decode:true crayon-inline\">iptables<\/span> basierende Funktionen durch native eBPF-Implementierungen ersetzt, wie z.B. die Umsetzung von Services des Typs\u00a0<span class=\"lang:default decode:true crayon-inline\">NodePort<\/span>.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Weave-Net\"><\/span>Weave Net<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Weave Net ist das \u00e4lteste aller betrachteten Plugins und wurde urspr\u00fcnglich f\u00fcr die Verbindung von Docker Containern entwickelt. Im Gegensatz zu Project Calico und Cilium spannt es ein clusterweites Layer-2-Netzwerk auf und nutzt dabei Standards wie das Address Resolution Protocol (ARP) und Forwarding Information Bases zur L2 Neighbour Discovery.<\/p>\n<p>F\u00fcr die knoten\u00fcbergreifende Kommunikation stehen bei Weave Net zwei Methoden zur Verf\u00fcgung: Der\u00a0<strong>Fast Datapath Modus<\/strong>, der vollst\u00e4ndig innerhalb des Kernels stattfindet, sowie der\u00a0<strong>Sleeve Modus<\/strong> als R\u00fcckfall, bei dem Datenpakete f\u00fcr nicht-lokale Ziele im Kernel mittels <span class=\"lang:default decode:true crayon-inline \">pcap<\/span>\u00a0abgegriffen und durch den als DeamonSet ausgef\u00fchrten Weave Router per UDP an den Weave Router des Zielknotens weitergeleitet werden. Da Weave Net ein virtuelles Layer-2-Netzwerk bereitstellt und damit simuliert, dass alle Workloads an einem gemeinsamen Netzwerkswitch angeschlossen sind, <em>muss<\/em> eine Overlay-Technologie f\u00fcr die knoten\u00fcbergreifende Pod-to-Pod-Kommunikation eingesetzt und ausgehende, nicht-lokale Ethernet Frames eingekapselt werden. Das gilt selbst dann, wenn sich alle Knoten im selben lokalen Netzwerk befinden. Die Entscheidung, ob eine Verbindung im Fast DP Modus aufgebaut werden kann, wird je nach Begebenheiten knotenindividuell getroffen (siehe Abbildung 5):<\/p>\n<figure id=\"attachment_18959\" aria-describedby=\"caption-attachment-18959\" style=\"width: 665px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Weave-Net_architecture_nicht-trans.png\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-18959\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Weave-Net_architecture_nicht-trans-1024x693.png\" alt=\"\" width=\"665\" height=\"318\" \/><\/a><figcaption id=\"caption-attachment-18959\" class=\"wp-caption-text\">Abbildung 5 &#8211; Weave Net &#8211; Weitblick auf die logische Architektur (Vollvermaschung)<\/figcaption><\/figure>\n<p>Forwarding Information Bases werden sowohl innerhalb der knotenlokalen Linux Bridges als auch innerhalb der auf jedem Knoten ausgef\u00fchrten Weave Router gepflegt. Letztere fungieren ins knoteninnere (also gegen\u00fcber den Workloads) wie klassische Switches. Sie sind einerseits mit der eigenen knoteninternen Bridge und andererseits logisch mit denen aller anderen Knoten des Clusters verbunden. Nach extern \u00fcbersetzen sie jedoch von Layer 2 durch Encapsulation in Layer 3, um Ethernet Frames netz\u00fcbergreifend \u00fcbertragen zu k\u00f6nnen. Sie bilden \u00fcber TCP eine Control Plane, tauschen Topologieinformationen untereinander aus und erkennen automatisch neue Knoten im Cluster. Durch die Kenntnis eines jeden Knotens, welche Knoten miteinander verbunden sind, k\u00f6nnen sie auch in teilvermaschten Netzen eingekapselte Frames \u00fcber Intermediate-Knoten \u00fcbermitteln.<\/p>\n<p>Durch die zus\u00e4tzliche \u00dcbertragung von Metadaten innerhalb des Weave-Net-eigenen Kapselungsformats (Sleeve Modus) beziehungsweise des VXLAN Headers (Fast Datapath) lernt jeder Knoten, der ein UDP-Datagramm mit eingekapselten Ethernet Frames zur Weiterverarbeitung erh\u00e4lt, \u00fcber welchen Knoten die Absender-Pods (in Form ihrer MAC-Adresse) der eingekapselten Frames erreichbar sind. So baut jeder Weave Router \u2013 vergleichbar mit einem Switch \u2013 eine Informationsbasis auf und kann k\u00fcnftige lokal initiierte Frames zielgerichtet zustellen. Damit soll verhindert werden, dass Datenverkehr f\u00fcr nicht-lokale Ziele \u2013 wie bei einem Hub \u2013 an <em>alle<\/em> Knoten des Clusters gesendet wird. Liegen innerhalb der FIBs noch keine Informationen zur Lokalit\u00e4t des Zielpods vor, werden diese initial durch klassische ARP Broadcasts ermittelt.<\/p>\n<p>Insofern sich die Knoten ohne NAT erreichen k\u00f6nnen und der Port 6784 freigegeben ist (typischerweise in lokalen Netzen), setzt Weave Net im Rahmen von Fast Datapath auf das Linux Kernelmodul Open vSwitch. Dabei erteilt der Weave Router aus dem User Space heraus Anweisungen auf Basis der von ihm gesammelten Informationen, wie Frames verarbeitet beziehungsweise weitergeleitet werden sollen. Fast Datapath l\u00e4uft einschlie\u00dflich der Encapsulation von Frames vollst\u00e4ndig im Kernel ab und ist somit schneller und effizienter als die Verarbeitung des Datenverkehrs durch die Weave Router im Sleeve Modus. In letzterem sind mehrere Kontextwechsel notwendig, da Datenpakete von der initiierenden Applikation im User Space an den Kernel gereicht und anschlie\u00dfend durch den Weave Router im User Space wieder abgegriffen werden.<\/p>\n<p>Weave Net setzt Kubernetes Network Policies mittels <span class=\"lang:default decode:true crayon-inline \">iptables<\/span>\u00a0um und kann jegliche knoten\u00fcbergreifende Kommunikation verschl\u00fcsseln (Control Plane + Data Plane). Die genauen Mechanismen f\u00fcr die knoten\u00fcbergreifende Kommunikation sind durch den Einsatz des Weave Routers beziehungsweise Open vSwitch ohne eine zus\u00e4tzliche Einarbeitung weniger transparent. Weave Nets Architektur ist hingegen \u00e4u\u00dferst simpel gehalten: Das gesamte Weave Net Deployment besteht aus lediglich einem Pod pro Knoten (DaemonSet) mit einem Container f\u00fcr den Weave Router sowie einem weiteren Container f\u00fcr den Network Policy Controller. Ein verteilter Key-Value Store wird durch Weave Net nicht ben\u00f6tigt.<\/p>\n<p>Abbildung 6 fasst meine Untersuchungen hinsichtlich des Aufbaus des Podnetzwerks und der mit <span class=\"lang:default decode:true crayon-inline \">tcpdump<\/span>\u00a0ermittelten Datenpfade bei der Nutzung von Weave Net v2.5.2 mit Fast Datapath grafisch zusammen.<\/p>\n<figure id=\"attachment_18960\" aria-describedby=\"caption-attachment-18960\" style=\"width: 655px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Weave-Net.png\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-18960\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Weave-Net.png\" alt=\"\" width=\"655\" height=\"500\" \/><\/a><figcaption id=\"caption-attachment-18960\" class=\"wp-caption-text\">Abbildung 6 &#8211; Weave Net &#8211; Umsetzung des Podnetzwerks bei Fast Datapath<\/figcaption><\/figure>\n<p>Durch den Knoten selbst initiierte und an das Podnetzwerk gerichtete Datenpakete werden via Routingregel \u00fcber die <span class=\"lang:default decode:true crayon-inline\">weave<\/span>-Bridge geleitet und dort mit einer validen IP-Adresse aus dem Podnetzwerk versehen. Das <span class=\"lang:default decode:true crayon-inline\">veth<\/span>-Paar bestehend aus <span class=\"lang:default decode:true crayon-inline\">vethwe-bridge<\/span>\u00a0und <span class=\"lang:default decode:true crayon-inline \">vethwe-datapath<\/span>\u00a0stellt die virtuelle Ethernetverbindung zwischen lokaler Linux Bridge und dem Open vSwitch Datapath in Form der <span class=\"lang:default decode:true crayon-inline\">datapath<\/span>-Schnittstelle dar, an der Datenpakete abgegriffen und injiziert werden.<\/p>\n<p>Seit meinen Untersuchungen Mitte 2019 sind bei Weave Net (aktuell in <a href=\"https:\/\/github.com\/weaveworks\/weave\/releases\/tag\/v2.6.5\">v2.6.5<\/a> aus Juni 2020) im Vergleich zu Project Calico und Cilium haupts\u00e4chlich Bugfixes und Verbesserungen zu beobachten, wie sich den <a href=\"https:\/\/github.com\/weaveworks\/weave\/releases\">Releases auf GitHub<\/a> entnehmen l\u00e4sst. Erw\u00e4hnenswerte neue Features blieben demnach aus.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Vergleichsmatrix\"><\/span>Vergleichsmatrix<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Wichtige funktionale und technische Merkmale der drei betrachteten Plugins sind in der am Ende dieses Artikels aufgef\u00fchrten Vergleichsmatrix zusammengefasst. Sie kann beim Auswahlprozess unterst\u00fctzen oder als Grundlage f\u00fcr den Vergleich bzw. die Untersuchung weiterer Kubernetes Netzwerk-Plugins herangezogen werden. Die Vergleichsmatrix wurde nach bestem Gewissen auf Basis meiner Untersuchungen und den Informationen aus den jeweiligen Dokumentationen zusammengestellt. Au\u00dferdem wurde sie im Rahmen dieses Artikels noch einmal auf den aktuellen Stand gebracht. Dennoch k\u00f6nnen die Daten aufgrund des Umfangs und der Komplexit\u00e4t der Thematik sowie der regen Weiterentwicklung von Project Calico und Cilium derweil unvollst\u00e4ndig oder ung\u00fcltig geworden sein.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Bewertung-der-Eignung\"><\/span>Bewertung der Eignung<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Project Calico kann als Allrounder eingestuft werden. Das Plugin besitzt keine nennenswerten Schw\u00e4chen und bietet eine Kombination aus umfangreichen Netzwerk- sowie Sicherheitsfunktionen. Da es f\u00fcr den Aufbau eines Podnetzwerks neben BIRD ausschlie\u00dflich auf Linux Bordmittel zur\u00fcckgreift, ist es leicht verst\u00e4ndlich und mit Netzwerkgrundkenntnissen leicht zu betreiben und zu debuggen. Infolge der uneingeschr\u00e4nkten Nutzungsm\u00f6glichkeit mit nativem Routing bietet sich Calico besonders f\u00fcr Projekte an, bei denen Zugriff auf eine physische Infrastruktur besteht und kein Overlay ben\u00f6tigt wird. Eine ausbleibende Encapsulation von Nutzdaten beg\u00fcnstigt durchsatzintensive Anwendungen. Aber auch mit Overlay stellt Calico f\u00fcr durchsatzintensive Anwendungen aufgrund der simplen und effizienten IP-in-IP Encapsulation mit lediglich 20 Byte Overhead eine gute Wahl dar. Dank BGP l\u00e4sst sich ein durch Calico verwaltetes Podnetzwerk zudem ideal in vorhandene Netzwerkinfrastrukturen integrieren, z.B. durch das automatische Propagieren einer sonst ausschlie\u00dflich clusterintern verf\u00fcgbaren <span class=\"lang:default decode:true crayon-inline\">ClusterIP<\/span>. Eine Skalierungsgrenze wird seitens Calico nicht genannt, lediglich bei \u00fcber 4.000 Knoten sollte auf ein separates etcd-Cluster zur\u00fcckgegriffen werden, statt den Kubernetes etcd \u00fcber die Kubernetes API mitzubenutzen. Die Integration von Wireguard als Tech Preview ist ein wichtiger Schritt, um den Nachteil der fehlenden Verschl\u00fcsselung gegen\u00fcber Cilium und Weave Net zu eliminieren. Die nachtr\u00e4gliche Einf\u00fchrung einer eBPF Data Plane neben weiteren Features zeigt au\u00dferdem, dass das Projekt technologisch keineswegs stillsteht und auch zuk\u00fcnftig mit einer gro\u00dfen Dynamik zu rechnen ist.<\/p>\n<p>Cilium kann als Netzwerkl\u00f6sung mit Sicherheitsfokus betrachtet werden. Umfangreiche M\u00f6glichkeiten hinsichtlich der Netzwerkrichtlinien sowie deren Verarbeitung durch einen identit\u00e4tsbasierten Ansatz machen Cilium f\u00fcr Projekte attraktiv, bei denen umfassende Absicherungen zwischen vielen Workloads notwendig sind. Ist also im Voraus eine gro\u00dfe Anzahl an Netzwerkrichtlinien abzusehen, sollte Cilium in Betracht gezogen werden, da der identit\u00e4tsbasierte Ansatz im Vergleich zu einer Vielzahl von <span class=\"lang:default decode:true crayon-inline\">iptables<\/span>-Regeln, die zudem auf jedem Knoten fortlaufend aktualisiert werden m\u00fcssen, effizienter und schneller von statten gehen sollte. Au\u00dferdem wird die Effizienz und Skalierbarkeit eines Clusters durch den Verzicht auf kube-proxy und <span class=\"lang:default decode:true crayon-inline\">iptables<\/span>\u00a0bei der Umsetzung von Kubernetes Services beg\u00fcnstigt. Beides gilt es jedoch im Einzelfall durch weiterf\u00fchrende Tests zu pr\u00fcfen. Die hohe Anzahl an Issues im offiziellen GitHub-Projekt sind ein Indiz f\u00fcr eine gro\u00dfe Beliebtheit. Dass mit der Nutzung von Cilium der Einsatz der noch sehr jungen und komplexen Technologie eBPF einhergeht, muss ber\u00fccksichtigt werden, bietet zugleich aber auch gro\u00dfes Potential, das zwischenzeitig auch durch Project Calico erkannt wurde. Cilium eignet sich nachweislich f\u00fcr sehr gro\u00dfe Cluster und wurde mit 5.000 Knoten, 100.000 Pods und 20.000 Services getestet. Die zahlreichen neuen Features der letzten Monate, wie z.B. Hubble oder die stetigen Optimierungen rund um eBPF, belegen auch bei Cilium eine sehr aktive Weiterentwicklung und das regelm\u00e4\u00dfige Setzen von technologischen Ma\u00dfst\u00e4ben im Bereich Container Networking.<\/p>\n<p>Weave Net kann als Netzwerk-Plugin mit dem Fokus auf Netzwerkfunktionalit\u00e4ten zusammengefasst werden. Es kann die Konnektivit\u00e4t zwischen Pods in teilvermaschten Umgebungen durch die beschriebenen Selbstlernprozesse herstellen und eignet sich somit f\u00fcr Topologien, bei denen andere Plugins Probleme bereiten k\u00f6nnten. Die tats\u00e4chliche Praxisrelevanz solcher Szenarien bleibt jedoch fraglich. Aufgrund der Implementierung eines Layer-2-Netzes mit FIBs k\u00f6nnten in gr\u00f6\u00dferen Umgebungen mit einer hohen Knotenanzahl\u00a0 aufgrund der Entstehung gro\u00dfer Broadcastdom\u00e4nen jedoch mitunter andere L\u00f6sungen geeigneter sein. Dies ist im Einzelfall durch weiterf\u00fchrende Tests zu \u00fcberpr\u00fcfen. F\u00fcr Szenarien, in denen auf ein Overlay verzichtet werden soll, ist Weave Net nicht geeignet. Werden Filterfunktionen \u00fcber die der Kubernetes Network Policies hinaus ben\u00f6tigt, stellen Calico beziehungsweise Cilium die bessere Wahl dar. Hingegen bietet Weave Net bereits am l\u00e4ngsten eine stabile, integrierte Verschl\u00fcsselung der Data Plane.\u00a0Bei der Skalierung eines Clusters mit Weave Net muss das Verbindungslimit der Control Plane beachtet werden, das standardm\u00e4\u00dfig 100 Verbindungen pro Knoten betr\u00e4gt. Bei deutlich mehr Knoten kann es bei einer Vollvermaschung zu \u00fcberm\u00e4\u00dfiger Rechen- und Netzwerklast kommen und eine Reduktion des Limits erfordern. Dies h\u00e4tte eine teilvermaschte Topologie zur Folge, in der sich einzelne Knoten nicht mehr direkt erreichen k\u00f6nnen und Latenzen steigen. In Umgebungen der Gr\u00f6\u00dfenordnung mehrerer hundert Knoten ist Weave Net daher im Vergleich zu Calico und Cilium weniger pr\u00e4destiniert. Weave Net ist eine ausgereifte Netzwerkl\u00f6sung und konzentriert sich im R\u00fcckblick auf die letzten Monate prim\u00e4r auf Bugfixes und kleine Verbesserungen statt auf nennenswerte, neue Features.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Zusammenfassung\"><\/span>Zusammenfassung<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Was l\u00e4sst sich aus den durchgef\u00fchrten Untersuchungen nun schlussfolgern und zusammenfassen? Alle untersuchten Plugins sind einfach zu installieren und stellen die Konnektivit\u00e4t im Cluster zuverl\u00e4ssig her. Aus einer distanzierten Sichtweise heraus ist es schwierig, eine allgemeing\u00fcltige Empfehlung auszusprechen, da jedes Plugin gleicherma\u00dfen gebrauchstauglich ist. Aufgrund der hohen Individualit\u00e4t von Anforderungen und zugrundeliegender Infrastrukturen kann und soll zudem kein \u201eTestsieger\u201c ausgemacht werden &#8211; zumal die in meiner Thesis durchgef\u00fchrten Messungen keine signifikanten Unterschiede aufwiesen, die die Untauglichkeit eines Plugins belegen w\u00fcrden. Hier w\u00fcrde die Entwicklung weiterf\u00fchrender Testszenarien, insbesondere unter dem Einsatz von Network Policies, Jumbo Frames oder performanterer Hardware mehr Aufschluss \u00fcber die Tauglichkeit eines Plugins in bestimmten Einsatzszenarien geben. Dennoch zeichnen sich die verschiedenen L\u00f6sungen im Detail durch einige wichtige funktionale und technische Unterschiede aus, die in Abh\u00e4ngigkeit des durchzuf\u00fchrenden Projekts und der zur Verf\u00fcgung stehenden Infrastruktur individuelle Vor- und Nachteile aufweisen und bei der Auswahl ber\u00fccksichtigt werden sollten. Einige Aspekte habe ich in diesem Artikel dargelegt. Sie k\u00f6nnen ebenso wie die erarbeitete Vergleichsmatrix die Entscheidungsfindung ma\u00dfgeblich unterst\u00fctzen und ersparen eine zeitintensive Einarbeitung in die umfangreiche Thematik rund um das Kubernetes Networking. Vorab sollten allerdings zumindest die folgenden Fragen beantwortet werden, um eine Vorauswahl herausfiltern zu k\u00f6nnen:<\/p>\n<ul>\n<li>Welche Anzahl an Knoten ist zu erwarten?<\/li>\n<li>Bestehen Pr\u00e4ferenzen hinsichtlich IPv4 oder IPv6?<\/li>\n<li>Bestehen Pr\u00e4ferenzen hinsichtlich der Topologie des Podnetzwerks (L2 oder L3)?<\/li>\n<li>Wird ein Overlay ben\u00f6tigt?<\/li>\n<li>Wird eine integrierte Verschl\u00fcsselung ben\u00f6tigt?<\/li>\n<li>In welchem Umfang und auf welchen Layern sollen Network Policies zum Einsatz kommen?<\/li>\n<\/ul>\n<p>F\u00fcr eine verbindliche Aussage hinsichtlich des Verhaltens eines Plugins unter bestimmten Voraussetzungen sind situationsspezifische Tests unabdingbar. Einige M\u00f6glichkeiten f\u00fcr die Durchf\u00fchrung solcher Tests wurden zu Beginn dieses Artikels aufgezeigt, woran f\u00fcr zuk\u00fcnftige Untersuchungen angekn\u00fcpft werden kann. Da besonders Cilium und Project Calico bez\u00fcglich ihrer Weiterentwicklung einer gro\u00dfen Dynamik unterliegen \u2013 vor allem rund um eBPF \u2013 ist f\u00fcr ein vollst\u00e4ndiges Bild eine regelm\u00e4\u00dfige Neubewertung der Plugins unerl\u00e4sslich. Auch sollten weitere Plugins wie <a href=\"https:\/\/github.com\/coreos\/flannel\">Flannel<\/a> oder <a href=\"https:\/\/www.kube-router.io\">Kube-router<\/a>, die im Rahmen meiner Bachelorthesis nicht betrachtet werden konnten, nicht au\u00dfer Acht gelassen werden.<\/p>\n\n<table id=\"tablepress-21\" class=\"tablepress tablepress-id-21\">\n<thead>\n<tr class=\"row-1\">\n\t<td class=\"column-1\"><\/td><th class=\"column-2\">Project Calico<\/th><th class=\"column-3\">Cilium<\/th><th class=\"column-4\">WeaveNet<\/th><td class=\"column-5\"><\/td>\n<\/tr>\n<\/thead>\n<tbody class=\"row-striping row-hover\">\n<tr class=\"row-2\">\n\t<td class=\"column-1\">Anbieter<\/td><td class=\"column-2\">Tigera Inc.<\/td><td class=\"column-3\">Isovalent Inc.<\/td><td class=\"column-4\">Weaveworks Inc.<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-3\">\n\t<td class=\"column-1\">Preis<\/td><td class=\"column-2\">kostenlos, optional Calico Enterprise (kostenpflichtig)<\/td><td class=\"column-3\">kostenlos<\/td><td class=\"column-4\">kostenlos, optional WeaveCloud (kostenpflichtig)<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-4\">\n\t<td class=\"column-1\">OpenSource \/ Lizenz<\/td><td class=\"column-2\">ja, Apache License, Version 2.0<\/td><td class=\"column-3\">ja, Apache License, Version 2.0 (User Space Komponenten); General Public License, Version 2.0 (BPF Code Templates)<\/td><td class=\"column-4\">ja, Apache License, Version 2.0<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-5\">\n\t<td class=\"column-1\">Support<\/td><td class=\"column-2\">Community + kostenpflichtig<\/td><td class=\"column-3\">Community + kostenpflichtig<\/td><td class=\"column-4\">Community + kostenpflichtig<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-6\">\n\t<td class=\"column-1\">Quellcode<\/td><td class=\"column-2\">https:\/\/github.com\/projectcalico<\/td><td class=\"column-3\">https:\/\/github.com\/cilium\/cilium<\/td><td class=\"column-4\">https:\/\/github.com\/weaveworks\/weave<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-7\">\n\t<td class=\"column-1\">Dokumentation<\/td><td class=\"column-2\">https:\/\/docs.projectcalico.org\/<\/td><td class=\"column-3\">https:\/\/docs.cilium.io\/en\/latest\/<\/td><td class=\"column-4\">https:\/\/www.weave.works\/docs\/net\/latest\/<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-8\">\n\t<td class=\"column-1\">Programmiersprachen<\/td><td class=\"column-2\">Go, Ruby, Python<\/td><td class=\"column-3\">Go, C<\/td><td class=\"column-4\">Go<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-9\">\n\t<td class=\"column-1\">aktuelle Version<\/td><td class=\"column-2\">v3.14.1 (29.05.2020)<\/td><td class=\"column-3\">v1.8.0 (22.06.2020)<\/td><td class=\"column-4\">v2.6.5 (10.06.2020)<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-10\">\n\t<td class=\"column-1\">erstes Release<\/td><td class=\"column-2\">16.01.2015 (v0.10)<\/td><td class=\"column-3\">28.03.2017 (v0.8.0)<\/td><td class=\"column-4\">30.12.2014 (v0.7)<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-11\">\n\t<td class=\"column-1\">Issues offen\/geschlossen<\/td><td class=\"column-2\">118\/1105 (10,7%)<\/td><td class=\"column-3\">440\/3427 (12,8%)<\/td><td class=\"column-4\">411\/1713 (24,0%)<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-12\">\n\t<td class=\"column-1\">Kernel Version<\/td><td class=\"column-2\">>= 3.10<\/td><td class=\"column-3\">>= 4.9.17 (wegen eBPF)<\/td><td class=\"column-4\">>= 3.8<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-13\">\n\t<td class=\"column-1\">Kubernetes Version<\/td><td class=\"column-2\">>= v1.9, aktuelles Release getestet mit >= v1.16<\/td><td class=\"column-3\">>= v1.9, aktuelles Release getestet mit >= v1.11<\/td><td class=\"column-4\">>= v1.4<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-14\">\n\t<td class=\"column-1\">Empfehlung max. Clustergr\u009a\u00f6\u00dfe<\/td><td class=\"column-2\">4k Nodes mit Kubernetes etcd, keine Angabe bei externem etcd<\/td><td class=\"column-3\">5k Nodes, 100k Pods, 20k Services (durch Cilium getestet, mehr m\u009a\u00f6glich)<\/td><td class=\"column-4\">(pro Knoten 100 Control Plane Verbindungen zu anderen Knoten)<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-15\">\n\t<td class=\"column-1\">CLI-Tool<\/td><td class=\"column-2\">ja, calicoctl<\/td><td class=\"column-3\">ja, cilium-agent (in \"cilium-*\" Pods)<\/td><td class=\"column-4\">ja, weave<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-16\">\n\t<td class=\"column-1\">Konnektivit\u00e4t\u008a<\/td><td class=\"column-2\"><\/td><td class=\"column-3\"><\/td><td class=\"column-4\"><\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-17\">\n\t<td class=\"column-1\">IP-Versionen<\/td><td class=\"column-2\">IPv4, IPv6<\/td><td class=\"column-3\">IPv4, IPv6<\/td><td class=\"column-4\">IPv4<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-18\">\n\t<td class=\"column-1\">Adressierung \/ IPAM<\/td><td class=\"column-2\">knotenspezifische Subnnetze (mehrere pro Knoten bei Ersch\u009a\u00f6pfung), optional Subnetting f\u00fc\u009fr verschiedene topologische Bereiche m\u009a\u00f6glich<\/td><td class=\"column-3\">knotenspezifische Subnetze<\/td><td class=\"column-4\">clusterweites Netz, zusammenh\u008angender Adressbereich pro Knoten, der untereinander dynamisch ausgehandelt wird<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-19\">\n\t<td class=\"column-1\">Topologie Podnetzwerk<\/td><td class=\"column-2\">clusterweites Layer 3 Netzwerk<\/td><td class=\"column-3\">clusterweites Layer 3 Netzwerk<\/td><td class=\"column-4\">clusterweites Layer 2 Netzwerk<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-20\">\n\t<td class=\"column-1\">Layer 2 Encapsulation<\/td><td class=\"column-2\">-<\/td><td class=\"column-3\">-<\/td><td class=\"column-4\">VXLAN (FastDP), eigenes Tunnel Protokoll (Sleeve)<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-21\">\n\t<td class=\"column-1\">Layer 3 Encapsulation<\/td><td class=\"column-2\">IP-in-IP, VXLAN<\/td><td class=\"column-3\">VXLAN, Geneve<\/td><td class=\"column-4\">-<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-22\">\n\t<td class=\"column-1\">Nutzung ohne Encapsulation<\/td><td class=\"column-2\">ja, natives Routing mit autom. Konfiguration (BGP)<\/td><td class=\"column-3\">ja, natives Routing mit manueller Konfiguration<\/td><td class=\"column-4\">nein, da knoten\u009f\u00fcberspannendes LAN (Layer 2)<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-23\">\n\t<td class=\"column-1\">Standard-Konnektivit\u008a\u00e4t<\/td><td class=\"column-2\">L3 Overlay mit IP-in-IP Encapsulation<\/td><td class=\"column-3\">L3 Overlay mit VXLAN Encapsulation<\/td><td class=\"column-4\">L2 Overlay; knotenindividuell, vorzugsweise FastDP mit VXLAN Encapsulation<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-24\">\n\t<td class=\"column-1\">Umsetzung Routing<\/td><td class=\"column-2\">Linux Kernel Routing, (alternativ extended Berkeley Packet Filter (eBPF) als \"Tech Preview\")<\/td><td class=\"column-3\">extended Berkeley Packet Filter (eBPF)<\/td><td class=\"column-4\">Weave Router selbstlernend (FIB) \/ Open vSwitch<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-25\">\n\t<td class=\"column-1\">Standard MTU<\/td><td class=\"column-2\">1480 Bytes (IP-in-IP)<\/td><td class=\"column-3\">1450 Bytes (\u009fVXLAN, \u00fcber Route in Workloads)<\/td><td class=\"column-4\">1376 Bytes (FastDP)<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-26\">\n\t<td class=\"column-1\">Key-Value Store \/ Datastore<\/td><td class=\"column-2\">Kubernetes etcd \/ CRDs (bis 4000 Nodes), etcd<\/td><td class=\"column-3\">Kubernetes etcd \/ CRDs (bis 250 Nodes), etcd, consul<\/td><td class=\"column-4\">lokal pro Knoten (\/var\/lib\/weave\/weave-netdata.db)<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-27\">\n\t<td class=\"column-1\">Service Load Balancing<\/td><td class=\"column-2\">kube-proxy (intern), Propagieren der virtuellen ClusterIPs mittels BGP an externe Router mit Equal Cost MultiPath (extern), (eBPF anstelle von kube-proxy als \"Tech Preview\" (intern))<\/td><td class=\"column-3\">eBPF anstelle von kube-proxy (intern)<\/td><td class=\"column-4\">kube-proxy (intern)<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-28\">\n\t<td class=\"column-1\">Sicherheit<\/td><td class=\"column-2\"><\/td><td class=\"column-3\"><\/td><td class=\"column-4\"><\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-29\">\n\t<td class=\"column-1\">Kubernetes Network Policies<\/td><td class=\"column-2\">Ingress + Egress mit allen durch die Kubernetes API unterst\u009f\u00fctzten Funktionen<\/td><td class=\"column-3\">Ingress + Egress mit allen durch die Kubernetes API unterst\u009f\u00fctzten Funktionen<\/td><td class=\"column-4\">Ingress + Egress mit allen durch die Kubernetes API unterst\u009f\u00fctzten Funktionen<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-30\">\n\t<td class=\"column-1\">Eigene Network Policies<\/td><td class=\"column-2\">Anwendung auf Ingress + Egress Traffic oder beide mit den Aktionen Allow, Deny, Log, Pass und den Match-Kriterien nummerierte Ports, Portr\u008a\u00e4ume, benannte Ports; Protokolle: TCP, UDP, ICMP, SCTP, UDPlite, ICMPv6; ICMP Attribute; IP Versionen (v4, v6); IP oder CIDR; Label-Selektoren; Namespace-Selektoren; Service-Account-Selektoren. Au\u00dferdem Sortierung \/ Priorisierung von Regeln<\/td><td class=\"column-3\">Anwendung auf Ingress + Egress Traffic oder beide mit der Aktion Allow und den Match-Kriterien nummerierte Ports, Portr\u008a\u00e4ume, benannte Ports; Protokolle: TCP, UDP; IP oder CIDR; Label-Selektoren, Namespace-Selektoren, Services, Entities, DNS-Namen, andere Cluster (MultiCluster); HTTP Attribute, Kafka Attribute (beta), DNS Attribute; Service-Account-Selektoren. Au\u00dferdem CiliumClusterwideNetworkPolicy: non-namespaced und cluster-scoped, erm\u009a\u00f6glicht die Nutzung von Node-Selektoren<\/td><td class=\"column-4\">nein<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-31\">\n\t<td class=\"column-1\">Umsetzung Network Policies<\/td><td class=\"column-2\">iptables, (eBPF als \"Tech Preview\")<\/td><td class=\"column-3\">eBPF mit identit\u008a\u00e4tsbasiertem Ansatz<\/td><td class=\"column-4\">iptables<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<tr class=\"row-32\">\n\t<td class=\"column-1\">integrierte Verschl\u009f\u00fcsselung<\/td><td class=\"column-2\">(ja, WireGuard als \"Tech Preview\")<\/td><td class=\"column-3\">ja, IPSec (beta bei Nutzung mit Overlay)<\/td><td class=\"column-4\">ja, NaCi bei Sleeve, ESP (IPSec) bei FastDP<\/td><td class=\"column-5\"><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n","protected":false},"excerpt":{"rendered":"<p>Anwendungskomponenten, die mittels Kubernetes als Pods ausgef\u00fchrt werden, k\u00f6nnen \u00fcber mehrere Knoten eines Clusters verteilt sein.\u00a0 Die knoten\u00fcbergreifende Netzwerkkommunikation stellt daher eine besondere Herausforderung dar. Aufgrund der Vielzahl unterschiedlicher Netzwerkumgebungen stellt Kubernetes zwar grundlegende Anforderungen an Netzwerkimplementierungen, setzt diese selbst aber nicht um. Stattdessen wird auf eine verbreitete Spezifikation, das Container Network Interface (CNI), f\u00fcr [&hellip;]<\/p>\n","protected":false},"author":225,"featured_media":19029,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"ep_exclude_from_search":false,"footnotes":""},"tags":[71],"service":[414,423],"coauthors":[{"id":225,"display_name":"Simon Kurth","user_nicename":"skurth"}],"class_list":["post-18953","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-cloud","service-cloud","service-kubernetes"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.6 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Kubernetes Networking Teil 2: Vergleich von (CNI) Netzwerk-Plugins - inovex GmbH<\/title>\n<meta name=\"description\" content=\"Nachdem wir uns im ersten Teil dieser Serie mit den Grundlagen des Container- und Kubernetes Networkings befasst haben, schauen wir uns in diesem Teil die CNI-kompatiblen Plug-Ins Project Calico, Cilium und Weave Net konkret an und vergleichen sie.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Kubernetes Networking Teil 2: Vergleich von (CNI) Netzwerk-Plugins - inovex GmbH\" \/>\n<meta property=\"og:description\" content=\"Nachdem wir uns im ersten Teil dieser Serie mit den Grundlagen des Container- und Kubernetes Networkings befasst haben, schauen wir uns in diesem Teil die CNI-kompatiblen Plug-Ins Project Calico, Cilium und Weave Net konkret an und vergleichen sie.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/\" \/>\n<meta property=\"og:site_name\" content=\"inovex GmbH\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/inovexde\" \/>\n<meta property=\"article:published_time\" content=\"2020-06-26T06:13:25+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2024-02-19T07:13:13+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/06\/Kubernetes-Networking-102.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1920\" \/>\n\t<meta property=\"og:image:height\" content=\"1080\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Simon Kurth\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/06\/Kubernetes-Networking-102-1024x576.png\" \/>\n<meta name=\"twitter:creator\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:site\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:label1\" content=\"Verfasst von\" \/>\n\t<meta name=\"twitter:data1\" content=\"Simon Kurth\" \/>\n\t<meta name=\"twitter:label2\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data2\" content=\"21\u00a0Minuten\" \/>\n\t<meta name=\"twitter:label3\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data3\" content=\"Simon Kurth\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-2-calico-cilium-weavenet\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-2-calico-cilium-weavenet\\\/\"},\"author\":{\"name\":\"Simon Kurth\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/person\\\/9d07667a11a6a36956e82ca902ba3bb4\"},\"headline\":\"Kubernetes Networking Teil 2: Vergleich von (CNI) Netzwerk-Plugins\",\"datePublished\":\"2020-06-26T06:13:25+00:00\",\"dateModified\":\"2024-02-19T07:13:13+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-2-calico-cilium-weavenet\\\/\"},\"wordCount\":4207,\"commentCount\":4,\"publisher\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-2-calico-cilium-weavenet\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2020\\\/06\\\/Kubernetes-Networking-102.png\",\"keywords\":[\"Cloud\"],\"articleSection\":[\"General\",\"Infrastructure\"],\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-2-calico-cilium-weavenet\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-2-calico-cilium-weavenet\\\/\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-2-calico-cilium-weavenet\\\/\",\"name\":\"Kubernetes Networking Teil 2: Vergleich von (CNI) Netzwerk-Plugins - inovex GmbH\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-2-calico-cilium-weavenet\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-2-calico-cilium-weavenet\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2020\\\/06\\\/Kubernetes-Networking-102.png\",\"datePublished\":\"2020-06-26T06:13:25+00:00\",\"dateModified\":\"2024-02-19T07:13:13+00:00\",\"description\":\"Nachdem wir uns im ersten Teil dieser Serie mit den Grundlagen des Container- und Kubernetes Networkings befasst haben, schauen wir uns in diesem Teil die CNI-kompatiblen Plug-Ins Project Calico, Cilium und Weave Net konkret an und vergleichen sie.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-2-calico-cilium-weavenet\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-2-calico-cilium-weavenet\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-2-calico-cilium-weavenet\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2020\\\/06\\\/Kubernetes-Networking-102.png\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2020\\\/06\\\/Kubernetes-Networking-102.png\",\"width\":1920,\"height\":1080,\"caption\":\"Kubernetes Networking 102 with the Kubernetes Logo as the 0\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-2-calico-cilium-weavenet\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Kubernetes Networking Teil 2: Vergleich von (CNI) Netzwerk-Plugins\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#website\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\",\"name\":\"inovex GmbH\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\",\"name\":\"inovex GmbH\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2021\\\/03\\\/inovex-logo-16-9-1.png\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2021\\\/03\\\/inovex-logo-16-9-1.png\",\"width\":1921,\"height\":1081,\"caption\":\"inovex GmbH\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/inovexde\",\"https:\\\/\\\/x.com\\\/inovexgmbh\",\"https:\\\/\\\/www.instagram.com\\\/inovexlife\\\/\",\"https:\\\/\\\/www.linkedin.com\\\/company\\\/inovex\",\"https:\\\/\\\/www.youtube.com\\\/channel\\\/UC7r66GT14hROB_RQsQBAQUQ\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/person\\\/9d07667a11a6a36956e82ca902ba3bb4\",\"name\":\"Simon Kurth\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/9c119d9425a0a9e26175d2e20a54d1a6c3cfe00588a1c5ca38f21b034f7e9308?s=96&d=retro&r=gd7e7b8834f50eac596c199b4a3b9a97c\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/9c119d9425a0a9e26175d2e20a54d1a6c3cfe00588a1c5ca38f21b034f7e9308?s=96&d=retro&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/9c119d9425a0a9e26175d2e20a54d1a6c3cfe00588a1c5ca38f21b034f7e9308?s=96&d=retro&r=g\",\"caption\":\"Simon Kurth\"},\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/author\\\/skurth\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Kubernetes Networking Teil 2: Vergleich von (CNI) Netzwerk-Plugins - inovex GmbH","description":"Nachdem wir uns im ersten Teil dieser Serie mit den Grundlagen des Container- und Kubernetes Networkings befasst haben, schauen wir uns in diesem Teil die CNI-kompatiblen Plug-Ins Project Calico, Cilium und Weave Net konkret an und vergleichen sie.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/","og_locale":"de_DE","og_type":"article","og_title":"Kubernetes Networking Teil 2: Vergleich von (CNI) Netzwerk-Plugins - inovex GmbH","og_description":"Nachdem wir uns im ersten Teil dieser Serie mit den Grundlagen des Container- und Kubernetes Networkings befasst haben, schauen wir uns in diesem Teil die CNI-kompatiblen Plug-Ins Project Calico, Cilium und Weave Net konkret an und vergleichen sie.","og_url":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/","og_site_name":"inovex GmbH","article_publisher":"https:\/\/www.facebook.com\/inovexde","article_published_time":"2020-06-26T06:13:25+00:00","article_modified_time":"2024-02-19T07:13:13+00:00","og_image":[{"width":1920,"height":1080,"url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/06\/Kubernetes-Networking-102.png","type":"image\/png"}],"author":"Simon Kurth","twitter_card":"summary_large_image","twitter_image":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/06\/Kubernetes-Networking-102-1024x576.png","twitter_creator":"@inovexgmbh","twitter_site":"@inovexgmbh","twitter_misc":{"Verfasst von":"Simon Kurth","Gesch\u00e4tzte Lesezeit":"21\u00a0Minuten","Written by":"Simon Kurth"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#article","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/"},"author":{"name":"Simon Kurth","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/9d07667a11a6a36956e82ca902ba3bb4"},"headline":"Kubernetes Networking Teil 2: Vergleich von (CNI) Netzwerk-Plugins","datePublished":"2020-06-26T06:13:25+00:00","dateModified":"2024-02-19T07:13:13+00:00","mainEntityOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/"},"wordCount":4207,"commentCount":4,"publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/06\/Kubernetes-Networking-102.png","keywords":["Cloud"],"articleSection":["General","Infrastructure"],"inLanguage":"de","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/","url":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/","name":"Kubernetes Networking Teil 2: Vergleich von (CNI) Netzwerk-Plugins - inovex GmbH","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#primaryimage"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/06\/Kubernetes-Networking-102.png","datePublished":"2020-06-26T06:13:25+00:00","dateModified":"2024-02-19T07:13:13+00:00","description":"Nachdem wir uns im ersten Teil dieser Serie mit den Grundlagen des Container- und Kubernetes Networkings befasst haben, schauen wir uns in diesem Teil die CNI-kompatiblen Plug-Ins Project Calico, Cilium und Weave Net konkret an und vergleichen sie.","breadcrumb":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#primaryimage","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/06\/Kubernetes-Networking-102.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/06\/Kubernetes-Networking-102.png","width":1920,"height":1080,"caption":"Kubernetes Networking 102 with the Kubernetes Logo as the 0"},{"@type":"BreadcrumbList","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-2-calico-cilium-weavenet\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.inovex.de\/de\/"},{"@type":"ListItem","position":2,"name":"Kubernetes Networking Teil 2: Vergleich von (CNI) Netzwerk-Plugins"}]},{"@type":"WebSite","@id":"https:\/\/www.inovex.de\/de\/#website","url":"https:\/\/www.inovex.de\/de\/","name":"inovex GmbH","description":"","publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.inovex.de\/de\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":"Organization","@id":"https:\/\/www.inovex.de\/de\/#organization","name":"inovex GmbH","url":"https:\/\/www.inovex.de\/de\/","logo":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","width":1921,"height":1081,"caption":"inovex GmbH"},"image":{"@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/inovexde","https:\/\/x.com\/inovexgmbh","https:\/\/www.instagram.com\/inovexlife\/","https:\/\/www.linkedin.com\/company\/inovex","https:\/\/www.youtube.com\/channel\/UC7r66GT14hROB_RQsQBAQUQ"]},{"@type":"Person","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/9d07667a11a6a36956e82ca902ba3bb4","name":"Simon Kurth","image":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/secure.gravatar.com\/avatar\/9c119d9425a0a9e26175d2e20a54d1a6c3cfe00588a1c5ca38f21b034f7e9308?s=96&d=retro&r=gd7e7b8834f50eac596c199b4a3b9a97c","url":"https:\/\/secure.gravatar.com\/avatar\/9c119d9425a0a9e26175d2e20a54d1a6c3cfe00588a1c5ca38f21b034f7e9308?s=96&d=retro&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/9c119d9425a0a9e26175d2e20a54d1a6c3cfe00588a1c5ca38f21b034f7e9308?s=96&d=retro&r=g","caption":"Simon Kurth"},"url":"https:\/\/www.inovex.de\/de\/blog\/author\/skurth\/"}]}},"_links":{"self":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/18953","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/users\/225"}],"replies":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/comments?post=18953"}],"version-history":[{"count":3,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/18953\/revisions"}],"predecessor-version":[{"id":51843,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/18953\/revisions\/51843"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media\/19029"}],"wp:attachment":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media?parent=18953"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/tags?post=18953"},{"taxonomy":"service","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/service?post=18953"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/coauthors?post=18953"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}