Don’t blow out your inspiration and your imagination; Don’t be a slave to your model. — Vincent Van Gogh

The implementation of K8S network model is committed to solving the following scenarios:

  • Tightly coupled container-to-container communication
  • Abstract POD-to-POD communication
  • Communication between Pod and Service
  • Communication between external and internal components of the cluster

Communication between containers within the same Pod

  • Containers in the same Pod share IP addresses with different ports and can communicate directly with localhost
  • You can communicate directly using IPC (such as message queues or pipes)

Containers within different PODS communicate

Communication between pods on the same Node

  • They are the same network segment, both assigned from Docker0, the same bridge, can communicate directly

  • Non-local data sent by POD will be transferred to the host through Docker 0 route

Pods on different nodes communicate with each other

K8s stores the IP assignment information of all running PODS in etCD and requires that the IP addresses of these pods do not conflict. For example, Flannel can automatically assign network segments to Docker0 on different nodes.

Communication between two PODS on different nodes must meet two conditions:

  • The IP addresses of Pod are uniformly allocated in the entire K8S cluster without conflict

  • Find a way to associate the Pod IP with the Node IP

Docker0 network segment and host network adapter are two completely different IP network segments. They can only communicate through the host physical network adapter, so they can only communicate through the HOST IP address.

Communication between Pod and Service

Service is an abstraction of Pod so that Pod can be extended horizontally so that Pod can be load-balanced through Service.

The client accesses the Service through its virtual IP address, and the Service forwards requests to the Pod on the back end, similar to a reverse proxy

Each Kube-Proxy deployed on Nodes forwards access to the Service to multiple pods on the back end

ClusterIP and NodePort concepts of Service are implemented by Kube-proxy through Iptables NAT. Access to ClusterIP and Port can be run on any Node. This is because the Kube-proxy on each Node sets the same forwarding rules for the Service.

Open Source Network Components

Flannel

  • Assign non-conflicting IP addresses to Docker containers on each Node
  • An overlay network is established between each IP address and is delivered to the target container intact through the overlay network.
  • Flannel modifies the startup parameters of Docker and passes the assigned address segment parameters
  • Flannel uses UDP by default and has to be repeatedly tested for availability in heavy traffic

conclusion

Understand the K8S network model is to understand the premise of k8S internal communication mechanism, the next chapter will take you to understand the way of K8S service discovery!