Kubernetes Networking 101
- Introduction
- Kubernetes Networking
- Container-to-Container Networking
- Pod-to-Pod Networking
- Pod-to-Service Networking
- Internet-to-Service Networking
- Conclusion
Introduction
This post is the third part of a blog series about Docker networking. For a better understanding, we recommend that you go through the first and the second part before proceeding with this post. While parts one and two deep dive into Docker networking, this post addresses Kubernetes networking. If you’re interested in monitoring Kubernetes, jump over to our guide on Monitoring Kubernetes with Prometheus.
If you are familiar with containerization and microservices philosophy, and the different network types and levels, you’ve already mastered a good part of Docker networking. However, in real-world scenarios and in production-grade environments, containers are just a part of a whole landscape. To be able to support production workloads, Docker needs to run inside a container orchestration system. Two of the most popular orchestration frameworks are Docker Swarm and Kubernetes. These platforms are used to automatically manage and schedule containers inside a cluster of nodes, or virtual/physical machines.
Orchestration is just as important as containerization, and it needs additional knowledge — in particular networking.
Let’s take into consideration Docker Swarm and Kubernetes. If you are already familiar with the Docker networking model, you will be able to understand the greater part of Docker Swarm network paradigms by going through part two of this series. In that post, we created three Docker hosts using Docker Machine: a manager and two workers. Therefore, we have seen how to establish an ingress network between the containers living in different machines.
When you use Kubernetes, things are slightly different, especially the networking model. Understanding how Kubernetes networking works is essential if you want to run Docker in production. This post will look into a few different kinds of Kubernetes networking.
Kubernetes Networking
In Kubernetes, we talk less about containers and more about pods. This does not mean that containers are less important than pods, but containers run inside pods.
Probably, the best definition of pods is the official one: Pods are the smallest deployable units of computing that can be created and managed in Kubernetes. Containers running inside the same pod share the same resources, notably networking. This shared context in networking implies tools and configurations like Linux namespaces, cgroups, and possibly other isolation and control mechanisms are shared.
In a Kubernetes cluster, all pods should be able to communicate with all other pods in their cluster without NAT, wether those pods belong to the same node or not. Another condition to establish the Kubernetes networking models concerns the communication between agents and pods: Kubernetes agents, like kubelet, should be able to communicate with pods inside the same node.
Containers within a pod are able to reach each other’s ports on localhost.
Finally, a pod has a unique IP address, and it sees itself with the same service IP (ClusterIP) address as what is seen by the other pods in the same cluster.
To implement the described networking mode, the Kubernetes administrator can use open source tools like Project Calico, OpenVSwitch, or Cilium. When using a managed cluster, the implementation is ensured by the cloud provider (e.g., AWS VPC CNI for Kubernetes, Azure CNI for Kubernetes, Google Compute Engine .etc.).
In order to deep dive into the networking model, let’s understand four important concepts:
- Container-to-Container Networking
- Pod-to-Pod Networking
- Service-to-Pod Networking
- Internet-to-Service Networking
…
To finish reading this article, check out the full post on the MetricFire website.
