Kubernetes Networking Explained: From Inside a Pod to Ingress, Load Balancer, and API Gateway
Exploring and building innovative tech solutions for the future while documenting the insights and knowledge gained along the way.
Kubernetes networking is one of the most important concepts for DevOps engineers. Many beginners understand Pods and containers but get confused about how traffic actually travels through a Kubernetes cluster.
In this article, we will understand the complete networking flow in Kubernetes, starting from:
Container → Pod → CNI → Node → Service → Ingress → Load Balancer → API Gateway → Internet
By the end of this blog, you will clearly understand how a request from a user reaches a container inside a Pod.
1. Container Networking (Inside a Pod)
A Kubernetes Pod can contain one or more containers.
All containers inside the same Pod share the same network namespace, which means they share:
The same IP address
The same network interface
The same port space
Because of this, containers communicate with each other using localhost.
Example
Container A runs an API on port 5000.
Container B can access it like this:
localhost:5000
Key rule:
Containers in the same Pod communicate using localhost.
2. Pod Networking
Every Pod in Kubernetes gets its own IP address.
Example:
Pod A → 10.244.1.5
Pod B → 10.244.2.8
Pod C → 10.244.3.2
Pods communicate directly with each other using their Pod IPs.
Example:
curl 10.244.2.8:8080
Important Kubernetes networking rule:
Every Pod can communicate with every other Pod without NAT.
3. CNI (Container Network Interface)
Kubernetes itself does not implement networking. Instead, it uses CNI plugins.
CNI stands for Container Network Interface.
CNI plugins are responsible for:
Assigning IP addresses to Pods
Connecting Pods to the cluster network
Managing routing between nodes
Enabling Pod-to-Pod communication
Popular CNI plugins include:
Calico
Flannel
Weave Net
Cilium
Simplified Flow
Pod → CNI Plugin → Node Network → Other Node → Pod
CNI makes sure Pods on different nodes can still communicate.
4. Node Networking
A Node is a machine where Pods run. It can be:
A Virtual Machine
A Physical Server
Each node has:
A Node IP
kube-proxy
container runtime
network interfaces
Example cluster:
Node1 → 192.168.1.10
Node2 → 192.168.1.11
Pods running on nodes:
Node1
├ Pod A (10.244.1.5)
├ Pod B (10.244.1.6)
Node2
├ Pod C (10.244.2.3)
CNI handles routing between nodes so that Pods on different nodes can communicate.
5. Kubernetes Service (Stable Access to Pods)
Pods are ephemeral. If a Pod crashes and restarts, its IP address may change.
To solve this problem, Kubernetes introduces Services.
A Service provides a stable IP address and DNS name for a group of Pods.
Example Service:
Name: user-service
ClusterIP: 10.96.45.12
Traffic flow:
Client → Service → Pod
Example request:
curl user-service:8080
The Service automatically load balances traffic across multiple Pods.
Example:
user-service
├ Pod A
├ Pod B
├ Pod C
6. kube-proxy (Traffic Routing)
kube-proxy runs on every Kubernetes node.
Its job is to manage network rules for Services.
It uses technologies like:
iptables
IPVS
Example routing rule:
Service IP → Pod1
Service IP → Pod2
Service IP → Pod3
Traffic flow:
Client → Service IP → kube-proxy → Pod
kube-proxy ensures traffic is distributed across available Pods.
7. Types of Kubernetes Services
Kubernetes provides different Service types depending on how you want to expose your application.
ClusterIP (Default):
Internal communication only.
Example:
Frontend Pod → Backend Service → Backend Pod
Used for microservice communication inside the cluster.
NodePort:
Exposes a service on a port of every node.
Example:
NodeIP:30080
Traffic flow:
Internet
↓
NodeIP:30080
↓
Service
↓
Pods
LoadBalancer:
Creates an external load balancer in cloud environments.
Example in AWS:
AWS ELB
↓
NodePort
↓
Service
↓
Pods
This is commonly used in production environments.
8. Ingress (HTTP Routing Layer)
Ingress is used for HTTP/HTTPS routing.
Instead of exposing many services separately, Ingress allows routing based on domains and paths.
Example:
example.com/api
example.com/app
Traffic flow:
Internet
↓
Load Balancer
↓
Ingress Controller
↓
Service
↓
Pods
Example routing rule:
example.com/api → api-service
example.com/web → web-service
Popular Ingress Controllers include:
NGINX Ingress
Traefik
HAProxy
AWS ALB Ingress
9. External Load Balancer
In cloud environments, Kubernetes integrates with cloud load balancers.
Examples:
AWS Elastic Load Balancer
Google Cloud Load Balancer
Azure Load Balancer
Traffic flow:
User
↓
Cloud LoadBalancer
↓
Ingress Controller
↓
Service
↓
Pod
The load balancer distributes traffic across nodes.
10. API Gateway (Optional Layer)
Large-scale architectures often place an API Gateway before Kubernetes.
Examples:
Kong
AWS API Gateway
Apigee
Ambassador
API Gateways provide:
Authentication
Rate limiting
Security policies
Logging and monitoring
Request transformation
Traffic flow:
User
↓
API Gateway
↓
Load Balancer
↓
Ingress
↓
Service
↓
Pod
Complete End-to-End Request Flow
Here is how a real request travels through the Kubernetes networking stack.
Example request:
https://myapp.com/login
Flow:
Browser
↓
API Gateway
↓
Cloud Load Balancer
↓
Ingress Controller
↓
Kubernetes Service
↓
kube-proxy
↓
Pod IP
↓
Container
The response then travels back through the same path.
The 5 Golden Rules of Kubernetes Networking
Every Pod gets its own IP address.
Pods can communicate directly without NAT.
Containers inside a Pod communicate using localhost.
Services provide stable access to Pods.
Ingress exposes HTTP routes to the outside world.
Final Thoughts
Understanding Kubernetes networking is essential for anyone working in DevOps, Cloud Engineering, or Platform Engineering.
Once you understand the flow:
Container → Pod → CNI → Node → Service → Ingress → Load Balancer → API Gateway
the entire Kubernetes networking architecture becomes much easier to reason about.
Please refer to following digram explaining network for kubernates
Interview-Level Kubernetes Networking Questions
These are very common DevOps / Kubernetes interview questions.
1. Why do containers inside the same Pod communicate using localhost?
Because containers inside a Pod share the same network namespace, meaning:
Same IP
Same network interface
Same port space
2. What is CNI in Kubernetes?
CNI (Container Network Interface) is a framework used to configure networking for containers.
Responsibilities:
Assign Pod IP addresses
Connect Pods to cluster network
Handle routing between nodes
Examples:
Calico
Flannel
Cilium
3. What are the main rules of Kubernetes networking?
The Kubernetes networking model defines:
Every Pod gets its own IP.
Pods can communicate with each other directly.
Containers in a Pod share network namespace.
No NAT is required between Pods.
4. What problem does a Kubernetes Service solve?
Pods are ephemeral.
If a Pod restarts:
Old Pod IP → gone
New Pod IP → created
Service provides:
Stable IP
DNS name
Load balancing
Example:
backend-service.default.svc.cluster.local
5. What is kube-proxy?
kube-proxy is a network component running on each node.
It manages routing rules using:
iptables
IPVS
It forwards traffic from Service → Pods.
6. Difference between ClusterIP, NodePort, and LoadBalancer
| Service Type | Access | Use Case |
|---|---|---|
| ClusterIP | Internal only | Microservices communication |
| NodePort | Node IP + port | Testing / simple exposure |
| LoadBalancer | External cloud LB | Production access |
7. What is Ingress in Kubernetes?
Ingress is a Layer 7 HTTP/HTTPS router that exposes services using:
domain names
paths
SSL
Example:
example.com/api → api-service
example.com/web → web-service
8. What is the difference between Ingress and LoadBalancer?
| Feature | Ingress | LoadBalancer |
|---|---|---|
| Layer | Layer 7 | Layer 4 |
| Routing | Host/path based | Port based |
| Use case | Multiple services | Single service |
9. How do Pods communicate across nodes?
Using CNI networking.
Example flow:
Pod A (Node1)
↓
CNI routing
↓
Node network
↓
CNI
↓
Pod B (Node2)
10. What happens when a request comes from the internet?
Full flow:
Internet
↓
Load Balancer
↓
Ingress
↓
Service
↓
kube-proxy
↓
Pod
↓
Container
✅ Tip for Interviews
Remember this order:
Container → Pod → CNI → Node → Service → Ingress → LoadBalancer → API Gateway
