Network requirements

In order to understand the network requirements of our cluster, we first need to understand the Kubernetes networking model and what problems it aims to solve. Container networking can be very hard to grasp; however, it has three essential problems:

  1. How do containers talk to each other (on the same host and on different hosts)?
  2. How do containers talk to the outside world, and how does the outside world talk to the containers?
  3. Who allocates and configures each container's unique IP address?

Containers on the same host can talk to each other through a virtual bridge that you can see with the brctl utility from the bridge-utils package. This is handled by the Docker engine and it's called the Docker networking model. Containers are attached to the virtual bridge named docker0 through a veth virtual interface that is allocated an IP from a private subnet address. In this way, all containers can talk to each other through their veth virtual interface. The problem with the Docker model arises when containers are allocated on different hosts, or when external services want to communicate with them. To solve this, Docker provides a method where containers are exposed to the outside world through the host's ports. Requests come into a certain port in the host's IP address and are then proxied to the container behind that port.

This method is useful but not ideal. You can't configure services to specific ports or in a dynamic port allocation scenario—our services will require flags to connect to the correct ports each time we deploy them. This can get really messy very quickly.

To avoid this, Kubernetes have implemented their own networking model that has to comply with the following rules:

  1. All pods can communicate with all other pods without network address translation (NAT)
  2. All nodes can communicate with all pods without NAT
  3. The IP that the pod sees itself as is the same IP that others see it as

There are several open source projects out there that can help us to reach this goal, and the one that suits you best will depend on your circumstances. Here are some of them:

Assigning IPs to pods and making them talk between them is not the only issue to be aware of. Kubernetes also provides DNS-based service discovery, because applications that talk through DNS records rather than IPs are far more efficient and scalable.