Service Types Deep Dive
ClusterIP, NodePort, LoadBalancer, ExternalName, and Headless — when to use each and how they work.
Service Types Overview
| Type | Reachable From | Use Case |
|---|---|---|
| ClusterIP | Inside cluster only | Internal microservice communication |
| NodePort | Node IP + port | Dev/testing, basic external access |
| LoadBalancer | External LB IP | Production cloud exposure |
| ExternalName | Inside cluster | Alias for external DNS name |
| Headless (clusterIP: None) | Inside cluster (DNS only) | StatefulSets, direct pod addressing |
ClusterIP (Default)
A stable virtual IP assigned to the service. kube-proxy programs iptables/ipvs to forward traffic to matching pods.
Pod A → ClusterIP:80 → kube-proxy → Pod B (one of the backends)
Cannot be reached from outside the cluster.
NodePort
Opens the same high port (30000–32767) on every node. Traffic to any node IP on that port reaches the service.
Laptop → NodeIP:30080 → kube-proxy → Pod
NodePort builds on ClusterIP. The service still has a ClusterIP for internal traffic.
LoadBalancer
Cloud provider creates an external load balancer pointing to the NodePort. Gives you one stable external IP.
Internet → ExternalIP:80 → Cloud LB → NodeIP:NodePort → kube-proxy → Pod
On minikube: use minikube tunnel to simulate the cloud LB.
ExternalName
Returns a CNAME DNS record. No proxying — pods that resolve the service name get the CNAME target.
spec: type: ExternalName externalName: my-database.us-east-1.rds.amazonaws.com
Headless (clusterIP: None)
DNS returns individual pod IPs instead of a single virtual IP. Used with StatefulSets for stable pod identity.