A cluster with five web services would require five separate LoadBalancer Services, each with its own cloud load balancer and IP address — costly and complex to manage. Ingress solves this problem: a single Ingress controller (typically nginx or a cloud-native controller) receives all external HTTP/HTTPS traffic and routes it to the correct internal Service based on the hostname, path, or other HTTP attributes. Ingress is an HTTP-aware layer 7 router sitting in front of all your Services, enabling path-based routing (api.cricketpulse.com/v1 → cricketpulse-api Service, api.cricketpulse.com/scores → cricketpulse-scores Service), host-based routing (api.cricketpulse.com → backend, www.cricketpulse.com → frontend), SSL termination, authentication, and rate limiting — all configured through a simple YAML object rather than managing individual load balancers.
35 minintermediate
Ingress and Load Balancing
Analogy🏏Cricket
🏏 Think of it like cricket: A well-run cricket board has distinct departments with clear responsibilities: the selection committee chooses players, the grounds department prepares venues, the scheduling department assigns matches to grounds, the operations department manages logistics, and the referees enforce the rules. No department does another's job, and all communication flows through the central secretariat. Just as the ICC's effectiveness comes from each department having a clear mandate and working through a central coordination system, Kubernetes' reliability comes from each component (API server, scheduler, controller manager, etcd, kubelet, kube-proxy) having a single responsibility and communicating only through the API server as the central hub. The insight is that this architecture makes the system resilient: a failure in the scheduling department doesn't stop ongoing matches, just as a failing scheduler doesn't kill running Pods.
Lesson 10 of 24
0% complete