ClusterIP vs NodePort vs LoadBalancer

WHAT THIS TESTS Knowing how each Service type exposes traffic and choosing appropriately for internal versus external access.

A GOOD ANSWER COVERS ClusterIP is the default. It assigns a stable virtual IP reachable only from within the cluster, making it the right choice for internal communication between microservices, such as a frontend calling a backend. NodePort builds on ClusterIP by additionally opening a static port (in a high range) on every node's IP; external traffic hitting any node on that port is forwarded to the Service. It suits development, on-premises clusters, or sitting behind an external load balancer you manage yourself. LoadBalancer builds on NodePort by asking the cloud provider to provision an external load balancer with a public IP that directs traffic into the Service. It is the standard production path for exposing an app to the internet on a managed cloud.

COMMON WRONG ANSWERS Using NodePort to serve production internet traffic, which exposes node IPs and properties poorly. Not realizing the types layer on each other. Confusing LoadBalancer with Ingress, which operates at layer 7 for HTTP routing.

LIKELY FOLLOW-UPS What if you need host or path routing for many services? Use Ingress in front of a single LoadBalancer. What about bare metal? LoadBalancer needs an implementation like MetalLB. NodePort range? A configurable high port range.

ONE CONCRETE EXAMPLE An internal cache uses ClusterIP. A dev cluster exposes a test app via NodePort so engineers hit a node IP and port. The production web app uses a LoadBalancer Service, which on a cloud provider spins up an external load balancer with a public IP routing to the web Pods.