Kubernetes Services: ClusterIP vs NodePort vs LoadBalancer vs ExternalName

Pods are ephemeral and get a new IP each time they are recreated, so nothing can reliably address them. We need a stable virtual IP and DNS name that load-balances across a constantly changing set of matching pods.

Solution: Put a Service (ClusterIP/NodePort/LoadBalancer) in front of pods for a stable IP/DNS that load-balances to healthy pods.

At our port, the actual ships come and go constantly, different vessels tie up at different spots every day. If you told a customer "your goods are on the ship currently at the third buoy," they'd be lost the moment it sailed. So the port gives each route a permanent pier number: customers always go to "Pier 7," and the port quietly directs them to whichever ships are berthed there right now. A Kubernetes Service is that permanent pier number, a stable IP and DNS name, while the pods behind it are the ever-changing ships. The Service's selector is the rule "all ships flying the app=web flag dock at this pier."

The same cluster entities appear in every day's notes; the diagram below shows where this day's topic fits.

Pods are ephemeral — they die and get recreated with new IPs. You can't rely on a pod IP. A Service gives a stable virtual IP + DNS name and load-balances across the matching pods.

Pods run on nodes. Each pod gets its own IP; the container listens on a containerPort (e.g. 8080). Nodes have their own IPs too.

Graph legend — a real nginx Deployment fronted by a Service vs hit directly:

A Service has no hard-coded pod list — its selector matches pod labels, and the matching pod IPs become the Service's Endpoints.

Graph legend — how the nginx Service discovers its pods:

kubectl get endpoints nginx     # the actual nginx pod IPs behind the service

A Service's type field decides who can reach it and how. There are four types, from most internal to most external: ClusterIP (inside the cluster only), NodePort (reachable on each node's IP), LoadBalancer (a public cloud IP), and ExternalName (a DNS alias to something outside the cluster). The next four subsections take them one at a time.

1) ClusterIP (default) — internal only

Gives a stable virtual IP reachable only inside the cluster.

Use for pod-to-pod / internal microservice traffic.

Graph legend — ClusterIP keeps nginx internal-only:

2) NodePort — expose on every node's IP at a high port

Opens the same high port on every node, forwarding outside traffic to the pods.

Graph legend — NodePort exposes nginx on every node:

3) LoadBalancer — cloud external LB

Asks the cloud provider for a public IP and front-ends the service with a managed load balancer.

Graph legend — LoadBalancer fronts nginx with a cloud LB:

4) ExternalName — DNS alias to an external host

Maps the service name to an external DNS host via a CNAME — no pods, no proxying.

Graph legend — ExternalName aliases an external managed Postgres:

Kubernetes Services come in three main types, and they are not separate ideas — each one builds on the type beneath it. ClusterIP gives a Service a stable internal-only address; NodePort adds a fixed port on every node on top of that ClusterIP; LoadBalancer adds a cloud load balancer on top of the NodePort. So choosing LoadBalancer automatically gives you the NodePort and ClusterIP underneath — that stacking is the "layering" this section shows.

Graph legend — each Service type wraps the one below:

Minimal manifests for the two types you create most often.

ClusterIP (in front of a real nginx Deployment, image nginx:1.27, container port 80):

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - port: 80          # service port
      targetPort: 80    # nginx container port

NodePort:

spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30007   # optional; auto-assigned if omitted

These three ports map the hop from node, to service, to container — keep them straight.

Example mapping: 192.168.0.11:30007 (NodeIP:nodePort) to 10.96.0.5:80 (svc:port) to 10.1.1.8:80 (podIP:targetPort).

Graph legend — the three ports for the nginx Service:

Everyday commands to expose a Deployment, inspect the Service, and test it from inside the cluster.

kubectl create deployment nginx --image=nginx:1.27 --replicas=3
kubectl expose deployment nginx --port=80 --target-port=80 --type=NodePort
kubectl get svc
kubectl get svc nginx -o wide
kubectl describe svc nginx

# test internal DNS from another pod
kubectl run tmp --image=busybox -it --rm -- wget -qO- nginx:80

Every Service gets an in-cluster DNS name built from its name, namespace, and the cluster domain.

A request reaches a stable Service and is load-balanced across the healthy pods picked by its selector.

Graph legend — a request reaching the real nginx Service end to end:

• Services give a stable IP/DNS + load balancing over ephemeral pods.
• ClusterIP internal, NodePort node IPs, LoadBalancer cloud public, ExternalName DNS alias.
• Remember the port / targetPort / nodePort trio.

• [ ] Exposed a Deployment as ClusterIP and reached it from another pod
• [ ] Created a NodePort and hit it on a node IP
• [ ] Inspected kubectl get endpoints
• [ ] Can explain port vs targetPort vs nodePort