Kubernetes Networking
25 min
Day 57: Services: ClusterIP, NodePort, LoadBalancer
The problem Services solve
Pods are ephemeral — they get new IPs every time they're recreated. A Service gives a stable virtual IP and DNS name in front of a changing set of Pods, selected by label — so nothing else in the cluster needs to track individual Pod IPs.
- ClusterIP (default) — a virtual IP reachable only from inside the cluster
- NodePort — additionally exposes the Service on a static port on every node's IP, for external access without a cloud load balancer
- LoadBalancer — asks the cloud provider to provision a real external load balancer pointing at the Service (this is what ALB/NLB provisioning in Phase 20 plugs into)
A ClusterIP Service selecting Pods by label
apiVersion: v1
kind: Service
metadata:
name: api
spec:
selector:
app: api
ports:
- port: 80
targetPort: 3000Services aren't magic — they're label selectors plus kube-proxy
A Service is really just: 'route to any Pod whose labels match this selector.' kube-proxy (running on every node) watches Services and Endpoints and programs the node's networking rules (iptables or IPVS) to actually load-balance traffic — this is the plumbing that makes the virtual IP work.
Key terms
- Service
- A stable virtual IP/DNS name load-balancing traffic across a changing set of Pods matched by label.
- kube-proxy
- The per-node component that programs networking rules to implement Service load balancing.
Why do other Pods talk to a Service's virtual IP instead of individual Pod IPs directly?
