Kubernetes Networking
In this blog, we will discuss networking in Kubernetes. In the previous blog, we saw what is Kubernetes, its components and its architecture.
Next, we move on to look at what services, Ingress, CNI, and Network policies are in Kubernetes.
Services:
It helps to connect our applications with other applications or databases.
There are 3 services primarily used in Kubernetes.
NodePort: NodePorts are open ports on every cluster node. Exposes the service on each Node's IP at a static port.
ClusterIP: Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default service in K8s
LoadBalancer: Exposes the Service externally using a cloud provider's load balancer.
Ingress:
Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster.
CNI:
Container Network Interface (CNI) is a framework for dynamically configuring networking resources. It uses a group of libraries and specifications written in Go language. The plugin specification defines an interface for configuring the network, provisioning IP addresses, and maintaining connectivity with multiple hosts.
Network Policies:
Used to control the traffic flow at the IP address or port level.
When a pod is created, it is assigned a unique IP address from the cluster’s IP address range.
When a service is created, it is assigned a ClusterIP, which is a virtual IP address that is used to route traffic to the underlying pods.
When a pod sends traffic to a service, the traffic is routed to the ClusterIP of the service.
When a service receives traffic, it uses the Kubernetes Service Discovery mechanism to determine which pods should receive the traffic.
If the pods are running on different nodes, the traffic is routed through the nodes’ network interfaces.
Network Policies can be used to define rules for traffic flow between pods and services.
CNI plugins configure the network interfaces and routing tables on each node to ensure that traffic is routed correctly between pods and services.
In summary, Kubernetes networking is a complex topic that involves multiple layers and components. Pods, Services, Nodes, Network Policies, and CNI plugins all play
Kubernetes networking can be divided into two main categories: pod-to-pod networking and pod-to-service networking.
Pod-to-pod networking:
Pod 1 sends a packet to its own Ethernet device eth0 which is available as the default device for the Pod. For Pod 1, eth0 is connected via a virtual Ethernet device to the root namespace, veth0 (1). The bridge cbr0 is configured with veth0 a network segment attached to it. Once the packet reaches the bridge, the bridge resolves the correct network segment to send the packet to — veth1 using the ARP protocol (3). When the packet reaches the virtual device veth1, it is forwarded directly to Pod 2’s namespace and the eth0 device within that namespace (4). Throughout this traffic flow, each Pod is communicating only with eth0 on localhost and the traffic is routed to the correct Pod.
Each pod in a Kubernetes cluster is assigned a unique IP address within a cluster-wide range.
Pods can communicate with other pods on the same node using the localhost interface.
Pods on different nodes can communicate with each other using the nodes’ network interfaces. Kubernetes uses an overlay network to provide transparent communication between nodes.
By default, pods can communicate with any other pod in the cluster, regardless of namespace or security context. Network Policies can be used to restrict or allow traffic between pods.
Pod-to-service networking:
Services provide a stable IP address and DNS name for a set of pods.
When a pod sends traffic to a service, the traffic is routed to the ClusterIP of the service.
The ClusterIP is a virtual IP address that is managed by Kubernetes and associated with the service. It can be used to load balance traffic between the pods that back the service.
When a service receives traffic, it uses the Kubernetes Service Discovery mechanism to determine which pods should receive the traffic. This can be based on labels, selectors, or other criteria.
Services can be exposed within the cluster using different types of Kubernetes Services: ClusterIP, NodePort, and LoadBalancer.
Ingress is a Kubernetes API object that manages external access to the services in a cluster, typically using HTTP(S) routing rules.
In addition to these components, Kubernetes also uses DNS to provide name resolution for services. When a pod sends traffic to a service using its DNS name, Kubernetes resolves the name to the ClusterIP of the service.
