{"id":20449,"date":"2021-01-06T14:08:55","date_gmt":"2021-01-06T13:08:55","guid":{"rendered":"https:\/\/www.inovex.de\/blog\/?p=20449"},"modified":"2024-02-19T08:13:12","modified_gmt":"2024-02-19T07:13:12","slug":"kubernetes-networking-part-1-en","status":"publish","type":"post","link":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/","title":{"rendered":"Kubernetes Networking Part 1: Networking Essentials"},"content":{"rendered":"<p>Application components, running as pods inside <a href=\"https:\/\/www.inovex.de\/de\/leistungen\/cloud\/kubernetes\/\">Kubernetes<\/a>, can be distributed among multiple nodes of a cluster. Therefore the inter-node communication presents a particular challenge. Due to the heterogeneity of network environments found in the field, Kubernetes only defines the requirements, but does not implement them. Instead a common specification, the <a href=\"https:\/\/github.com\/containernetworking\/cni\">Container Network Interface<\/a> (CNI) is used to connect to different suitable network implementations. Due to the decoupling and the universal acceptance of CNI a variety of compatible plugins is available to be used with Kubernetes.<\/p>\n<p>This series sums up my bachelor&#8217;s thesis from September 2019, in which I covered the fundamentals of Kubernetes networking as well as the functional and technical differences of three popular networking plugins. Extending on this I extracted criteria to compare also other plugins and to be used as the basis for choosing a suitable plugin.<\/p>\n<p>The first part of this series covers the fundamentals of container networking with Docker as reference. We will apply this knowledge to fully understand the internal networking mechanisms of Kubernetes and the \u201cpod network\u201c. The article will also answer the question why we need a Kubernetes network plugin in the first place. The second part will then dive into the particular implementations <a href=\"https:\/\/www.projectcalico.org\/\">Project Calico<\/a>, <a href=\"https:\/\/cilium.io\/\">Cilium<\/a>\u00a0and\u00a0Weave Net\u00a0and will explain their fundamental paradigms and functional differences. At the end of the series you should then have an overview of the major concepts of Kubernetes networking and also know the criteria by which to choose the most suitable network plugin for your particular environment.<\/p>\n<p><!--more--><\/p>\n<p><a href=\"https:\/\/www.inovex.de\/blog\/kubernetes-networking-1-essentials\/\">[Diesen Beitrag auf deutsch lesen.]<\/a><\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_82_2 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-part-1-en\/#Fundamentals-of-Container-Networking\" >Fundamentals of Container Networking<\/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-part-1-en\/#The-Kubernetes-Networking-Model\" >The Kubernetes Networking Model<\/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-part-1-en\/#The-Container-Network-Interface-CNI\" >The 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-part-1-en\/#Installing-Kubernetes-Network-Plugins\" >Installing Kubernetes Network 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-part-1-en\/#Summary\" >Summary<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"Fundamentals-of-Container-Networking\"><\/span>Fundamentals of Container Networking<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Out of the box Docker containers operate in bridge-mode. The following graphic shows this classic scenario in which two Docker containers are started in a shared bridge network.<\/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\">Graphic 1 &#8211; Architecture of Docker bridge network<\/figcaption><\/figure>\n<p>For each network Docker creates a virtual linux network bridge, initially named <span class=\"lang:default decode:true crayon-inline\">docker0<\/span>. This bridge is then able to route traffic via the Linux Kernel routing table and out the existing physical interface of the host (<span class=\"lang:default decode:true crayon-inline\">eth0<\/span>). Internally it creates a separate address space in the form of a subnet. Each container is connected to the bridge via a <span class=\"lang:default decode:true crayon-inline\">veth<\/span>-pair. This interface pair functions like a virtual point-to-point ethernet connection and connects the network namespaces of the containers with the network namespace of the host. The communication between containers of a docker bridge network always happens via the bridge &#8211; provided the IP address or the hostname of the other container is known. Since both containers have their own dedicated namespace, they each maintain their own routing table, interfaces and <span class=\"lang:default decode:true crayon-inline\">iptables<\/span> rules.<\/p>\n<p>If you start a Docker container with the option <span class=\"lang:default decode:true crayon-inline\">&#8211;net=container:&lt;container-name&gt;<\/span>, with <span class=\"lang:default decode:true crayon-inline\">&lt;container-name&gt;<\/span> being an existing container, the new container will be connected to the virtual interface of the existing container. Both containers now share the same namespace and therefore have a joint network stack. Communication is now possible using the loopback interface or <span class=\"lang:default decode:true crayon-inline\">localhost<\/span>. Exactly this concept is also used by Kubernetes to allow communication between containers within a single pod. Remember: A pod can hold multiple containers (usually a main container and one or more sidecars). So a web server bound to port 8080 and running in container 1 is then reachable via <span class=\"lang:default decode:true crayon-inline\">http:\/\/localhost:8080<\/span>\u00a0from container 2, even though there is no such process running there. In the context of Kubernetes this is called <b>Container-to-Container communication<\/b>. Graphic 2 visualizes this communication pattern.<\/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\">Graphic 2 &#8211; Docker Container Mode<\/figcaption><\/figure>\n<p>Within a Kubernetes Pod it\u2019s worth to note that apart from the \u201cuser containers\u201c there is yet another so called \u201cpause\u201c container. This container only exists to create and maintain the network namespace. If all the user containers fail or crash, the pod and its namespace remains to allow the other containers to join back after their restart.<\/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\">Graphic 3 &#8211; Architecture Kubernetes Pod<\/figcaption><\/figure>\n<p>The architecture shown in graphic 3 can be observed when using i.e. <a href=\"https:\/\/github.com\/kubernetes\/minikube\">minikube<\/a> with Docker as container runtime. If there are more pods those will also be connected to the bridge via <span class=\"lang:default decode:true crayon-inline\">veth<\/span>-pairs. This architecture might vary, depending on the container runtime and the particular network plugin used for multi-node clusters, as we will observe in the second part of the series. Understanding this architecture is still a good base to understand node-local networking mechanisms &#8211; especially when you have prior experience with Docker when starting with Kubernetes.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"The-Kubernetes-Networking-Model\"><\/span>The Kubernetes Networking Model<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>After focusing on the networking between containers <i>within<\/i> a single pod, we shall now go one abstraction layer higher and look at communication between pods. To illustrate let\u2019s imagine a simple web application, consisting of a frontend and a backend. Remember: Because both components have different characteristics (stateless vs. stateful), one would put them into individual pods, at least to scale them independently. To allow the web application to function properly, the pods need to be able to communicate with each other at all times &#8211; independently from the node which they currently run on. Regarding the <b>Pod-to-Pod communication<\/b> it\u2019s important to ensure that pods on a single node as well as pods on a topological remote can establish communication at all times. After all Kubernetes\u2019 job is to spread workload evenly among the available nodes, while abstracting away the actual hardware resources. It shall not concern the developer of an application if the frontend or backend pod run on the same or different nodes. The pod-to-pod communication is implemented like this:<\/p>\n<p>Each pod receives a unique IP address, valid anywhere in the cluster. Kubernetes requires this address to not be subject to network address translation (NAT). This is intended to simplify the communication among application components by making each pod reachable via this IP address which is the same that is also bound to its virtual network interface.<\/p>\n<p>For communication between pods on the same node this is implicitly achieved via the virtual bridge (L2) &#8211; see the explanation around graphic 3 above &#8211; archiving seamless cross nodes is more complex: First of all there needs to be some sort of IP address management (IPAM), in order for IP addresses not to be used multiple times or conflict in other ways. Furthermore the local bridge networks of all nodes need to be connected so communication can happen across nodes.<\/p>\n<p>There are multiple approaches to implement such requirements: Quite simply they could be set up manually by an administrator or be managed by an external component &#8211; the network plugin &#8211; which is connected to the Kubelet. The Kubelet always serves as the primary interface between the Kubernetes API and the local container runtime. It\u2019s running as an agent on every node. From a networking perspective the cross-node communication can be implemented on layer 2 (Switching) or layer 3 (Routing) or also as an overlay network.<\/p>\n<p>A possible implementation of such a pod network could look like this:<\/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\">Graphic 4 &#8211; Possible implementation of a pod network<\/figcaption><\/figure>\n<p>In this case the bridges on each node are connected and some simple routing rules are applied: Each node\u2019s routing table holds routes to all the other nodes internal networks with the next-hop being the physical interface of the particular target node. Additionally there is another route for the node&#8217;s own subnet and local bridge network to allow incoming traffic from external as well as locally originating (i.e. a pod running in host mode) to be forwarded to the bridge.<\/p>\n<p>The graphic illustrates a packet being initiated by pod 2 and the transmission of that packet across the physical connection between node A and node B to finally reach pod 3. The virtual ethernet pair (<span class=\"lang:default decode:true crayon-inline \">veth<\/span>-pair) serves as a logical connection between the network namespace of the pod and the network namespace of the host system. In case of a switched layer 2 network both nodes can communicate via ARP and their own MAC address directly. In case there was a router between node A and node B (layer 3) the subnet used on the bridge networks on each node would need to be added to its routing table as well.<\/p>\n<p>In a nutshell the pod network illustrated in graphic 4 implements all the requirements defined by Kubernetes: Pods can communicate with all other pods, local as well as remote, and do so without any NAT. Also all nodes (or rather processes running there) can also reach all local and remote pods as well as all other nodes directly and without NAT. But as soon as packets targeting another pod reach a router on a public network the traffic will be dropped due to it being addressed to a private network. This results in the shown setup only being applicable if all nodes are connected to each other via a switch or if intermediate routers can be configured explicitly. Otherwise NAT would have to be used to mask the private addresses and in order to allow traffic to be routed. This is where tunnelling protocols or so called overlay networks come into play, which can be added via network plugins to a Kubernetes cluster. Even in local networks, in which tunneling protocols are not actually required, the manual tasks of configuring multiple nodes, as shown in graphic 4 is not manageable. This job is taken over and automated by network plugins.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"The-Container-Network-Interface-CNI\"><\/span>The Container Network Interface (CNI)<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The container network interface was developed by CoreOS (now part of RedHat) and in relation to the rkt container runtime. The goal was to define a common interface between network plugins and container runtime or orchestrator. Meanwhile CNI is common among container orchestrators &#8211; with the exception of Docker Swarm (which uses the Docker-specific solution libnetwork) &#8211; which results in a number of compatible plugins from 3rd parties.<\/p>\n<p>CNI consists of a specification and some libraries to allow the development of plugins which configure network interfaces in Linux Containers. Furthermore the CNI project comes with a few <a href=\"https:\/\/github.com\/containernetworking\/plugins\">\u201eCore\u201c Plugins<\/a> which cover fundamental functionality &#8211; i.e. creation of Linux bridges or connecting host and container to it. CNI only handles network connectivity of container and the cleanup of allocated resources (i.e. IP addresses) after containers have been deleted (garbage collection) and therefore is lightweight and quite easy to implement. Apart from Kubernetes CNI is also used for OpenShift, Cloud Foundry, Apache Mesos or Amazon ECS.<\/p>\n<p>To better understand CNI it is worth looking into certains aspects of the <a href=\"https:\/\/github.com\/containernetworking\/cni\/blob\/master\/SPEC.md\">specification<\/a>: According to this a CNI plugin has to be provided as executable file (binary), which can be invoked by the container management system (in case of Kubernetes with Docker this would be the Kubelet) after a network namespace has been created to host a new container (<span class=\"lang:default decode:true crayon-inline \">ADD<\/span> operation). Following this step the plugin has to add a network interface inside the container namespace (following the example from graphic 4, this is the container-facing end of the <span class=\"lang:default decode:true crayon-inline \">veth<\/span>-pair) and also ensure connectivity on the host (in our example this is the host-facing end of the <span class=\"lang:default decode:true crayon-inline\">veth<\/span>-pair and the connection to the bridge). Finally it needs to assign an IP address to the created interface and add required routes maintaining consistency with the IP address management (IPAM) which is handled by an IPAM plugin. According to the specification the following operations have to be implemented:<\/p>\n<ul style=\"list-style-type: square;\">\n<li><span class=\"lang:default decode:true crayon-inline\">ADD<\/span><strong>\u00a0<\/strong>(Adding a container to a network),<\/li>\n<li><span class=\"lang:default decode:true crayon-inline \">DEL<\/span>\u00a0\u00a0(Remove container from a network),<\/li>\n<li><span class=\"lang:default decode:true crayon-inline\">CHECK<\/span><strong>\u00a0<\/strong>(Validating connectivity) and<\/li>\n<li><span class=\"lang:default decode:true crayon-inline \">VERSION<\/span> (Respond with the CNI versions the plugin supports)<\/li>\n<\/ul>\n<p>The configuration of a plugin has to happen via a JSON file. Further details can be found in the <a href=\"https:\/\/github.com\/containernetworking\/cni\/blob\/master\/SPEC.md\">specification<\/a><\/p>\n<p>Practically speaking a CNI conformant plugin could be realized via a BASH script, which implements the four operations in the form of individual, parameterized functions. The script would utilize existing tools like <span class=\"lang:default decode:true crayon-inline \">$ ip link<\/span> oder <span class=\"lang:default decode:true crayon-inline \">$ ip route add<\/span> to create and configure interfaces or add routes.<\/p>\n<p>We have looked at the specification and have a first idea on how a plugin is to be implemented. But how is CNI utilized by Kubernetes? To Kubernetes using Docker as the Container Runtime (<a href=\"https:\/\/github.com\/kubernetes\/kubernetes\/tree\/release-1.19\/pkg\/kubelet\/dockershim\">Dockershim<\/a>) CNI is a network plugin <i>itself<\/i>. It is connected to the Kubelet running on each node, which is responsible for creating and deleting containers. A network plugins is selected via the option <span class=\"lang:default decode:true crayon-inline\">&#8211;network-plugin=&lt;cni|kubenet&gt;<\/span>. This step is usually handled by installers like kubeadm. kubenet is the built-in \u201cbasic\u201c network plugin Kubernetes comes with. It also uses the CNI core plugins, but is not widely used. If an alternative container runtime like <a href=\"https:\/\/containerd.io\">containerd<\/a> or <a href=\"https:\/\/cri-o.io\">CRI-O<\/a> is used via the Container Runtime Interface (CRI) the runtime will directly interact with the CNI plugin with no additional calls via the Kubelet or Dockershim.<\/p>\n<p>In the case of Docker as container runtime a network plugin has to implement the <span class=\"lang:default decode:true crayon-inline \">NetworkPlugin<\/span> interface (<a href=\"https:\/\/github.com\/kubernetes\/kubernetes\/blob\/3446ffbb4a5328e88a75afc36a258c1f7adb1b89\/pkg\/kubelet\/dockershim\/network\/plugins.go#L54\">see GitHub<\/a>). This specifies functions like <span class=\"lang:default decode:true crayon-inline \">SetupPod()<\/span>\u00a0and\u00a0<span class=\"lang:default decode:true crayon-inline \">TearDownPod()<\/span>. The Kubelet calls the first function after a <span class=\"lang:default decode:true crayon-inline \">pause<\/span> container and therefore a new pod has been stated. The other function is called after a <span class=\"lang:default decode:true crayon-inline \">pause<\/span> container and therefore a previously existing pod has been deleted. The CNI implementation inside the Dockershim uses the official <a href=\"https:\/\/github.com\/containernetworking\/cni\/tree\/master\/libcni\">CNI library<\/a> provided for integrations (<a href=\"https:\/\/github.com\/kubernetes\/kubernetes\/blob\/3446ffbb4a5328e88a75afc36a258c1f7adb1b89\/pkg\/kubelet\/dockershim\/network\/cni\/cni.go#L31\">see GitHub<\/a>).\u00a0Roughly sketched the method calls after creating a new pod look like this:<\/p>\n<ol>\n<li>The Kubelet calls\u00a0<span class=\"lang:default decode:true crayon-inline\">SetupPod()<\/span>, which then calls\u00a0<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\">see GitHub<\/a>)<\/li>\n<li><span class=\"lang:default decode:true crayon-inline\">addToNetwork()<\/span>\u00a0then uses\u00a0<span class=\"lang:default decode:true crayon-inline \">addNetworkList()<\/span>\u00a0from the imported CNI library. This then invokes\u00a0<span class=\"lang:default decode:true crayon-inline \">addNetwork()<\/span>\u00a0(<a href=\"https:\/\/github.com\/containernetworking\/cni\/blob\/77436456f2ab8443ba0450d61b1499bd50e8a704\/libcni\/api.go#L400\">see GitHub<\/a>)<\/li>\n<li aria-level=\"1\">Finally the <span class=\"lang:default decode:true crayon-inline\">ADD<\/span> operation of the provided CNI-compatible plugin is invoked during <span class=\"lang:default decode:true crayon-inline\">addNetwork()<\/span> (<a href=\"https:\/\/github.com\/containernetworking\/cni\/blob\/77436456f2ab8443ba0450d61b1499bd50e8a704\/libcni\/api.go#L421\">see GitHub<\/a>)<\/li>\n<\/ol>\n<p>To sum up, CNI is, by implementing the <span class=\"lang:default decode:true crayon-inline \">NetworkPlugin<\/span> interface, a Kubelet network plugin itself. But it is also a specification for 3rd party network plugins such as Weave Net, by describing the expected operations and behavior.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Installing-Kubernetes-Network-Plugins\"><\/span>Installing Kubernetes Network Plugins<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Before we dive into the particular network plugins we need to understand how they are installed. Usually the project provides a YAML manifest containing all required Kubernetes resources. This only has to be applied to a cluster via <span class=\"lang:default decode:true crayon-inline \">$ kubectl create -f<\/span>. This is due to the fact that there are usually more components required than just the single CNI binary implementing the functions to add or delete pods. Usually those components come in the form of one or more privileged pods, running as DeamonSet on each node. They influence the network configuration of the node or can even intercept and forward traffic independently to ensure communication across multiple nodes. Since having the CNI binary provide IP addresses to pods and connecting them to the host network namespace is not enough to provide the host with the required details on how to reach other Kubernetes nodes or pods &#8211; remember graphic 4 in which this information in the form of routes was provided manually. Additionally it\u2019s possible to create and use overlay networks by having each node-local component communicate via a control-plane and implement mechanisms to encapsulate and decapsulate data packets.<\/p>\n<p>Also to provide network policies additional components are required &#8211; potentially in the form of a privileged pod which monitors <span class=\"lang:default decode:true crayon-inline \">NetworkPolicy<\/span> resources and applying <span class=\"lang:default decode:true crayon-inline \">iptables<\/span> rules on the host. As you can see a NetworkPlugin consists of much more than just the CNI binary. But it\u2019s also shown that components are interchangeable and the complexity of the networking lies within each implementation. They just have to be run on the target platform and then form a cluster-wide network &#8211; independently from any workload. The CNI plugin then simply provides the interfaces required to add and remove workloads to this network. Instead of privileged pods there also could be a routing daemon like BIRD running locally on the host to ensure connectivity between the different nodes. This makes you realize the loose coupling between the networking components and the general platform.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Summary\"><\/span>Summary<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>What to take away from this? The node-local networking mechanisms of Kubernetes are quite easy to understand when looking at Docker and they are realized using the Linux built-in tools. More complex then is the Pod-to-Pod communication across nodes. First the distribution of IP addresses without conflicts has to be ensured, so each pod is assigned its own, unique address. Additionally each pod has to be reachable cluster-wide and without any NAT. Realizing this might seem straightforward for a few nodes &#8211; looking at the setup on graphic 4 again &#8211; but is not practical for larger environments, potentially involving public networks, anymore. This is where network plugins come into play. They take on the job of all network configuration for pods &#8211; assigning IP addresses and connectivity to the established pod network &#8211; with no manual intervention required. With the de-facto standard CNI, serving as an adapter between Kubelet \/ container runtime and 3rd-party network plugins, a variety of solutions are available. Each using their own implementation and methods, but following the Kubernetes requirements to create a flat network for all nodes.<\/p>\n<p>Three of those solutions, namely Project Calico, Cilium und Weave Net, we shall be looking at in great detail in part two of this series.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Application components, running as pods inside Kubernetes, can be distributed among multiple nodes of a cluster. Therefore the inter-node communication presents a particular challenge. Due to the heterogeneity of network environments found in the field, Kubernetes only defines the requirements, but does not implement them. Instead a common specification, the Container Network Interface (CNI) is [&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,114],"service":[423],"coauthors":[{"id":225,"display_name":"Simon Kurth","user_nicename":"skurth"}],"class_list":["post-20449","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-cloud","tag-kubernetes","service-kubernetes"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.4 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Kubernetes Networking Part 1: Networking Essentials - inovex GmbH<\/title>\n<meta name=\"description\" content=\"This article covers the fundamentals of container networking with Docker as a reference. We will apply this knowledge to fully understand the internal networking mechanisms of Kubernetes and the \u201cpod network\u201d. The article will also answer the question why we need a Kubernetes network plugin in the first place.\" \/>\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-part-1-en\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Kubernetes Networking Part 1: Networking Essentials - inovex GmbH\" \/>\n<meta property=\"og:description\" content=\"This article covers the fundamentals of container networking with Docker as a reference. We will apply this knowledge to fully understand the internal networking mechanisms of Kubernetes and the \u201cpod network\u201d. The article will also answer the question why we need a Kubernetes network plugin in the first place.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/\" \/>\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=\"2021-01-06T13:08:55+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2024-02-19T07:13:12+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=\"14\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-part-1-en\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-part-1-en\\\/\"},\"author\":{\"name\":\"Simon Kurth\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/person\\\/9d07667a11a6a36956e82ca902ba3bb4\"},\"headline\":\"Kubernetes Networking Part 1: Networking Essentials\",\"datePublished\":\"2021-01-06T13:08:55+00:00\",\"dateModified\":\"2024-02-19T07:13:12+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-part-1-en\\\/\"},\"wordCount\":2831,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-part-1-en\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2020\\\/05\\\/Kubernetes-Networking-101.png\",\"keywords\":[\"Cloud\",\"Kubernetes\"],\"articleSection\":[\"English Content\",\"General\",\"Infrastructure\"],\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-part-1-en\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-part-1-en\\\/\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-part-1-en\\\/\",\"name\":\"Kubernetes Networking Part 1: Networking Essentials - inovex GmbH\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-part-1-en\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-part-1-en\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2020\\\/05\\\/Kubernetes-Networking-101.png\",\"datePublished\":\"2021-01-06T13:08:55+00:00\",\"dateModified\":\"2024-02-19T07:13:12+00:00\",\"description\":\"This article covers the fundamentals of container networking with Docker as a reference. We will apply this knowledge to fully understand the internal networking mechanisms of Kubernetes and the \u201cpod network\u201d. The article will also answer the question why we need a Kubernetes network plugin in the first place.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-part-1-en\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-part-1-en\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/kubernetes-networking-part-1-en\\\/#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-part-1-en\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Kubernetes Networking Part 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 Part 1: Networking Essentials - inovex GmbH","description":"This article covers the fundamentals of container networking with Docker as a reference. We will apply this knowledge to fully understand the internal networking mechanisms of Kubernetes and the \u201cpod network\u201d. The article will also answer the question why we need a Kubernetes network plugin in the first place.","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-part-1-en\/","og_locale":"de_DE","og_type":"article","og_title":"Kubernetes Networking Part 1: Networking Essentials - inovex GmbH","og_description":"This article covers the fundamentals of container networking with Docker as a reference. We will apply this knowledge to fully understand the internal networking mechanisms of Kubernetes and the \u201cpod network\u201d. The article will also answer the question why we need a Kubernetes network plugin in the first place.","og_url":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/","og_site_name":"inovex GmbH","article_publisher":"https:\/\/www.facebook.com\/inovexde","article_published_time":"2021-01-06T13:08:55+00:00","article_modified_time":"2024-02-19T07:13:12+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":"14\u00a0Minuten","Written by":"Simon Kurth"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/#article","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/"},"author":{"name":"Simon Kurth","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/9d07667a11a6a36956e82ca902ba3bb4"},"headline":"Kubernetes Networking Part 1: Networking Essentials","datePublished":"2021-01-06T13:08:55+00:00","dateModified":"2024-02-19T07:13:12+00:00","mainEntityOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/"},"wordCount":2831,"commentCount":0,"publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Kubernetes-Networking-101.png","keywords":["Cloud","Kubernetes"],"articleSection":["English Content","General","Infrastructure"],"inLanguage":"de","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/","url":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/","name":"Kubernetes Networking Part 1: Networking Essentials - inovex GmbH","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/#primaryimage"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2020\/05\/Kubernetes-Networking-101.png","datePublished":"2021-01-06T13:08:55+00:00","dateModified":"2024-02-19T07:13:12+00:00","description":"This article covers the fundamentals of container networking with Docker as a reference. We will apply this knowledge to fully understand the internal networking mechanisms of Kubernetes and the \u201cpod network\u201d. The article will also answer the question why we need a Kubernetes network plugin in the first place.","breadcrumb":{"@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/blog\/kubernetes-networking-part-1-en\/#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-part-1-en\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.inovex.de\/de\/"},{"@type":"ListItem","position":2,"name":"Kubernetes Networking Part 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\/20449","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=20449"}],"version-history":[{"count":4,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/20449\/revisions"}],"predecessor-version":[{"id":51842,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/20449\/revisions\/51842"}],"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=20449"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/tags?post=20449"},{"taxonomy":"service","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/service?post=20449"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/coauthors?post=20449"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}