Skip to main content

Networking

Why kube-proxy Uses NAT

kube-proxy uses Network Address Translation (NAT) to manage the routing of traffic from a node to the appropriate pod(s) in a Kubernetes cluster.

What is NAT?

NAT, or Network Address Translation, is a technique used in networking to modify the network address information in packet headers as they pass through a routing device.

If you’ve worked with cloud networks, you’re likely familiar with deploying a NAT gateway to manage outgoing traffic from a private network to the internet.

Essentially, NAT allows private IP addresses to be mapped to a pool of public IP addresses, enabling secure and efficient communication between internal and external networks.

NAT In Kubernetes

In Kubernetes, kube-proxy uses Network Address Translation (NAT) in a way that is conceptually similar to how a NAT gateway operates in cloud networks, but within the context of a cluster.

Within a Kubernetes cluster, kube-proxy uses NAT to map the external-facing IP address (Node IP) and port (NodePort) or ClusterIP to the internal IP address and port of a pod.

This allows external clients and internal apps to interact with services running in pods without needing to know the internal pod IPs.

Why kube-proxy Uses NAT

Firs lets understand why kube-proxy uses NAT

1. IP and Port Translation

When you expose a service using a NodePort, the service is accessible through a port on each node's IP address.

However, the actual pods that serve the requests may not be running on the same node that receives the traffic. NAT allows kube-proxy to translate the node's IP and NodePort to the pod's IP and the port on which the pod is listening.

Even within the cluster, kube-proxy uses NAT to translate ClusterIP and port to the specific pod's IP and port.

2. Load Balancing

kube-proxy performs load balancing by selecting one of the available pod endpoints that match the service's selector.

NAT allows kube-proxy to forward the request to the selected pod, ensuring that the client remains unaware of which specific pod is serving the request.

The Logic Behind NAT in kube-proxy

When you try to access a Service in Kubernetes, here is what happens.

  1. When traffic arrives at a node's IP and a NodePort (or ClusterIP in internal traffic), kube-proxy intercepts this traffic.
  2. kube-proxy queries the Kubernetes API server to find the service associated with the incoming port.
  3. Based on the service's selector, kube-proxy selects one of the available endpoints (pod IP and port) to forward the traffic to.
  4. kube-proxy modifies the destination IP and port in the packet header to match the selected pod's IP and port. This is the NAT process.
  5. The modified packet is then forwarded to the selected pod. The pod processes the request and sends a response back to kube-proxy.
  6. When the pod responds, kube-proxy reverses the NAT operation, changing the source IP and port back to the node's IP and NodePort (or ClusterIP and port), so the client receives the response as if it came directly from the service.