Kubernetes Networking

Three Fundamental Requirements of Kubernetes Networks

  1. All containers should be accessible to each other without NAT, regardless of which nodes they are on
  2. All nodes should communicate with all containers
  3. The IP container should see itself the same way as the others see it

Pod-to-pod communications – Same Node

Pod IP addresses are accessible from other pods no matter which nodes they’re on. This fits
the second requirement.

Pod-to-pod communication within the same node goes through the bridge by default.

Pod communication across nodes

According to the second requirement, all nodes must communicate with all containers.
Kubernetes delegates the implementation to the container network interface (CNI). Users
could choose different implementations, by L2, L3, or overlay. Overlay networking is one of
the common solutions, known as packet encapsulation.

Pod-to-service communication

The Kubernetes service is an abstraction to define a set of pods by label selectors. We normally use the service to
access pods instead of specifying a pod explicitly. When we create a service, an endpoint object is created, which describes a set of pod IPs that the label selector in that service has selected.

External Access to Services

The ability to serve external traffic to Kubernetes is critical. Kubernetes provides two API
objects to achieve this:
Service: External network LoadBalancer or NodePort (L4)
Ingress: HTTP(S) LoadBalancer (L7)

Ingress

Route External Traffic to a Kubernetes Cluster

kubernetes networking
  1. Pods and services in Kubernetes have their own IP; however, it is normally not the interface
    you’d provide to the external internet.
  2. Though there is service with node IP configured, the port in the node IP can’t be duplicated among the services.
  3. It is cumbersome to decide which port to manage with which service. Furthermore, as the node appears and is shut down, it would not be prudent to provide a static node IP to external service.
  4. Ingress defines a set of rules that allows the inbound connection to access Kubernetes
    cluster services.
  5. It brings the traffic into the cluster at L7, allocates and forwards a port on each VM to the service port.
  6. We define a set of rules and post them as source type ingress to the API server. When the traffic comes in, the
    ingress controller will then fulfill and route the ingress by the ingress rules. As shown in the
    figure above, ingress is used to route external traffic to the kubernetes endpoints by
    different URLs.