ClusterIP vs NodePort vs LoadBalancer: Key Differences & When to Use

What is a Service ?

A service helps clients reach one (or more) of the Pods that can fulfill their request. The Service can be reached at the same place at any point in time, so it serves as a stable destination that the client can use to get access to what it needs. The client doesn’t have to worry about the Pods’ dynamic IP addresses.

Cluster IP ( for Pod to Pod Communication )

1. Service definition lives in the control plane (master node)
   • A ClusterIP Service is indeed a Kubernetes object stored in etcd (via API server).
   • It has a stable virtual IP inside the cluster.
   • It selects Pods based on labels (app=nginx ).
2. Kube-proxy runs on every worker node
   • Its job is to program routing rules (iptables or IPVS) so that when a request comes to the Service IP, the traffic can reach the right Pod.
3. Traffic routing
   • When a request comes to the Service’s ClusterIP, kube-proxy decides which Pod to send it to.
   • Only Pods that match the Service’s selector (app=nginx) will get traffic.

Small refinement (important nuance)

• The request to the ClusterIP doesn’t first “hit the master node” and then get distributed.
• Instead, the ClusterIP is virtual — kube-proxy on each worker node sets up rules so that any Pod on that node can directly reach the Service IP.
• When traffic hits the Service IP, kube-proxy on that worker node chooses a backend Pod (could be on the same node or a different node).
• If the chosen Pod is remote (different node), traffic is forwarded across the cluster network.

So the control plane (master node) stores the Service definition, but the routing actually happens on worker nodes (via kube-proxy).

Corrected Flow

1. Client Pod sends traffic to ClusterIP:Port.
2. Kube-proxy (on the same node as the client Pod) intercepts the traffic.
3. Kube-proxy load-balances and chooses one backend Pod with app=nginx.
4. Traffic is forwarded directly to that Pod (local or remote).