{"id":18938,"date":"2020-06-19T12:32:45","date_gmt":"2020-06-19T10:32:45","guid":{"rendered":"https:\/\/www.inovex.de\/blog\/?p=18938"},"modified":"2024-02-19T08:13:14","modified_gmt":"2024-02-19T07:13:14","slug":"kubernetes-networking-1-essentials","status":"publish","type":"post","link":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/","title":{"rendered":"Kubernetes Networking Teil 1: Networking Essentials"},"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. 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 <a href=\"https:\/\/github.com\/containernetworking\/cni\">Container Network Interface<\/a> (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>Der erste Teil dieser Serie befasst sich mit den Grundlagen des Container Networkings am Beispiel Docker. Wir nutzen diese zum Verst\u00e4ndnis der internen Netzwerkmechanismen von Kubernetes sowie der Funktionsweise eines \u201ePodnetzwerks\u201c. Au\u00dferdem geht der Artikel der Frage nach, wof\u00fcr wir ein Kubernetes Netzwerk Plugin \u00fcberhaupt ben\u00f6tigen. Der zweite Teil beleuchtet die Netzwerk-Plugins <a href=\"https:\/\/www.projectcalico.org\/\">Project Calico<\/a>, <a href=\"https:\/\/cilium.io\/\">Cilium<\/a> und Weave Net und stellt ihre grundlegenden Funktionsweisen und Unterschiede heraus. Am Ende dieser Artikelserie solltet ihr einen \u00dcberblick \u00fcber die Grundkonzepte des Kubernetes Networkings erhalten und Kriterien aufgezeigt bekommen haben, nach denen ihr das f\u00fcr eure Begebenheiten am besten geeignetste Kubernetes-Netzwerk-Plugin ausw\u00e4hlen k\u00f6nnt.<!--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-1-essentials\/#Grundlagen-des-Container-Networkings\" >Grundlagen des Container Networkings<\/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-1-essentials\/#Das-Kubernetes-Netzwerkmodell\" >Das Kubernetes-Netzwerkmodell<\/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-1-essentials\/#Das-Container-Network-Interface-CNI\" >Das Container Network Interface (CNI)<\/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-1-essentials\/#Installation-von-Kubernetes-Netzwerk-Plugins\" >Installation von Kubernetes Netzwerk-Plugins<\/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-1-essentials\/#Zusammenfassung\" >Zusammenfassung<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"Grundlagen-des-Container-Networkings\"><\/span>Grundlagen des Container Networkings<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Standardm\u00e4\u00dfig operieren Docker Container im Bridge-Modus. Die folgende Abbildung veranschaulicht ein klassisches Szenario, bei dem zwei Docker Container in einem gemeinsamen Bridge-Netzwerk gestartet werden.<\/p>\n<figure id=\"attachment_18940\" aria-describedby=\"caption-attachment-18940\" style=\"width: 426px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-18940\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Container-to-Container-Networking.png\" alt=\"\" width=\"426\" height=\"320\" \/><figcaption id=\"caption-attachment-18940\" class=\"wp-caption-text\">Abbildung 1 &#8211; Aufbau Docker Bridge Netzwerk<\/figcaption><\/figure>\n<p>Docker erzeugt dabei pro Netzwerk eine virtuelle Linux Bridge, initial mit der Bezeichnung <span class=\"lang:default decode:true crayon-inline\">docker0<\/span>, die nach au\u00dfen mittels Linux Kernel Routing \u00fcber die physische Schnittstelle des Hosts (<span class=\"lang:default decode:true crayon-inline\">eth0<\/span>) kommunizieren kann. Intern spannt sie \u00a0einen eigenen Adressraum in Form eines Subnetzes auf. Die Container werden jeweils \u00fcber ein <span class=\"lang:default decode:true crayon-inline\">veth<\/span>-Paar an die Bridge angeschlossen. Das Paar fungiert wie eine virtuelle Punkt-zu-Punkt-Ethernetverbindung und verbindet die Network Namespaces der Container mit dem Network Namespace des Hosts. Die Kommunikation zwischen den Containern verl\u00e4uft innerhalb eines Docker-Bridge-Netzwerks \u00fcber die entsprechende Bridge \u2013 vorausgesetzt die IP-Adresse beziehungsweise der Hostname des Zielcontainers ist bekannt. Da beide Container in einem eigenen Network Namespace ausgef\u00fchrt werden, besitzen sie individuelle Routing-Tabellen, Schnittstellen und <span class=\"lang:default decode:true crayon-inline\">iptables<\/span>-Regeln.<\/p>\n<p>Startet man hingegen einen Docker Container mit der Option <span class=\"lang:default decode:true crayon-inline\">&#8211;net=container:&lt;container-name&gt;<\/span>, wobei <span class=\"lang:default decode:true crayon-inline \">&lt;container-name&gt;<\/span>\u00a0dem Namen eines bereits ausgef\u00fchrten Containers entspricht, wird der neue Container an die virtuelle Netzwerkschnittstelle des vorhandenen Containers angebunden. Beide Container befinden sich nun im selben Netzwerk Namespace und teilen sich denselben Netzwerkstack.\u00a0 Eine Kommunikation ist daher \u00fcber <span class=\"lang:default decode:true crayon-inline\">localhost<\/span>\u00a0m\u00f6glich. Genau dieses Konzept macht sich Kubernetes f\u00fcr die Kommunikation zwischen Containern innerhalb eines Pods zu Nutze. Zur Erinnerung: Ein Pod kann aus mehreren Containern (meistens ein Hauptcontainer mit einem oder mehreren Sidecar Containern) bestehen. \u00a0Wird nun auf Container 1 ein Webserver auf Port 8080 betrieben, ist dieser von Container 2 \u00fcber <span class=\"lang:default decode:true crayon-inline\">http:\/\/localhost:8080<\/span>\u00a0erreichbar, obwohl er den Prozess selbst nicht ausf\u00fchrt. Man spricht im Kontext von Kubernetes von der <strong>Container-to-Container-Kommunikation<\/strong>. Abbildung 2 veranschaulicht diesen Aufbau.<\/p>\n<figure id=\"attachment_18946\" aria-describedby=\"caption-attachment-18946\" style=\"width: 319px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-18946\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Container-to-Container-Networking_2_neu.png\" alt=\"\" width=\"319\" height=\"320\" srcset=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Container-to-Container-Networking_2_neu.png 662w, https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Container-to-Container-Networking_2_neu-300x300.png 300w, https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Container-to-Container-Networking_2_neu-150x150.png 150w, https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Container-to-Container-Networking_2_neu-400x401.png 400w, https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Container-to-Container-Networking_2_neu-650x650.png 650w, https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Container-to-Container-Networking_2_neu-360x361.png 360w\" sizes=\"auto, (max-width: 319px) 100vw, 319px\" \/><figcaption id=\"caption-attachment-18946\" class=\"wp-caption-text\">Abbildung 2 &#8211; Docker Container Mode<\/figcaption><\/figure>\n<p>Innerhalb eines Kubernetes Pods besteht nun gegen\u00fcber Abbildung 2 lediglich die Besonderheit, dass unabh\u00e4ngig von den \u201eNutzcontainern\u201c zus\u00e4tzlich ein <span class=\"lang:default decode:true crayon-inline\">pause<\/span>-Container existiert, der den Network Namespace einschlie\u00dflich der Netzwerkschnittstelle initial erzeugt und aufrechterh\u00e4lt. Sollten alle Nutzcontainer ausfallen, bleibt der Pod und somit der Namespace trotzdem bestehen, sodass die Container ihm sp\u00e4ter wieder hinzugef\u00fcgt werden k\u00f6nnen.<\/p>\n<figure id=\"attachment_18942\" aria-describedby=\"caption-attachment-18942\" style=\"width: 311px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-18942\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Container-to-Container-Networking_3_neu.png\" alt=\"\" width=\"311\" height=\"320\" srcset=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Container-to-Container-Networking_3_neu.png 664w, https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Container-to-Container-Networking_3_neu-291x300.png 291w, https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Container-to-Container-Networking_3_neu-400x412.png 400w, https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Container-to-Container-Networking_3_neu-360x371.png 360w\" sizes=\"auto, (max-width: 311px) 100vw, 311px\" \/><figcaption id=\"caption-attachment-18942\" class=\"wp-caption-text\">Abbildung 3 &#8211; Aufbau Kubernetes Pod<\/figcaption><\/figure>\n<p>Der in Abbildung 3 dargestellte Aufbau kann z.B. bei der Verwendung von <a href=\"https:\/\/github.com\/kubernetes\/minikube\">minikube<\/a> mit Docker als Container Runtime nachvollzogen werden. Existieren weitere Pods werden diese nach demselben Schema \u00fcber weitere <span class=\"lang:default decode:true crayon-inline\">veth<\/span>-Paare an die Bridge angeschlossen. Je nach Container Runtime und verwendeten Netzwerk-Plugins bei Multi-Node-Clustern kann dieser Aufbau jedoch variieren, wie wir im zweiten Teil dieser Serie noch feststellen werden. Dennoch bietet er eine gute Grundlage zum Verst\u00e4ndnis der knotenlokalen Netzwerkmechanismen \u2013 insbesondere dann, wenn man sich vor dem Einstieg in Kubernetes bereits mit Docker befasst hat.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Das-Kubernetes-Netzwerkmodell\"><\/span>Das Kubernetes-Netzwerkmodell<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Nachdem wir uns bis hier hin darauf beschr\u00e4nkt haben, wie das Networking zwischen Containern <em>innerhalb\u00a0<\/em>eines Pods erfolgt, begeben wir uns nun eine Abstraktionsebene h\u00f6her und besch\u00e4ftigen uns mit der Kommunikation zwischen Pods. Hierzu stellen wir uns eine simple Webapplikation vor, bestehend aus Frontend und Backend. Zur Erinnerung: Weil beide Komponenten v\u00f6llig unterschiedliche Beschaffenheiten aufweisen (zustandslos vs. zustandsbehaftet), w\u00fcrde man sie als separate Pods ausf\u00fchren, um sie auch getrennt voneinander skalieren zu k\u00f6nnen. Damit die Webapplikation ordnungsgem\u00e4\u00df funktioniert, m\u00fcssen diese Pods stets miteinander kommunizieren k\u00f6nnen \u2013 unabh\u00e4ngig davon, auf welchen Knoten sie ausgef\u00fchrt werden. Mit der <strong>Pod-to-Pod-Kommunikation<\/strong> gilt es somit sicherzustellen, dass sowohl Pods eines einzigen Knotens als auch Pods unterschiedlicher, auch topologisch entfernter Knoten, stets eine Netzwerkverbindung zueinander aufbauen und Daten austauschen k\u00f6nnen. Schlie\u00dflich soll Kubernetes die Workloads m\u00f6glichst gleichm\u00e4\u00dfig \u00fcber die verf\u00fcgbaren Knoten verteilen, aber zugleich die zugrundeliegenden Hardwareressourcen abstrahieren. F\u00fcr den Entwickler einer Applikation soll es bei der Nutzung von Kubernetes also nicht von Interesse sein, ob Frontend und Backend Pods auf demselben oder auf unterschiedlichen Knoten ausgef\u00fchrt werden. Die Pod-to-Pod-Kommunikation wird wie folgt umgesetzt:<\/p>\n<p>Jeder Pod in Kubernetes erh\u00e4lt eine eindeutige IP-Adresse, die eine clusterweite G\u00fcltigkeit besitzt. Dar\u00fcber hinaus stellt Kubernetes die Anforderung, dass innerhalb eines Clusters alle Pods eines Knotens mit allen Pods anderer Knoten ohne Network Address Translation (NAT) kommunizieren k\u00f6nnen. Dies soll die Kommunikation zwischen Anwendungskomponenten vereinfachen und jeden Pod clusterweit \u00fcber die IP-Adresse erreichbar machen, die auch seiner virtuellen Netzwerkschnittstelle zugeordnet ist.<\/p>\n<p>Was bei der Kommunikation zwischen knotenlokalen Pods bei der Verwendung einer gemeinsamen virtuellen Linux Bridge (L2) bereits implizit erf\u00fcllt ist \u2013 wir erinnern uns an die Ausf\u00fchrungen rund um Abbildung 3 \u2013 stellt sich knoten\u00fcbergreifend als komplexer dar: Zum einen muss ein IP-Address-Management (IPAM) stattfinden, damit IP-Adressen innerhalb eines Clusters nicht mehrfach vergeben werden und Konflikte auftreten. Zum anderen m\u00fcssen die lokalen Bridge-Netzwerke aller Knoten miteinander verbunden werden, damit eine Kommunikation auch knoten\u00fcbergreifend stattfinden kann.<\/p>\n<p>F\u00fcr die Implementierung eines Podnetzwerks nach den genannten Anforderungen existieren mehrere M\u00f6glichkeiten: Sie kann entweder manuell durch einen Administrator erfolgen oder von einer an das Kubelet angebundenen, externen Komponente \u2013 dem Netzwerk Plugin \u2013 \u00fcbernommen werden. Zur Erinnerung: Das Kubelet bildet die prim\u00e4re Schnittstelle zwischen der Kubernetes API und der lokalen Container Runtime und wird auf jedem Knoten als Agent ausgef\u00fchrt. Aus netzwerktechnischer Sicht kann die knoten\u00fcbergreifende Kommunikation auf Layer 2 (Switching), Layer 3 (Routing) oder durch ein Overlay-Netzwerk realisiert werden.<\/p>\n<p>Eine m\u00f6gliche Implementierung eines Podnetzwerks k\u00f6nnte wie folgt aussehen:<\/p>\n<figure id=\"attachment_18943\" aria-describedby=\"caption-attachment-18943\" style=\"width: 800px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-18943\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Pod-to-Pod-Networking.png\" alt=\"\" width=\"800\" height=\"473\" \/><figcaption id=\"caption-attachment-18943\" class=\"wp-caption-text\">Abbildung 4 &#8211; M\u00f6gliche Umsetzung eines Podnetzwerks<\/figcaption><\/figure>\n<p>Hierbei werden die beiden knotenlokalen Bridges \u00fcber die Implementierung von simplen Routingegeln miteinander verbunden: Daf\u00fcr sind die Routing-Tabellen der Knoten jeweils so einzurichten, dass sie die internen Bridge-Netzwerke aller anderen Knoten beinhalten und als Next-Hop auf die physische Schnittstelle des jeweiligen Knotens verweisen. Ebenso muss eine Route f\u00fcr das eigene Bridge-Netzwerk vorhanden sein, damit von extern eingehender, ebenso wie lokal initiierter Datenverkehr (z.B. durch einen Pod, der im Hostmodus betrieben wird) an die eigenen Pods, intern an die entsprechende virtuelle Bridge weitergeleitet wird.<\/p>\n<p>Die Abbildung veranschaulicht die Initiierung eines Datenpakets durch Kubernetes Pod 2 und die \u00dcbertragung \u00fcber die physische Verbindung zwischen Node A und Node B an Pod 3. Die virtuellen Ethernet-Paare (<span class=\"lang:default decode:true crayon-inline\">veth<\/span>-Paare) bilden hierbei eine logische Verbindung zwischen Network Namespace des Pods und Network Namespace des Hostsystems. Im Falle eines Switched Netzwerks (L2) k\u00f6nnen beide Knoten \u00fcber ARP und ihre MAC-Adressen direkt miteinander kommunizieren. Bef\u00e4nde sich ein Router zwischen Node A und Node B (L3) m\u00fcssten diesem die jeweiligen knotenlokalen Bridge-Netzwerke \u00fcber entsprechende Routen bekannt gemacht werden.<\/p>\n<p>Zusammengefasst erf\u00fcllt das in Abbildung 4 dargestellte Podnetzwerk alle durch Kubernetes formulierten Anforderungen: Pods k\u00f6nnen mit allen lokalen und nicht-lokalen Pods sowie allen Knoten ohne NAT kommunizieren. Alle Knoten (beziehungsweise darauf ausgef\u00fchrte Prozesse) k\u00f6nnen mit lokalen und nicht-lokalen Pods sowie allen anderen Knoten ohne NAT kommunizieren. Sobald jedoch an einen anderen Pod gerichtete Datenpakete Router \u00f6ffentlicher Netze passieren, werden diese aufgrund ihrer aus einem privaten Adressbereich stammenden Ziel-IP-Adresse verworfen. Folglich ist die dargestellte Implementierung nur dann praktikabel, wenn alle Knoten \u00fcber einen Switch direkt miteinander verbunden sind beziehungsweise es sich um ein privates Netz handelt, in dem eventuell zwischengeschaltete Router konfiguriert werden k\u00f6nnen. Andernfalls w\u00e4re wiederum die Verwendung von NAT erforderlich, um die privaten Adressen zu maskieren und die Datenpakete auch \u00f6ffentlich routen zu k\u00f6nnen. Hier kommen Tunnelprotokolle beziehungsweise Overlays ins Spiel, die sich \u00fcber Netzwerk-Plugins in ein Kubernetes Cluster einbinden lassen. Selbst jedoch in lokalen Netzwerken, in denen Tunnelprotokolle nicht notwendig sind, ist die manuelle Netzwerkkonfiguration von mehreren Knoten und Pods, wie sie mit Abbildung 4 verdeutlicht wird, kaum handhabbar. Diese Arbeit \u00fcbernehmen und automatisieren Netzwerk-Plugins.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Das-Container-Network-Interface-CNI\"><\/span>Das Container Network Interface (CNI)<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Das Container Network Interface wurde urspr\u00fcnglich von CoreOS (heute Teil von RedHat) im Zusammenhang mit der Container Runtime rkt entwickelt. Ziel war die Definition einer gemeinsamen Schnittstelle zwischen Netzwerk-Plugins und Container Runtime beziehungsweise Orchestrator. Mittlerweile ist CNI bei Orchestratoren weit verbreitet \u2013 mit der Ausnahme von Docker Swarm (hier wird die Docker-eigene L\u00f6sung libnetwork eingesetzt) \u2013 was in einer Vielzahl kompatibler Plugins von Drittanbietern resultiert.<\/p>\n<p>CNI besteht aus einer Spezifikation sowie Bibliotheken f\u00fcr die Entwicklung von Plugins, die Netzwerkschnittstellen in Linux Containern konfigurieren. Au\u00dferdem liefert das CNI Projekt bereits einige kompatible <a href=\"https:\/\/github.com\/containernetworking\/plugins\">\u201eCore\u201c Plugins<\/a> mit, die Grundfunktionalit\u00e4ten umsetzen \u2013 etwa das Erzeugen einer Linux Bridge und das Anbinden von Host und Container an diese. CNI befasst sich ausschlie\u00dflich mit der Netzwerkkonnektivit\u00e4t von Containern sowie der Freigabe von allokierten Ressourcen (z.B. IP-Adressen) nach dem L\u00f6schen von Containern (Garbage Collection) und ist daher leichtgewichtig und einfach zu implementieren. Neben Kubernetes wird CNI unter anderem auch durch OpenShift, Cloud Foundry, Apache Mesos oder Amazon ECS eingesetzt<\/p>\n<p>F\u00fcr ein besseres Verst\u00e4ndnis von CNI lohnt es sich, bestimmte Ausschnitte der <a href=\"https:\/\/github.com\/containernetworking\/cni\/blob\/master\/SPEC.md\">Spezifikation<\/a>\u00a0 genauer zu betrachten: Demnach muss ein CNI-Plugin als ausf\u00fchrbare Datei (executable) bereitgestellt werden, die durch das Containermanagementsystem (im Fall von Kubernetes mit Docker durch das Kubelet) nach der Erzeugung des Network Namespaces eines neuen Containers aufgerufen wird (<span class=\"lang:default decode:true crayon-inline\">ADD<\/span>-Operation). Anschlie\u00dfend muss das Plugin f\u00fcr das Hinzuf\u00fcgen einer Netzwerkschnittstelle innerhalb des Container Network Namespaces (angelehnt an unser Beispiel aus Abbildung 4 das containerseitige Ende des <span class=\"lang:default decode:true crayon-inline\">veth<\/span>-Paares) sorgen und auf dem Host alle zur Herstellung der Konnektivit\u00e4t erforderlichen Ma\u00dfnahmen vornehmen (in unserem Beispiel die Verbindung des anderen Endes des <span class=\"lang:default decode:true crayon-inline\">veth<\/span>-Paares mit einer Linux Bridge). Im Anschluss ist daf\u00fcr Sorge zu tragen, dass der erzeugten Schnittstelle eine IP-Adresse zugewiesen wird und relevante Routen konsistent mit dem IP-Adressmanagement (IPAM) konfiguriert werden, wof\u00fcr ein entsprechendes IPAM Plugin aufgerufen wird. Laut Spezifikation \u00a0m\u00fcssen die folgenden Operationen implementiert werden:<\/p>\n<ul style=\"list-style-type: square;\">\n<li><span class=\"lang:default decode:true crayon-inline\">ADD<\/span><strong>\u00a0<\/strong>(Container zu einem Netzwerk hinzuf\u00fcgen),<\/li>\n<li><span class=\"lang:default decode:true crayon-inline \">DEL<\/span>\u00a0\u00a0(Container von einem Netzwerk l\u00f6schen),<\/li>\n<li><span class=\"lang:default decode:true crayon-inline\">CHECK<\/span><strong>\u00a0<\/strong>(\u00dcberpr\u00fcfung der Konnektivit\u00e4t) und<\/li>\n<li><span class=\"lang:default decode:true crayon-inline \">VERSION<\/span>\u00a0\u00a0(R\u00fcckgabe der durch das Plugin unterst\u00fctzten CNI-Versionen)<\/li>\n<\/ul>\n<p>Die Konfiguration eines Plugins muss zudem \u00fcber eine JSON-Datei erfolgen. Weitere Einzelheiten werden hier nicht weiter ausgef\u00fchrt und k\u00f6nnen der <a href=\"https:\/\/github.com\/containernetworking\/cni\/blob\/master\/SPEC.md\">Spezifikation<\/a> direkt entnommen werden.<\/p>\n<p>Praktisch dargestellt lie\u00dfe sich ein CNI-konformes Plugin mit einem Bash Script realisieren, das die vier aufgezeigten Operationen in Form von parametrisierten Funktionen implementiert und sich den verf\u00fcgbaren CLI-Kommandos wie <span class=\"lang:default decode:true crayon-inline \">$ ip link<\/span>\u00a0oder <span class=\"lang:default decode:true crayon-inline \">$ ip route add<\/span>\u00a0bedient, um Schnittstellen zu erstellen und zu konfigurieren beziehungsweise Routing-Regeln zu erzeugen.<\/p>\n<p>Wir haben nun einen Blick in die Spezifikation geworfen und einen Eindruck erhalten, wie ein Netzwerk Plugin nach CNI-Vorgaben zu implementieren ist. Doch wie erfolgt die Implementierung von CNI innerhalb von Kubernetes? Aus der Sicht von Kubernetes in Verbindung mit Docker als Container Runtime (<a href=\"https:\/\/github.com\/kubernetes\/kubernetes\/tree\/release-1.19\/pkg\/kubelet\/dockershim\">Dockershim)<\/a> ist CNI <em>selbst<\/em> ein Netzwerk-Plugin. Es wird an das Kubelet pro Knoten angebunden, da das Kubelet f\u00fcr das Erzeugen und L\u00f6schen von Containern auf seinem jeweiligen Knoten zust\u00e4ndig ist. Ausgew\u00e4hlt wird ein Kubelet-Netzwerk-Plugin \u00fcber die Option <span class=\"lang:default decode:true crayon-inline\">&#8211;network-plugin=&lt;cni|kubenet&gt;<\/span>, wobei dies in der Regel implizit durch Installationstools wie kubeadm erfolgt. kubenet ist im \u00dcbrigen das Kubernetes \u201eBasis\u201c-Netzwerk-Plugin, das sich jedoch selbst der CNI Core Plugins bedient und in der Praxis kaum eine Relevanz hat. Werden \u00fcber das Container Runtime Interface (CRI) alternative Container Runtimes wie <a href=\"https:\/\/containerd.io\">containerd<\/a> oder <a href=\"https:\/\/cri-o.io\">CRI-O<\/a>\u00a0genutzt,\u00a0interagieren die Runtimes direkt mit dem CNI-Plugin, ohne dass zus\u00e4tzliche Aufrufe \u00fcber das Kubelet bzw. Dockershim notwendig sind.<\/p>\n<p>Im Falle von Docker als Container Runtime\u00a0muss ein an das Kubelet angebundenes Netzwerk-Plugin das Interface <span class=\"lang:default decode:true crayon-inline \">NetworkPlugin<\/span>\u00a0(<a href=\"https:\/\/github.com\/kubernetes\/kubernetes\/blob\/3446ffbb4a5328e88a75afc36a258c1f7adb1b89\/pkg\/kubelet\/dockershim\/network\/plugins.go#L54\">siehe GitHub<\/a>) implementieren, das unter anderem die Funktionen <span class=\"lang:default decode:true crayon-inline \">SetupPod()<\/span>\u00a0und <span class=\"lang:default decode:true crayon-inline \">TearDownPod()<\/span>\u00a0spezifiziert. Das Kubelet ruft die erste Funktion auf, nachdem ein <span class=\"lang:default decode:true crayon-inline\">pause<\/span>-Container und somit ein neuer Pod gestartet wurde. Die letzte Funktion wird aufgerufen, nachdem ein <span class=\"lang:default decode:true crayon-inline\">pause<\/span>-Container und somit ein bestehender Pod gel\u00f6scht wurde. Die CNI-Implementierung innerhalb von Dockershim nutzt die offizielle <a href=\"https:\/\/github.com\/containernetworking\/cni\/tree\/master\/libcni\">CNI-Bibliothek<\/a> zur Integration in Applikationen (<a href=\"https:\/\/github.com\/kubernetes\/kubernetes\/blob\/3446ffbb4a5328e88a75afc36a258c1f7adb1b89\/pkg\/kubelet\/dockershim\/network\/cni\/cni.go#L31\">siehe GitHub<\/a>). Grob skizziert sehen die Methodenaufrufe nach dem Erzeugen eines neuen Pods wie folgt aus:<\/p>\n<ol>\n<li>Das Kubelet f\u00fchrt die Funktion <span class=\"lang:default decode:true crayon-inline\">SetupPod()<\/span>\u00a0aus, durch die wiederum die Funktion <span class=\"lang:default decode:true crayon-inline\">addToNetwork()<\/span>\u00a0(<a href=\"https:\/\/github.com\/kubernetes\/kubernetes\/blob\/3446ffbb4a5328e88a75afc36a258c1f7adb1b89\/pkg\/kubelet\/dockershim\/network\/cni\/cni.go#L354\">siehe GitHub<\/a>) aufgerufen wird.<\/li>\n<li>Durch <span class=\"lang:default decode:true crayon-inline \">addToNetwork()<\/span>\u00a0wird <span class=\"lang:default decode:true crayon-inline \">addNetworkList()<\/span>\u00a0aus der importierten CNI Library genutzt. Sie f\u00fchrt innerhalb der Library <span class=\"lang:default decode:true crayon-inline \">addNetwork()<\/span>\u00a0(<a href=\"https:\/\/github.com\/containernetworking\/cni\/blob\/77436456f2ab8443ba0450d61b1499bd50e8a704\/libcni\/api.go#L400\">siehe GitHub<\/a>) aus.<\/li>\n<li>Final wird das bereitgestellte CNI-kompatible Plugin innerhalb von <span class=\"lang:default decode:true crayon-inline \">addNetwork()<\/span>\u00a0mit der Operation <span class=\"lang:default decode:true crayon-inline \">ADD<\/span>\u00a0\u00a0aufgerufen (<a href=\"https:\/\/github.com\/containernetworking\/cni\/blob\/77436456f2ab8443ba0450d61b1499bd50e8a704\/libcni\/api.go#L421\">siehe GitHub<\/a>).<\/li>\n<\/ol>\n<p>Demnach ist CNI durch die Implementierung von <span class=\"lang:default decode:true crayon-inline\">NetworkPlugin<\/span>\u00a0einerseits ein Kubelet-Netzwerk-Plugin, andererseits ein \u201eLastenheft\u201c (im Sinne der erw\u00e4hnten Spezifikation) f\u00fcr Netzwerk-Plugins von Drittanbietern wie etwa Weave Net, das beschreibt, welche Merkmale die durch das Kubelet ausgel\u00f6sten Operationen aufzuweisen haben.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Installation-von-Kubernetes-Netzwerk-Plugins\"><\/span>Installation von Kubernetes Netzwerk-Plugins<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Bevor wir im Detail in die Netzwerk-Plugins einsteigen, bleibt zu kl\u00e4ren, wie deren Installation in einem Kubernetes Cluster erfolgt. In der Regel wird durch das jeweilige Projekt ein YAML-Manifest mit allen ben\u00f6tigten Kubernetes Ressourcen bereitgestellt, die lediglich mit <span class=\"lang:default decode:true crayon-inline \">$ kubectl create -f<\/span>\u00a0im Cluster erzeugt werden m\u00fcssen. Denn neben der CNI Binary, welche die Schnittstellenkonfiguration der Pods bei deren Erstellen oder L\u00f6schen vornimmt, sind je nach Funktionsumfang des Plugins weitere Komponenten notwendig \u2013 oftmals in Form eines oder mehrerer privilegierter Pods, die als DaemonSet auf jedem Knoten ausgef\u00fchrt werden. Sie beeinflussen die Netzwerkkonfiguration des Knotens oder k\u00f6nnen Traffic gar abgreifen und eigenst\u00e4ndig weiterleiten, um die knoten\u00fcbergreifende Kommunikation zwischen Pods sicherzustellen. Denn nur weil die CNI Binary den Pods eine IP-Adresse zugewiesen und sie mit dem Network Namespaces ihrer Hosts verbunden hat, hei\u00dft das noch nicht, dass dem Host auch die Informationen vorliegen, wie andere Kubernetes Nodes und ihre Pods erreichbar sind \u2013 wir erinnern uns wieder an Abbildung 4, wo diese Informationen manuell durch Routing-Regeln bereitgestellt wurden. Es wird dar\u00fcber hinaus m\u00f6glich, Overlay-Netzwerke zu erzeugen, indem die auf jedem Knoten ausgef\u00fchrten Komponenten \u00fcber eine Control Plane miteinander kommunizieren und Mechanismen implementiert werden, um Datenpakete ein- und auszukapseln.<\/p>\n<p>Auch f\u00fcr die Umsetzung von Netzwerkrichtlinien k\u00f6nnen weitere Komponenten notwendig sein \u2013 etwa ein weiterer privilegierter Pod, der <span class=\"lang:default decode:true crayon-inline\">NetworkPolicy<\/span>-Ressourcen \u00fcberwacht und <span class=\"lang:default decode:true crayon-inline\">iptables<\/span>-Regeln auf dem Host implementiert beziehungsweise l\u00f6scht. Es wird deutlich, dass ein Netzwerk-Plugin (oder besser eine Netzwerkl\u00f6sung) aus deutlich mehr als der CNI Binary besteht. Es wird auch deutlich, dass diese L\u00f6sungen interoperabel einsetzbar sind und die eigentliche Komplexit\u00e4t in ihren jeweiligen Komponenten liegt. Diese m\u00fcssen lediglich auf der Zielplattform betrieben werden und bauen zun\u00e4chst unabh\u00e4ngig von etwaigen Workloads ein cluster\u00fcberspannendes Netzwerk auf. Das CNI-Plugin sorgt dann durch entsprechende Schnittstellenkonfigurationen nur noch daf\u00fcr, dass neue Workloads auf der Plattform diesem Netzwerk hinzugef\u00fcgt beziehungsweise sp\u00e4ter wieder gel\u00f6scht werden. Anstelle der Nutzung von privilegierten Pods k\u00f6nnte ebenso direkt auf dem Host ein Routingdaemon wie BIRD f\u00fcr BGP installiert werden, um die Konnektivit\u00e4t zwischen den Knoten sicherzustellen. Man erkennt die lose Kopplung beziehungsweise den modularen Ansatz zwischen Netzwerkl\u00f6sung und Plattform.<\/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 abschlie\u00dfend festhalten? Die knotenlokalen Netzwerkmechanismen von Kubernetes lassen sich am Beispiel Docker leicht verst\u00e4ndlich herleiten und sind mit Linux-Bordmitteln umsetzbar. Komplizierter wird es bei der knoten\u00fcbergreifenden Pod-to-Pod-Kommunikation. Zum einen muss eine clusterweit konfliktfreie Vergabe von IP-Adressen gew\u00e4hrleistet werden, damit jeder Pod \u00fcber seine eigene, eindeutige IP-Adresse verf\u00fcgt. Zum anderen muss jeder Pod \u00fcber diese IP-Adresse auch clusterweit ohne NAT erreichbar sein. Was bei wenigen Knoten innerhalb eines lokalen Netzwerks in Anlehnung an Abbildung 4 noch als manuell umsetzbar erscheinen mag, ist in gr\u00f6\u00dferen (Produktiv-)Umgebungen und\/oder \u00f6ffentlichen Netzen nicht mehr praktikabel. An dieser Stelle setzen Netzwerk-Plugins an. Sie \u00fcbernehmen die Netzwerkkonfiguration der Pods \u2013 etwa die Vergabe von IP-Adressen \u2013 und deren Verbindung zum zuvor erzeugten Podnetzwerk, ohne dass ein manueller Eingriff erforderlich ist. \u00dcber den de-facto Standard CNI, der wie eine Art Adapter zwischen Kubelet bzw. Container Runtime und Netzwerk-Plugins von Drittanbietern fungiert, stehen eine Vielzahl kompatibler L\u00f6sungen zur Verf\u00fcgung, die auf ihre eigene Art und Weise, aber stets unter Einhaltung der durch Kubernetes definiertes Anforderungen, ein knoten\u00fcberspannendes Netzwerk herstellen. Drei solcher L\u00f6sungen, n\u00e4mlich Project Calico, Cilium und Weave Net, schauen wir uns im zweiten Teil dieser Serie genauer an.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Anwendungskomponenten, die mittels Kubernetes als Pods ausgef\u00fchrt werden, k\u00f6nnen \u00fcber mehrere Knoten eines Clusters verteilt sein. 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":19032,"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],"coauthors":[{"id":225,"display_name":"Simon Kurth","user_nicename":"skurth"}],"class_list":["post-18938","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-cloud","service-cloud"],"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 1: Networking Essentials - inovex GmbH<\/title>\n<meta name=\"description\" content=\"Im ersten Teil dieser Serie befassen wir uns mit den Grundlagen des Container Networkings am Beispiel Docker und nutzen diese zum Verst\u00e4ndnis der internen Mechanismen von Kubernetes sowie der Funktionsweise eines Podnetzwerks. Dann gehen wir der Frage nach, wof\u00fcr wir ein Kubernetes Netzwerk Plug-In \u00fcberhaupt ben\u00f6tigen.\" \/>\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-1-essentials\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Kubernetes Networking Teil 1: Networking Essentials - inovex GmbH\" \/>\n<meta property=\"og:description\" content=\"Im ersten Teil dieser Serie befassen wir uns mit den Grundlagen des Container Networkings am Beispiel Docker und nutzen diese zum Verst\u00e4ndnis der internen Mechanismen von Kubernetes sowie der Funktionsweise eines Podnetzwerks. Dann gehen wir der Frage nach, wof\u00fcr wir ein Kubernetes Netzwerk Plug-In \u00fcberhaupt ben\u00f6tigen.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/\" \/>\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-19T10:32:45+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2024-02-19T07:13:14+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Kubernetes-Networking-101.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\/05\/Kubernetes-Networking-101-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=\"16\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-1-essentials\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-1-essentials\\\/\"},\"author\":{\"name\":\"Simon Kurth\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/person\\\/9d07667a11a6a36956e82ca902ba3bb4\"},\"headline\":\"Kubernetes Networking Teil 1: Networking Essentials\",\"datePublished\":\"2020-06-19T10:32:45+00:00\",\"dateModified\":\"2024-02-19T07:13:14+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-1-essentials\\\/\"},\"wordCount\":2878,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-1-essentials\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2020\\\/05\\\/Kubernetes-Networking-101.png\",\"keywords\":[\"Cloud\"],\"articleSection\":[\"General\",\"Infrastructure\"],\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-1-essentials\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-1-essentials\\\/\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-1-essentials\\\/\",\"name\":\"Kubernetes Networking Teil 1: Networking Essentials - inovex GmbH\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-1-essentials\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-1-essentials\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2020\\\/05\\\/Kubernetes-Networking-101.png\",\"datePublished\":\"2020-06-19T10:32:45+00:00\",\"dateModified\":\"2024-02-19T07:13:14+00:00\",\"description\":\"Im ersten Teil dieser Serie befassen wir uns mit den Grundlagen des Container Networkings am Beispiel Docker und nutzen diese zum Verst\u00e4ndnis der internen Mechanismen von Kubernetes sowie der Funktionsweise eines Podnetzwerks. Dann gehen wir der Frage nach, wof\u00fcr wir ein Kubernetes Netzwerk Plug-In \u00fcberhaupt ben\u00f6tigen.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-1-essentials\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-1-essentials\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-1-essentials\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2020\\\/05\\\/Kubernetes-Networking-101.png\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2020\\\/05\\\/Kubernetes-Networking-101.png\",\"width\":1920,\"height\":1080,\"caption\":\"Kubernetes Networking 101 und die 0 ist das Kubernetes-Logo.\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-1-essentials\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Kubernetes Networking Teil 1: Networking Essentials\"}]},{\"@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 1: Networking Essentials - inovex GmbH","description":"Im ersten Teil dieser Serie befassen wir uns mit den Grundlagen des Container Networkings am Beispiel Docker und nutzen diese zum Verst\u00e4ndnis der internen Mechanismen von Kubernetes sowie der Funktionsweise eines Podnetzwerks. Dann gehen wir der Frage nach, wof\u00fcr wir ein Kubernetes Netzwerk Plug-In \u00fcberhaupt ben\u00f6tigen.","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-1-essentials\/","og_locale":"de_DE","og_type":"article","og_title":"Kubernetes Networking Teil 1: Networking Essentials - inovex GmbH","og_description":"Im ersten Teil dieser Serie befassen wir uns mit den Grundlagen des Container Networkings am Beispiel Docker und nutzen diese zum Verst\u00e4ndnis der internen Mechanismen von Kubernetes sowie der Funktionsweise eines Podnetzwerks. Dann gehen wir der Frage nach, wof\u00fcr wir ein Kubernetes Netzwerk Plug-In \u00fcberhaupt ben\u00f6tigen.","og_url":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/","og_site_name":"inovex GmbH","article_publisher":"https:\/\/www.facebook.com\/inovexde","article_published_time":"2020-06-19T10:32:45+00:00","article_modified_time":"2024-02-19T07:13:14+00:00","og_image":[{"width":1920,"height":1080,"url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Kubernetes-Networking-101.png","type":"image\/png"}],"author":"Simon Kurth","twitter_card":"summary_large_image","twitter_image":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Kubernetes-Networking-101-1024x576.png","twitter_creator":"@inovexgmbh","twitter_site":"@inovexgmbh","twitter_misc":{"Verfasst von":"Simon Kurth","Gesch\u00e4tzte Lesezeit":"16\u00a0Minuten","Written by":"Simon Kurth"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/#article","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/"},"author":{"name":"Simon Kurth","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/9d07667a11a6a36956e82ca902ba3bb4"},"headline":"Kubernetes Networking Teil 1: Networking Essentials","datePublished":"2020-06-19T10:32:45+00:00","dateModified":"2024-02-19T07:13:14+00:00","mainEntityOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/"},"wordCount":2878,"commentCount":0,"publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Kubernetes-Networking-101.png","keywords":["Cloud"],"articleSection":["General","Infrastructure"],"inLanguage":"de","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/","url":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/","name":"Kubernetes Networking Teil 1: Networking Essentials - inovex GmbH","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/#primaryimage"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Kubernetes-Networking-101.png","datePublished":"2020-06-19T10:32:45+00:00","dateModified":"2024-02-19T07:13:14+00:00","description":"Im ersten Teil dieser Serie befassen wir uns mit den Grundlagen des Container Networkings am Beispiel Docker und nutzen diese zum Verst\u00e4ndnis der internen Mechanismen von Kubernetes sowie der Funktionsweise eines Podnetzwerks. Dann gehen wir der Frage nach, wof\u00fcr wir ein Kubernetes Netzwerk Plug-In \u00fcberhaupt ben\u00f6tigen.","breadcrumb":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/#primaryimage","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Kubernetes-Networking-101.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Kubernetes-Networking-101.png","width":1920,"height":1080,"caption":"Kubernetes Networking 101 und die 0 ist das Kubernetes-Logo."},{"@type":"BreadcrumbList","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-1-essentials\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.inovex.de\/de\/"},{"@type":"ListItem","position":2,"name":"Kubernetes Networking Teil 1: Networking Essentials"}]},{"@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\/18938","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=18938"}],"version-history":[{"count":4,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/18938\/revisions"}],"predecessor-version":[{"id":51844,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/18938\/revisions\/51844"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media\/19032"}],"wp:attachment":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media?parent=18938"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/tags?post=18938"},{"taxonomy":"service","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/service?post=18938"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/coauthors?post=18938"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}