The Kubernetes Networking Model | Caylent

Many web applications today consist of multiple containers, utilizing different Services from different places. Kubernetes effectively streamlines the process of implementing multi-container applications. With Kubernetes, the user can configure features on the container orchestration tool exactly how they want to combine different containers within a single app. Kubernetes then handles the process of rolling them out, maintaining them, and ensuring that all the components remain in sync.

There are other advantages to Kubernetes as well:

• Scaling container-based apps: An important feature of web apps is that they need to be able to scale up and down according to the number of users. Meeting demand while balancing the incoming load and ensuring proper use of resources is essential for any app that is expected to be deployed at scale. Kubernetes is able to automate these processes.In Kube, scaling happens at two fundamental levels. Container and infrastructure scaling features like Horizontal and Vertical Pod Autoscaler (HPA & VPA), as well as Cluster Autoscaler (CA), automate scaling for integral components on-demand. (Check out the blog post, Kubernetes Horizontal Pod & Cluster Autoscaling: All You Need to Know for more on these in detail.)
• Roll out new versions without shutting down: One of the biggest appeals of the container-based approach to application development is that it allows for continuous delivery and integration. Kubernetes enables graceful updates, whereby updates can be rolled out without the need for any downtime.
• Works in any environment: Kubernetes is not locked to any particular cloud environment or underlying technology. Any platform that supports containers can run Kubernetes, making it a very versatile tool. Kubernetes is the ultimate container orchestration platform for the Cloud. It offers excellent Cloud support and enables teams to use it as a true Cloud-native development platform with a seemingly endless potential to build on top of.

Kubernetes Networking Conditions

Kubernetes sets certain conditions and requirements for the networking communication of Pods:

1. Pods are all able to communicate with one another without the need to use network address translation (NAT).
2. Nodes are the machines that run the Kubernetes cluster. These can be either virtual or physical machines, or indeed anything else that is able to run Kubernetes. These nodes are also able to communicate with all the Pods, without the need for NAT.
3. Each Pod will see itself with the same IP that other Pods see it as having.

This is the Kubernetes network model in a nutshell. It leaves us with three networking challenges that need to be solved in order to take advantage of Kubernetes:

1. Container-to-container networking.
2. Pod-to-Pod networking
3. Pod-to-Service networking

Container-to-Container Networking

We generally think of a virtual machine’s network communication of consisting of a single Ethernet device that it interacts with directly. However, the reality of the situation is a little more nuanced than this.

In Linux, every running process intercommunicates within a network namespace. This namespace provides a new network stack for all the processes contained within the namespace. Linux’s default behavior is to assign each process to the root network namespace, and in doing so, provide access to the external world.

A Pod is modeled as a group of individual Docker containers, all of which share a network namespace. All the containers within a given Service will have the same IP address and port space, which is assigned by the Pod’s assigned network namespace. Because the containers all reside within the same namespace, they are able to communicate with one another via localhost.

Pod-to-Pod Networking

Every Pod in Kubernetes has an assigned IP address and this IP address is the one that other Pods will see. In understanding how Pods communicate with one another via real IP addresses, let us first consider two Pods that reside on the same physical machine, and therefore share a node.

As far as each Pod is concerned, it exists in its own Ethernet namespace. This namespace then needs to communicate with other network namespaces that are located on the same node. Linux provides a mechanism for connecting namespaces using a virtual Ethernet device (VED or ‘veth pair’). The VED comprises of a pair of virtual interfaces. In order to connect two Pod namespaces, one side of the VED is assigned to the root network namespace. The other member of the veth pair is then assigned to the Pod’s network namespace.

The VED then acts like a virtual cable that connects the root network namespace to that of the Pod’s network namespace and allowing them to exchange data.

Pod-to-Service Networking

Pod IP addresses in Kubernetes are not durable. Whenever an application is scaled up or down, or encounters an error and needs to reboot, their IP address will disappear and need to be reassigned. This change in IP address occurs without warning. In response to this, Kubernetes utilizes Services.

In Kubernetes, a Service manages the current state of a set of Pods. This provides the user with a means of tracking IP addresses and other properties that change over time. Services serve as an abstraction layer on top of the Pods, assigning a single virtual IP address to a specified group of Pods. Once these Pods are associated with that virtual IP address, any traffic which is addressed to that virtual IP will be routed to the corresponding set of Pods. The set of Pods that are linked to a Service can be changed at any time, but the IP address of the Service will remain static.

Kubernetes makes managing multi-container applications easier than ever before. Its use of Pods takes the already powerful concept of containers and gives them an added boost. Despite the learning curve, using Kubernetes is more straightforward than many people realize. Armed with an understanding of how Kubernetes networking features, you are ready to take your application development to the next level.

Caylent offers DevOps-as-a-Service to high growth companies looking for help with microservices, containers, cloud infrastructure, and CI/CD deployments. Our managed and consulting services are a more cost-effective option than hiring in-house, and we scale as your team and company grow. Check out some of the use cases and learn how we work with clients by visiting our DevOps-as-a-Service offering.

Source