A LoadBalancer Service creates one cloud load balancer per Service — the correct model for TCP/UDP workloads where each service needs its own external IP and port. For HTTP/HTTPS services, this approach becomes expensive and operationally unwieldy as the number of services grows: twenty HTTP microservices should not require twenty separate AWS NLBs with twenty public IPs, twenty TLS certificates, and twenty DNS entries. An Ingress resource solves this by describing HTTP routing rules — 'requests to `api.ipl.example.com/batters` go to Service `ipl-api` on port 8000, requests to `admin.ipl.example.com` go to Service `ipl-admin` on port 8080' — and an IngressController (Nginx Ingress, AWS ALB Ingress, Traefik) reads these rules and implements them by configuring a single shared load balancer with path-based or host-based routing. Cert-manager automates TLS certificate provisioning and renewal using ACME (Let's Encrypt), creating certificates automatically when Ingress resources with TLS annotations are created and renewing them before expiry without any human intervention.
25 minintermediate
Ingress and IngressControllers — HTTP routing, TLS termination and cert-manager
Analogy🏏Cricket
🏏 Think of it like cricket: The Pod-ReplicaSet-Deployment hierarchy maps precisely onto the three levels of IPL franchise team management. A Pod is a single player on the field at a given moment — the smallest unit of participation, carrying its own identity and fulfilling a specific role in the current game. A ReplicaSet is the franchise's match-day playing XI contract — it specifies that exactly eleven players matching a specific profile must always be on the field; if one is injured and leaves, the team management immediately sends a substitute of the same profile to restore the count. A Deployment is the franchise's season-long team strategy — it manages how the playing XI evolves between matches: when a new batting approach is adopted, the Deployment replaces the old XI with the new one in a controlled rolling substitution rather than swapping all eleven players simultaneously and disrupting team cohesion. Just as the franchise director does not manage individual players directly — the playing XI contract (ReplicaSet) handles the count and the season strategy (Deployment) handles the transitions — you never manage Pods directly in production; the Deployment manages the transition and the ReplicaSet maintains the count. This reveals why the three-level hierarchy exists rather than one omnibus 'workload' object: each level solves one specific problem, and composing three focused abstractions produces better separation of concerns than one object that conflates scheduling, scaling, and update management.
Lesson 19 of 33
0% complete