What are the four Kubernetes Service types, and when do you use each one?

Think of a building with different types of doors. ClusterIP is an internal corridor door — only people already inside the building can use it. NodePort is a side entrance with a specific door number — anyone who knows the building address and door number can enter. LoadBalancer is the main lobby with a receptionist who directs visitors to the right floor. ExternalName is a sign that says 'for this service, go to the building next door.'

ClusterIP is the default and most common service type. It assigns a virtual IP address that is only reachable from within the cluster. Pods use this to communicate with each other — for example, a payments-api pod talks to a payments-db service via its ClusterIP. The kube-proxy component on each node programs iptables or eBPF rules to route traffic from the ClusterIP to one of the healthy backend pods selected by the service's label selector.

NodePort builds on top of ClusterIP by opening a static port (range 30000-32767) on every node in the cluster. External clients can reach the service by connecting to any node's IP on that port. Internally, traffic is forwarded to the ClusterIP. This is useful for development and testing but not recommended for production because it exposes random high ports and does not provide load balancing across nodes.

LoadBalancer builds on top of NodePort by requesting a cloud provider load balancer (AWS ELB, GCP LB, Azure LB) that gets an external IP and distributes traffic across all nodes. This is the standard way to expose services to the internet in production. The cloud controller manager provisions the load balancer automatically when you create a LoadBalancer service.

The non-obvious gotcha is that ExternalName does not create any endpoints or proxying — it simply returns a CNAME DNS record. This means health checking, load balancing, and failover do not apply. Also, LoadBalancer services can be expensive in cloud environments because each one provisions a separate cloud load balancer. Teams often use a single Ingress controller with an internal LoadBalancer service and route multiple services through it to reduce costs.