Kube-Proxy and CNI: The Backbone of Kubernetes Networking

Kubernetes networking looks simple — every Pod gets an IP, and Services route traffic automatically.

Behind this simplicity are two core components that make everything work: CNI and kube-proxy.

Kube-Proxy

Kube-Proxy is a network proxy that runs on each node in the cluster. When a service is created, it sets up the necessary network rules to route incoming requests to one of the pods backing the service. This can involve IP tables, IPVS (IP Virtual Server), or other networking mechanisms depending on the configuration.

The major work of Kube-Proxy internally involves tasks like-

• Kube Proxy makes services to actually route by handling routing to the pods.
• Kube Proxy maintains the Service IP behaves like a stable endpoint, even the Pods are ephemeral. Kube-proxy translates the Service IP to a Pod IP using iptables or IPVS rules.
• When a new service or endpoint is created, Kube Proxy sets up routing rules on the node. If a pod backing the service is deleted or a new pod is added, Kube-proxy updates the rules to maintain the service’s availability.
• Kube-Proxy enables service-level traffic distribution by kernel networking rules (iptables or IPVS), allowing traffic sent to a Service IP to be forwarded to one of the backing Pods.
• Without kube-proxy, Service IPs would exist but would not route traffic to Pods. kube-proxy wires Service IPs and ports to actual Pod endpoints.

Container Network Interface (CNI)

In Kubernetes, CNI is the standard way to provide networking to pods. The main purpose of CNI is to allow different networking plugins to be used with container runtimes. This allows Kubernetes to be flexible and work with different networking solutions

• Assigns a unique IP to each Pod so that it can communicate within the cluster.
• It will create and configure the Pod's network interface veth pair, then attach it inside the node's network namespace.
• It sets up routing rules so that Pods can communicate with other Pods across nodes.