10 min readCyber Infoware

Kubernetes NodePort, ClusterIP & LoadBalancer Explained: How Traffic Reaches Your Pods

Understand Kubernetes networking — ClusterIP, NodePort, LoadBalancer, Ingress, and nginx — and how external requests are load-balanced to Pods in a NestJS microservices cluster.

  • Kubernetes
  • Networking
  • Ingress
  • DevOps
  • Microservices
Kubernetes ClusterIP, NodePort, and LoadBalancer networking paths with Cyber Infoware branding

Kubernetes does not expose Pods as stable network names by default — Pods die and get new IPs. A Service gives you a stable virtual IP and load-balances to healthy Pods. Choosing ClusterIP, NodePort, or LoadBalancer (plus Ingress/nginx) decides who can reach your NestJS API and how.

The three Service types (and when to use each)

ClusterIP — internal only (default)

ClusterIP creates a virtual IP reachable only inside the cluster. Other Pods call `http://billing-service:3000`. Use it for NestJS domain services that must never be public — billing, audit, internal workers.

NodePort — open a port on every node

NodePort allocates a high port (e.g. 30080) on each node’s IP and forwards to the Service. Useful for labs and demos; awkward for production because you manage node IPs and ports yourself. Many teams use NodePort only as a building block under a cloud load balancer.

LoadBalancer — cloud-provisioned external IP

LoadBalancer asks your cloud to attach an external load balancer that targets the Service (often via NodePort under the hood). Clients hit a stable public IP/DNS; the LB spreads connections across nodes/Pods.

Comparison of ClusterIP, NodePort, and LoadBalancer service exposure paths
ClusterIP stays inside the cluster; NodePort opens node ports; LoadBalancer adds an external cloud balancer.

Ingress + nginx: HTTP routing in front of Services

For HTTP/HTTPS microservices, an Ingress controller (commonly nginx Ingress) terminates TLS and routes by host/path to ClusterIP Services — e.g. `/api` → gateway Service, `/auth` → Keycloak. One entry point, many backend Services, fewer public LoadBalancers to pay for.

Kubernetes cluster networking with ingress gateway and service paths
External clients → load balancer / Ingress → Services → Pods running NestJS containers.

How a request is distributed

  1. DNS resolves your API hostname to the cloud load balancer or Ingress IP.
  2. LB/Ingress forwards to a healthy node or directly to the Ingress Pod.
  3. nginx matches host/path rules and proxies to a ClusterIP Service.
  4. kube-proxy / data plane load-balances to Endpoints (Pod IPs) for that Service.
  5. Your NestJS Pod handles the request; readiness probes remove unhealthy Pods from rotation.

Rule of thumb: ClusterIP for internals, Ingress/nginx for HTTP edge, LoadBalancer sparingly. Explore kits on cyberinfoware.com or contact.

Explore Cyber Infoware packages

Production NestJS SaaS foundations with commercial licensing — pick the architecture that matches your team.

See pricingContact us

More from the blog

← Back to all articles