Kubernetes · Orchestration under pressure
Compare ClusterIP, NodePort and LoadBalancer Services
Short answer
ClusterIP is internal-only. NodePort exposes a port on every node. LoadBalancer provisions an external load balancer that targets the Service, usually built on NodePort internally.
ClusterIP is the default and the building block for the others. NodePort allocates a port on every node and forwards it to the Service. LoadBalancer asks the cloud provider for an external load balancer, which then sends traffic to node ports or directly to pod endpoints depending on the implementation.
- ClusterIP is simplest and keeps traffic inside the cluster
- NodePort exposes every node and requires you to manage external routing and health checks
- LoadBalancer is convenient but can be costly and provider-specific
- LoadBalancer implementations vary in whether they preserve client IP
- Ingress or Gateway API is often a better fit for HTTP routing than many LoadBalancers
apiVersion: v1
kind: Service
metadata:
name: api-public
spec:
type: LoadBalancer
selector:
app: api
ports:
- port: 443
targetPort: 8443
externalTrafficPolicy: LocalThe trade-off is between control, cost and operational surface. NodePort gives you flexibility but pushes routing and TLS to you. LoadBalancer is easy per service but multiplies cloud resources. A shared ingress or gateway usually gives the best balance for HTTP workloads.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Why does a LoadBalancer Service often create a NodePort too?
- 2What does externalTrafficPolicy change?
- 3When would you expose a service with NodePort directly?
- 4How do you avoid one cloud load balancer per service?
Say it in the interview
ClusterIP is the internal virtual IP, NodePort adds a port on every node, and LoadBalancer asks the cloud for an external balancer. They are layered rather than exclusive, and the choice is really about cost, control and who owns routing. For HTTP I usually expose one ingress or gateway instead of a LoadBalancer per service. If I need client IP preservation, I weigh externalTrafficPolicy Local against its routing constraints.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.