Services & Ingress
Docker & Kubernetes for Interviews: lesson 7 of 12
A stable name in front of Pods that come and go, and one front door for HTTP.
Lesson 7 of 12 · 7 min
Services & Ingress
Step 1 of 12
Pods come and go, and their IPs change with them. No client should chase addresses.
The Idea
Pods come and go, and their IPs with them. A Service picks a set of Pods by label and gives them one stable virtual IP and DNS name, and Kubernetes keeps its endpoints current. ClusterIP, the default, is internal only; NodePort also opens a static port on every node; LoadBalancer asks the cloud provider for an external load balancer.
Real-World Example
Web Pods call the name api — the Service's DNS name in their namespace — and requests spread over whichever api Pods are ready. One Ingress routes shop.example.com/api to the api Service and everything else to web, terminating TLS once.
The Tradeoff
An Ingress does nothing without an Ingress controller, and it only carries HTTP and HTTPS; other protocols need NodePort or LoadBalancer. The Ingress API is frozen, and the project recommends Gateway API for new work.
Hands-On
# illustrative — a ClusterIP Service in front of the api Pods
apiVersion: v1
kind: Service
metadata: { name: api }
spec:
selector: { app: api }
ports: [{ port: 80, targetPort: 8000 }]
# then: kubectl get endpointslices -l kubernetes.io/service-name=api
Your turn
Put the steps in the right order.
- The Ingress controller matches the host and path rule
- A browser requests shop.example.com/api
- The Service sends it to one ready api Pod
- The controller forwards it to the api Service
Mini quiz
1 / 3
The default Service type is:
Sources
- Service — Kubernetes Documentation
- Ingress — Kubernetes Documentation
- DNS for Services and Pods — Kubernetes Documentation
- Gateway API — Kubernetes Documentation