Before we can understand Kubernetes networking we must first understand what we are trying to solve. There are 3 issues we need to solve in a Kubernetes cluster:
- Container to Container communication
- pod to pod communication
- pod to service communication
Solving for Kubernetes Network IssuesLet us go over each one of the bullet points we mentioned above and how Kubernetes attempts to solves it.
Container to Container CommunicationThis is solved with the concept of Pods. In Linux, a network namespace contains its own network resources, i.e interfaces, routing tables, etc. This same concept applies to Pods. When a pod is created, it gets a network namespace that the containers in the pod will share resources therefore allowing all containers in a pod to communicate through localhost.
Pod to Service CommunicationA service is an abstraction that routes traffic to a set of pods. A service gets its own Cluster IP, the pods also get their own IP’s and when requests need to reach the pods, it is sent to the service Cluster IP and then forwarded to the actual IP of the pods. This way pods(mortals) can come and go without worrying about updating IP’s since by default the service will automatically update its endpoint with the IP of the pod that it targets as those pod changes IP. The way the service knows what pod to target is through LabelSelector. This is an important concept to be aware of since LabelSelector is the only way the service knows what pod to target and keep track of their IP’s.
Pod to Pod CommunicationFor communication between pods, Kubernetes imposes the following fundamental requirements on any networking implementation:
- all Pods can communicate with all other Pods without using network address translation (NAT)
- all Nodes can communicate with all Pods without NAT.
- the IP that a Pod sees itself as is the same IP that others see it as.
The idea is that when a pod is created, Linux Virtual Ethernet Device or veth pair can be used to connect Pod network namespaces to the root network namespace. Pods on the same node can talk through a bridge.
A Linux Ethernet bridge is a virtual Layer 2 networking device used to unite two or more network segments, working transparently to connect the two networks together. For Pods on separate nodes, assuming connectivity between the nodes, request will go from root namespace of one node to the root namespace of other node. The node should then know how to route traffic to the correct pod.