Kubernetes Service Types: ClusterIP vs NodePort vs LoadBalancer vs Ingress

Kubernetes has four ways to expose a Service, and the choice determines who can reach it and how traffic enters. Most teams never use NodePort in production; they use ClusterIP for internal services and a LoadBalancer-backed Ingress for external traffic.

ClusterIP — internal cluster communication

• Default; creates a virtual IP reachable only inside the cluster; services talk via DNS — payment-service.default.svc.cluster.local resolves via CoreDNS to the ClusterIP.
• Correct for every service that should not be externally reachable — databases, internal APIs, caches; anything higher is a security exposure.

NodePort — fixed port on every node

• Opens a port 30000–32767 on every node's IP; traffic to any-node-ip:nodeport reaches the Service — useful for minikube and bare-metal, not for production.
• Production concerns: direct node IP exposure, inconvenient port range, node IP changes on restart; NodePort is rarely right for prod external traffic.

LoadBalancer — cloud LB per service

• type: LoadBalancer provisions a cloud LB on EKS/GKE/AKS; traffic enters through the LB's external IP.
• Cost issue: one LB per Service at $20–100/month each is expensive for a cluster with 20 services — this is exactly what Ingress solves.
• Right choice for a single non-HTTP service (raw TCP, gRPC where Ingress doesn't handle it) or when you need a dedicated L4 LB with specific DNS/IP.

Ingress — one LB, many services

• An Ingress resource defines HTTP(S) routing rules (path- or host-based) to multiple backends behind a single cloud LB running the Ingress controller (NGINX, AWS ALB, Traefik).
• Handles TLS termination with certs from cert-manager — the controller presents the right cert and routes decrypted traffic to the backend; services remain ClusterIP.
• The controller must be installed separately — this is the piece most teams forget on a fresh cluster.

Gateway API — the successor

• GA in Kubernetes 1.29; more expressive than Ingress, supports HTTP / TCP / UDP / gRPC, separates platform role (Gateway) from app owner role (HTTPRoute).
• If starting fresh, prefer Gateway API; if existing NGINX Ingress is stable, migration is not urgent but planned.

Common pitfalls

• Sticky sessions break when Ingress hides client IP — use cookie-based affinity or externalTrafficPolicy: Local if you need client IP.
• gRPC requires backend-protocol: GRPC annotation or a service mesh — plain HTTP/1.1 Ingress silently breaks gRPC streams.
• Rate limiting via NGINX annotations is basic; for production security add Cloudflare, AWS WAF, or an Istio envoy filter.