ClusterIP, NodePort, LoadBalancer, and Headless
The type field on a Service controls how it is exposed. Each type builds on the previous one:
1. ClusterIP (Default)
The Service gets an IP reachable only from within the cluster. No external traffic can reach it. This is the correct choice for internal backend services — databases, caches, internal APIs — that should never be directly accessible from the internet.
2. NodePort
Opens a specific port (in the range 30000–32767) on every node in the cluster. Any traffic sent to <any-node-IP>:<node-port> is forwarded to the Service. This allows external access without a cloud load balancer, but it's clunky: you're exposing a high-numbered port, and you need to know a node's IP. Mostly used for development or on-premises clusters without cloud integrations.
3. LoadBalancer
The standard way to expose a Service to the internet on cloud providers (AWS, Azure, GCP). Kubernetes instructs the cloud provider's API to provision a real external load balancer (like an AWS Network Load Balancer) with a public IP address. That load balancer routes external traffic into the cluster's NodePort, which routes to the Service, which routes to Pods. This is the most common type for production internet-facing services.
4. Headless Services
A special variant of ClusterIP where the cluster IP is explicitly set to none. Instead of providing a single stable IP and load balancing, a DNS lookup for the Service name returns a list of all individual Pod IPs directly. This is used by stateful applications — like a Cassandra or Kafka cluster — where each instance has a unique identity and peers need to discover and connect to each other individually, not through a load balancer.
A common interview question is: "How does a Service know which Pods to send traffic to?" The answer is label selectors — the Service's spec.selector field defines a set of key-value labels, and the Service routes traffic to all Pods whose metadata.labels match. Kubernetes maintains an Endpoints object (or the newer EndpointSlice) that is automatically updated as matching Pods are created or destroyed. A follow-up: "What happens if a Service has no matching Pods?" — the Endpoints object is empty, and all connections to the Service will be refused or time out.