Kubernetes Service Types: ClusterIP, NodePort, LoadBalancer

In Kubernetes, Pods are ephemeral — they die, restart, and change IPs. A Service puts a stable access point in front of a group of Pods. But where you can reach it from depends on the Service type. There are three main types.

ClusterIP (default)

Gives a virtual IP reachable only from inside the cluster. Closed to the outside world. Ideal for microservices talking to each other — e.g. an API reaching its database.

NodePort

Opens a specific port (30000-32767) on every node for your app. You can reach it externally via <node-ip>:<port>. Simple but crude for production — usually used for dev/test or behind a load balancer.

LoadBalancer

Provisions a real external load balancer from your cloud provider (AWS, GCP, Azure) and gives a single public IP. It's the standard way to receive external traffic in production.

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

Which one, when?

• ClusterIP: internal service-to-service traffic (default)
• NodePort: quick testing or custom network setups
• LoadBalancer: exposing a single service to the internet in production
• For many HTTP services: Ingress + ClusterIP (one LB, many routes)

Case: 'I can't reach my Service' — diagnosis

You created a Service but curl times out. 90% of the time the cause is: the Service selector matches no Pods (so Endpoints is empty). The diagnosis flow:

1. 1kubectl get endpoints <svc> → if empty, the selector doesn't match
2. 2kubectl get pods --show-labels → do Pod labels equal the Service selector?
3. 3Does targetPort match the port the container actually listens on?
4. 4Test from inside the cluster (before changing the external type)

$ kubectl get svc web
NAME   TYPE        CLUSTER-IP     PORT(S)   AGE
web    ClusterIP   10.96.0.20     80/TCP    3m
$ kubectl get endpoints web
NAME   ENDPOINTS   AGE
web    <none>      3m               # ⚠ empty! The selector matches no Pod.
$ kubectl get pods --show-labels
web-xyz  1/1  Running  app=web-api   # Pod label is 'app=web-api'
# Service selector is 'app=web' → mismatch. Fix the selector:
$ kubectl get endpoints web
NAME   ENDPOINTS                       AGE
web    10.244.0.7:8080,10.244.0.8:8080 1m   # ✓ now populated
$ kubectl run tmp --rm -it --image=busybox -- wget -qO- web:80
<h1>OK</h1>                          # ✓ in-cluster access works

Trying these types on a real cluster and watching traffic makes the concept stick — exactly what Cloudpuz's Kubernetes labs offer.