0 / 15 lessons — 0%
Lesson 05 / 15
Services & networking
Pods are mortal — they get replaced constantly, and every replacement gets a brand-new IP address. So how does anything else reliably find "the web app" if its address keeps changing? That's what a Service is for: a stable name and IP that load-balances across whichever Pods currently match its label selector.
| Type | Reachable from | Typical use |
|---|---|---|
ClusterIP (default) | Only inside the cluster | Internal services — a backend talking to another backend |
NodePort | Any node's IP, on a fixed port | Quick external access, mostly for testing |
LoadBalancer | A public IP, provisioned by your cloud | Production external access on AWS/Azure/GCP |
# service.yaml — targets any pod labeled app: web apiVersion: v1 kind: Service metadata: name: web spec: selector: app: web ports: - port: 80 targetPort: 3000 type: ClusterIP
kubectl apply -f service.yaml kubectl get svc web kubectl get endpoints web # the actual pod IPs it's currently balancing across
Same trick as Docker Compose, one level up: just like Compose containers reach each other by service name, other Pods reach this Service at
web (or web.namespace.svc.cluster.local in full) — Kubernetes' internal DNS resolves it, no IP addresses required.Try it yourselfApply the Deployment from lesson 4 and this Service, then from a temporary debug pod (
kubectl run tmp --rm -it --image=busybox -- sh) run wget -qO- web. Kill and recreate one of the web Pods mid-experiment — the Service keeps working without you touching it.