>DevOps Interview KB

What's the difference between ClusterIP, NodePort, LoadBalancer, and ExternalName, and how do you choose?

BeginnerComparisonKubernetes5 min read

Short Answer

ClusterIP (the default) exposes a Service only inside the cluster; NodePort additionally opens a static port on every node, reachable from outside the cluster via any node's IP; LoadBalancer provisions an actual external cloud load balancer that routes to the Service (and typically also creates the NodePort/ClusterIP underneath it); ExternalName is a special case that doesn't proxy traffic at all — it just returns a DNS CNAME to an external hostname, letting in-cluster clients use a cluster-local name to reach something entirely outside the cluster.

Detailed Explanation

ClusterIP: the default, cluster-internal-only exposure: allocates a virtual IP reachable only from within the cluster — this is the right choice for the large majority of Services, since most workloads (internal APIs, databases, caches) should only ever be reachable by other in-cluster workloads, not directly from outside.

NodePort: opens a static port on every node's IP: builds on ClusterIP but additionally reserves a port (from a configurable range, default 30000-32767) on every node in the cluster, forwarding traffic on that port to the Service — reaching the workload from outside means connecting to any node's IP on that specific port. This is rarely the final production exposure mechanism on its own (it ties clients to knowing specific node IPs, and doesn't handle node failure gracefully on its own) but is commonly used as a building block underneath a LoadBalancer Service or an Ingress controller.

LoadBalancer: provisions a real external load balancer via the cloud provider: requires a cloud provider integration (or a bare-metal equivalent like MetalLB) that actually creates an external load balancer resource (an AWS NLB/ELB, an Azure Load Balancer, a GCP Load Balancer) pointing at the Service — this is the standard way to expose a workload directly to the public internet or an external network, and typically has real ongoing cost associated with the provisioned load balancer resource itself.

ExternalName: a DNS-only alias, not a proxy: rather than routing traffic through the cluster's networking at all, an ExternalName Service simply configures CoreDNS to return a CNAME record pointing to an external hostname — in-cluster clients can then use a cluster-local Service name to reach something outside the cluster (an external database, a third-party API) as if it were just another in-cluster Service, without any traffic actually flowing through kube-proxy or a load balancer. This is purely a naming/discovery convenience, not a network exposure mechanism.

Choosing between them follows directly from where the traffic needs to originate and terminate: internal-only communication between workloads → ClusterIP; genuinely need public/external exposure with a real load balancer → LoadBalancer (most common for production internet-facing services, often actually fronted further by an Ingress controller which itself typically uses a LoadBalancer Service); need a stable in-cluster name for something that lives outside the cluster → ExternalName; NodePort is used directly relatively rarely in production, mostly as an implementation detail underneath the other mechanisms or in constrained/on-prem environments without a cloud load balancer integration available.

Ingress and Gateway API sit on top of these, not instead of them: an Ingress or Gateway API resource still needs an underlying Service (typically LoadBalancer or NodePort) for the Ingress/Gateway controller itself to be reachable — these choosing decisions aren't mutually exclusive with using Ingress; Ingress is a routing layer on top of whichever Service type actually exposes the controller.

Interview Follow-Up Questions

  • How does an Ingress controller typically expose itself to the outside world, in terms of which Service type it uses underneath?
  • What's the cost and operational implication of using a separate `LoadBalancer` Service per microservice, versus a single Ingress/Gateway fronting many services?
  • How would you troubleshoot a `LoadBalancer` Service stuck in `Pending` for its external IP indefinitely?

Key Takeaways

  • ClusterIP (the default) is cluster-internal only, and correct for the large majority of Services.
  • NodePort opens a static port on every node, mostly used as a building block underneath other exposure mechanisms rather than as a final production choice on its own.
  • LoadBalancer provisions a real external cloud load balancer, and is the standard mechanism for genuine public/external exposure.
  • ExternalName is DNS-only — it doesn't proxy traffic, it just aliases a cluster-local name to an external hostname via CNAME.

References

Last updated August 22, 2026 · Last reviewed August 22, 2026