TL;DR: ClusterIP gives a stable internal address, NodePort adds a port on every node, and LoadBalancer requests an external load-balancing implementation. It commonly retains a ClusterIP and uses NodePorts, but some implementations route directly to pods. Select public or internal exposure explicitly.
How to approach it
Lead with the stacking relationship, because presenting the three as alternatives leaves you unable to explain why a LoadBalancer Service still has an internal IP. Then say what you would actually run, which is the part the type list does not tell you: whether shared HTTP routing meets the applications' isolation and protocol requirements.
A strong answer
Start with the problem all of them solve. Pods are replaced constantly and each replacement gets a new IP, so nothing can depend on a pod address. A Service is a stable name and a stable virtual IP that keeps pointing at whichever pods currently match its selector.
ClusterIP is the default. The Service gets a virtual IP that only works inside the cluster, plus a DNS name (payments.prod.svc.cluster.local). Traffic to that IP is rewritten by the node's dataplane to one of the healthy pod IPs. This is what service-to-service calls use, and it is the right answer for the overwhelming majority of Services.
NodePort is a ClusterIP plus a port opened on every node in the cluster, by default somewhere in 30000-32767. With the usual Cluster traffic policy, a reachable node can forward to an endpoint on another node. Local traffic policy restricts forwarding to local endpoints. It is useful for a bare-metal cluster with something else in front, and for local development. In a cloud environment it is mostly a building block rather than something you expose directly, because the port number is ugly, the range is restricted, and you have to know node addresses that change.
LoadBalancer requests a load balancer from an installed controller. It may be public or internal, and its targets can be nodes or pod IPs depending on the implementation. Supporting controllers can use allocateLoadBalancerNodePorts: false. Account for the provider's resource and traffic charges when choosing separate versus shared frontends.
ExternalName is the odd one out and does no proxying at all. It maps a Service name to an external DNS name via a CNAME, which is handy when you want in-cluster code to call database and have that resolve to a managed database hostname you can change later.
What I would run: every internal Service as ClusterIP, and one Ingress controller or Gateway at the edge, exposed with a single LoadBalancer, routing by hostname and path to those ClusterIP Services. One cloud load balancer, TLS terminated in one place, and routing rules that live in Kubernetes objects rather than in the cloud console.
One more detail that comes up: a Service with clusterIP: None is a headless Service. DNS returns the pod IPs directly instead of a virtual IP, which is what StatefulSets use so each replica is individually addressable.
Trace the external and internal paths independently
Suppose checkout has a ClusterIP and healthy endpoints, while its external load balancer reports no healthy targets. First test the Service from an approved in-cluster client. If that succeeds, inspect the load balancer's target type, health check and traffic policy before changing application labels.
With externalTrafficPolicy: Local, a node without a local eligible endpoint does not forward external traffic to a pod on another node. The load balancer must select appropriate nodes. With a controller that targets pod IPs directly, the external path may bypass NodePorts entirely. Draw the implementation you actually run rather than assuming every provider uses the same chain.
Choose separate external load balancers when isolation, protocol or ownership requirements justify them. Sharing an HTTP gateway can reduce repeated infrastructure, but it also creates a shared failure domain. Record which team owns its capacity and rollout policy. Service documentation covers traffic policies and optional NodePort allocation.
What interviewers probe next
"How does the Service know which pods to send to?" A label selector, matched continuously. Pods that match and pass their readiness probe are in the endpoint list; anything failing readiness is removed, which is how a rolling update avoids sending traffic to a pod that is still starting.
"Is a Service a proxy?" Not a process in the path. The node programs rules (iptables, IPVS, or eBPF) so the packet is rewritten in the kernel. Performance depends on the data plane, connection tracking and endpoint scale; it still needs measurement.
"How does it balance?" Roughly randomly per connection, in the kernel, with no awareness of load. If you need real load balancing policy, retries or circuit breaking, that is what a mesh or an Ingress controller gives you.
Common mistakes
Presenting the three types as unrelated options rather than layers, then being unable to say what a LoadBalancer Service's ClusterIP is for.
Giving every microservice its own LoadBalancer, which works and produces a cloud bill nobody can explain.
Confusing a Service with an Ingress. A Service does not understand HTTP, hostnames or paths; it works at the connection level.
Forgetting readiness. Readiness normally controls endpoint eligibility, with exceptions such as publishNotReadyAddresses and existing connections that need separate consideration.