Today I had a small discussion with some friends about Kubernetes networking. We talked about how Kubernetes manages IP addresses, how Services work, and why a Service needs its own dedicated IP address even when traffic is coming through a Load Balancer.
When people start learning Kubernetes, they often hear words like Service, Load Balancer, Ingress, Gateway API, Service Mesh, and Istio. At first, these terms sound complicated.
Let's imagine Kubernetes is a big city.
The Kubernetes City
Imagine a city full of buildings. Each building is a Kubernetes Pod. Inside each building lives an application.
Some buildings get rebuilt frequently, so their addresses change all the time. This creates a problem: how can people find the right building if the address keeps changing?
That's where Kubernetes networking comes in.
Main path (solid): User → Internet → Load Balancer → Gateway API/Ingress → Services → Pods. Dashed lines show Service Mesh traffic between services inside the cluster.
1. Service: The Reception Desk
Imagine ten workers are doing the same job in ten different buildings. Instead of remembering every building address, visitors go to a reception desk. The receptionist sends them to an available worker.
- Pods are workers
- Service is a receptionist
A Service gives Pods one stable address. Even if Pods are destroyed and recreated, users keep talking to the Service.
Think: Service is a stable address for changing Pods.
2. Load Balancer: The Traffic Police
Now imagine thousands of people arrive at the city. If everyone enters through one road, traffic becomes terrible. A traffic police officer directs cars to different roads.
- Load Balancer distributes traffic
- Requests are shared across multiple Pods
Without it: All traffic may hit one Pod.
With it: Traffic is spread evenly.
Think: Load Balancer = Traffic police.
3. Ingress: The City Gate (Older Way)
Suppose your city has many businesses: shop.ajrly.com, api.ajrly.com, and blog.ajrly.com. You don't want a separate entrance gate for every business. Instead, you build one large city gate. The guard looks at the destination and sends visitors to the correct building.
This is what Ingress does.
- api.ajrly.com → API Service
- blog.ajrly.com → Blog Service
- app.ajrly.com → Web App Service
Think: Ingress is one entrance for many applications.
Why is it becoming less popular?
Ingress was designed years ago and has limitations. The Kubernetes community now recommends Gateway API for new projects.
4. Gateway API: The Modern Smart Gate
Gateway API is the next generation of Ingress. Imagine replacing an old gate guard with a modern airport system. Now you can create multiple gates, define different rules, separate responsibilities, and manage traffic more easily.
- More flexible
- Easier to manage at scale
- Better for large organizations
Ingress is Old city gate
Gateway API is Smart modern airport
5. Service Mesh: The City's Internal Road System
Everything so far focused on people entering the city. But what about communication inside the city?
Imagine Building A talks to Building B, Building B talks to Building C, and Building C talks to Building D. Now you want encryption, security, traffic monitoring, access control, and reliability.
You could add this logic to every application — but that's a lot of work. Instead, the city builds smart roads that handle these things automatically. This is a Service Mesh.
Think: Service Mesh = Smart roads inside the city.
6. Istio: The Most Popular Service Mesh
Istio is one of the most widely used Service Mesh solutions. It adds features such as mTLS encryption, traffic routing, canary deployments, observability, and service-to-service security.
Example: you can send 90% of traffic to Version 1 and 10% to Version 2 without changing application code.
Think: Istio is an advanced traffic control system for the city.
7. Open Service Mesh (OSM)
OSM is another Service Mesh project. Compared with Istio, OSM tries to be simpler, easier to learn, and lighter weight. Istio tries to provide more features, more integrations, and more enterprise capabilities.
OSM is Small city traffic system
Istio is International airport traffic control
Quick Summary
Pod — Building
Service — Reception Desk
Load Balancer — Traffic Police
Ingress — Old City Gate
Gateway API — Modern Smart Airport
Service Mesh — Internal Smart Roads
Istio — Advanced Traffic Control System
OSM — Lightweight Traffic Control System
Final Rule
Remember this simple order:
- Pods run applications.
- Services find Pods.
- Load Balancers expose applications.
- Ingress/Gateway API manage incoming traffic.
- Service Mesh manages internal traffic.
- Istio and OSM are Service Mesh implementations.
If you understand the city analogy, you already understand the big picture of Kubernetes networking.