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 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.

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.

How a request is distributed
- DNS resolves your API hostname to the cloud load balancer or Ingress IP.
- LB/Ingress forwards to a healthy node or directly to the Ingress Pod.
- nginx matches host/path rules and proxies to a ClusterIP Service.
- kube-proxy / data plane load-balances to Endpoints (Pod IPs) for that Service.
- 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.
- NestJS Microservice Starter Kit
Production NestJS microservices — API gateway, Keycloak SSO, RabbitMQ, Docker, Kubernetes, and Terraform.
- Enterprise SaaS Microservices Boilerplate
Full multi-tenant SaaS control plane as NestJS microservices — service-per-DB, billing, audit, notifications.
- Multi-Tenant SaaS Boilerplate
Best-seller NestJS multi-tenant SaaS boilerplate — one API, per-tenant databases, billing, and Keycloak SSO.