Services: ClusterIP, NodePort, and LoadBalancer

In one line

Pods get a new, unpredictable IP address every time they're recreated — a Service gives a set of pods one stable address that never changes, automatically routing to whichever healthy pods currently exist.

0/5 · 0%

Think of it like this

A company's single, permanent customer-support phone number, versus the actual support agents answering it, who rotate shifts constantly — callers only ever need to know the ONE stable number; who's actually answering behind it can change every hour with zero impact on how callers reach support.

Key ideas

01
A pod's IP address is genuinely unstable — Phase 0.3 already noted pods are disposable, and every time one is recreated (a crash, a rolling update, a reschedule), it gets a BRAND NEW IP. Hardcoding a pod's IP anywhere would break the moment that pod is inevitably replaced — which is exactly the problem a SERVICE exists to solve.
02
A SERVICE defines a stable virtual IP address and DNS name that automatically load-balances traffic across every pod matching a given LABEL SELECTOR — as pods come and go (scaled, healed, updated), the Service's own address never changes, and it automatically stops routing to pods that are gone and starts routing to new ones that match.
03
ClusterIP (the default Service type) is only reachable FROM WITHIN the cluster — the standard choice for internal communication between your own services (a backend reaching a database, one microservice calling another), never intended to be exposed to the outside world directly.
04
NodePort opens a specific port on EVERY worker node's own IP address, forwarding to the Service — genuinely useful for quick testing or specific on-prem setups, but rarely the right choice for real production external traffic, since it ties you to specific node IPs and a narrow port range (30000-32767 by convention).
05
LoadBalancer provisions an actual external load balancer from your cloud provider (an AWS ALB/NLB, for instance) pointing at the Service — the standard way to expose a Service directly to the public internet on a managed cloud cluster, though Phase 3's Ingress is often the more scalable choice when you have MANY services needing external access, since a LoadBalancer Service typically provisions one real cloud load balancer PER Service.

Code & diagrams

ServiceStableAddressdiagram

Pods' IPs change constantly; the Service's address never does.

Rendering diagram…

service.yamlmarkdown

A ClusterIP Service, matching the Deployment from Topic 1.1 by label.

apiVersion: v1
kind: Service
metadata:
  name: my-app-svc
spec:
  type: ClusterIP     # the default — internal only
  selector:
    app: my-app        # matches the Deployment's pod template labels
  ports:
    - port: 80          # the Service's own port
      targetPort: 8080   # the container's actual listening port

services.shmarkdown

Create a Service and confirm it survives pod churn, unlike a pod's own IP.

kubectl apply -f service.yaml

# See the Service's own stable ClusterIP
kubectl get svc my-app-svc

# From ANY other pod in the cluster, this address always works —
# by DNS name, not IP, which is even more stable
kubectl run test --rm -it --image=busybox -- sh
# inside that shell:
# wget -qO- http://my-app-svc

# Confirm the Service survives a pod being replaced
kubectl delete pod <one-of-my-app's-pods>
kubectl get pods -l app=my-app -w
# once the replacement is Ready, the Service is ALREADY routing to it —
# no reconfiguration needed anywhere

# Expose the same Deployment externally instead (cloud cluster required)
kubectl expose deployment my-app --type=LoadBalancer --port=80 --target-port=8080
kubectl get svc my-app-lb   # note the EXTERNAL-IP column once provisioned

Explain it without notes

Why can't you just hardcode a pod's IP address somewhere and call it done, instead of using a Service?

What's the practical difference between ClusterIP and LoadBalancer, and when would you use each?

Practice

Create the example Service pointing at your Deployment's pods, and confirm from a temporary test pod (kubectl run --rm -it) that you can reach it by its DNS name.

Delete one of the backing pods and confirm, without changing any Service configuration at all, that traffic continues working once the replacement pod becomes ready.

Trade-offs

↔
A LoadBalancer Service is the simplest way to expose ONE service externally, but provisioning a full cloud load balancer PER service gets genuinely expensive and unwieldy once you have many services needing external access — this is precisely the scaling problem Phase 3's Ingress solves, by routing many services through a single shared entry point instead.

Done when you can

I understand why pods' unstable IPs make a Service necessary.
I can create a ClusterIP Service and confirm it routes correctly using a label selector.
I know the practical difference between ClusterIP, NodePort, and LoadBalancer.