Kubernetes Services: ClusterIP vs NodePort vs LoadBalancer

Pods are disposable. Kubernetes kills and recreates them freely, and every new Pod gets a new IP address — so you can never hand out a Pod's IP and expect it to keep working. A Service solves this: it's a stable address that always routes to the right, currently-alive Pods. The only thing you really have to choose is the type, and that comes down to one question: who needs to reach it?

The problem: Pod IPs are moving targets

A Deployment might replace your Pods during an update, a crash, or a scale event — each replacement with a fresh IP. Anything that talked directly to a Pod IP breaks the moment that Pod is replaced. You need a fixed point of contact that doesn't care which specific Pods are behind it right now.

What a Service does

A Service gives you a stable virtual IP and DNS name, and load-balances traffic across all Pods whose labels match its selector. Pods can churn underneath; the Service address never changes, and it only ever sends traffic to Pods that are currently Ready.

selector:
  app: web        # route to every Ready Pod labelled app=web

That much is true of every Service. The type just decides how far the door opens.

ClusterIP — internal only (the default)

ClusterIP gives the Service an IP reachable only inside the cluster. Perfect for internal wiring — your web Pods talking to your database or an internal API. Nothing outside the cluster can reach it. This is the default, and most Services in a cluster are ClusterIP.

NodePort — a port on every node

NodePort builds on ClusterIP and also opens a specific high port (30000–32767) on every node, so http://<node-ip>:<nodePort> reaches the Service from outside. It's simple and works anywhere, but it's blunt — odd ports, and you're exposing node IPs. Handy for quick access, dev, or as a building block, not usually your polished public front door.

LoadBalancer — a real external entry point

LoadBalancer builds on NodePort and asks the environment for an external load balancer with its own public IP (on a cloud, that provisions a real cloud LB; on bare metal you need something like MetalLB). This is the clean way to expose a single service to the internet.

The three types layer: LoadBalancer includes a NodePort, which includes a ClusterIP. You're not picking a mechanism so much as choosing how far out the same Service reaches.

And Ingress, briefly

Giving every public service its own LoadBalancer gets expensive fast. In practice you expose one LoadBalancer running an Ingress controller, and use Ingress rules to route many hostnames and paths to many internal ClusterIP Services. Services still do the internal load-balancing; Ingress does the smart HTTP routing at the edge.

The mental model to keep

A Service is a stable front door for a shifting set of Pods, and the type sets who can knock: ClusterIP = staff only (inside the cluster), NodePort = a side door on every node, LoadBalancer = a proper public entrance. Default to ClusterIP, reach for LoadBalancer (usually behind Ingress) when the outside world needs in.

Frequently Asked Questions

What's the difference between ClusterIP, NodePort, and LoadBalancer?

ClusterIP is internal-only (the default), NodePort opens a port on every node, and LoadBalancer provisions an external load balancer with a public IP. Each type builds on the one before it.

Why do I need a Service instead of a Pod IP?

Pod IPs change whenever pods are replaced. A Service gives a stable address and load-balances across whichever Ready pods currently match its selector.

Should I use LoadBalancer for every public service?

No — that gets expensive. Expose one LoadBalancer running an Ingress controller and route many services through Ingress rules instead.