Kubernetes networking is designed around one core idea:
Every pod can directly communicate with every other pod using IP addresses, without NAT inside the cluster.
That leads to a simple mental model:
- Pods = actual running application containers
- Services = stable access points/load balancers for pods
- Ingress = HTTP/HTTPS entry gateway into the cluster
- NetworkPolicies = firewall rules between pods
- CNI plugins = the technology that creates the network
- kube-proxy = traffic router for Services
- CoreDNS = internal DNS system
1. Pod Networking Model
Core Kubernetes Rule
Every pod gets:
- its own IP address
- ability to talk to every other pod directly
Example:
| Pod | IP |
|---|---|
| frontend-pod | 10.1.1.5 |
| backend-pod | 10.1.2.8 |
| db-pod | 10.1.3.2 |
The frontend pod can directly call:
http://10.1.2.8
without NAT or port mapping.
2. What is a “Flat Network”?
This statement:
Pods communicate using a flat network model
means:
All pods appear to be on one shared network
Even if they are on different nodes.
Example
Suppose:
| Node | Pod | IP |
|---|---|---|
| Worker-1 | frontend | 10.1.1.5 |
| Worker-2 | backend | 10.1.2.8 |
Even though pods are on different machines:
frontend ---> backend
works directly using pod IP.
The frontend pod does NOT need:
- NAT
- port forwarding
- special routing logic
This is called a flat network because all pod IPs belong to one logical address space.
Analogy
Imagine every employee in a company has a direct extension number.
You can call anyone directly regardless of building.
That is a flat network.
3. Why Kubernetes Needs CNI
Kubernetes itself does NOT implement networking.
Instead, it delegates networking to:
CNI
(Container Network Interface)
CNI plugins create the actual pod networking.
4. What CNI Plugins Do
A CNI plugin:
- assigns IP addresses to pods
- creates virtual interfaces
- configures routes
- enables pod-to-pod communication
- may enforce NetworkPolicies
Popular CNI Plugins
| Plugin | Features |
|---|---|
| Calico | Routing + NetworkPolicies |
| Flannel | Simple overlay networking |
| Cilium | eBPF-based advanced networking |
| Weave | Easy setup overlay network |
Examples:
- Calico
- Flannel
- Cilium
- Weave Net
5. Overlay Networking
Overlay networking is commonly used by CNI plugins.
Problem
Pods on different nodes may exist on different physical networks.
Example:
| Node | Physical IP |
|---|---|
| Node1 | 192.168.1.10 |
| Node2 | 192.168.1.20 |
But pods use virtual IP ranges:
| Pod | Pod IP |
|---|---|
| frontend | 10.1.1.5 |
| backend | 10.1.2.8 |
The physical network does not understand pod IPs.
Solution: Overlay Network
CNI plugins create a virtual network over the physical network.
Packets are encapsulated/tunneled between nodes.
Example technologies:
- VXLAN
- IP-in-IP
- Geneve
Analogy
Think of overlay networking like:
creating a private virtual road system on top of real highways.
Pods think they are directly connected.
6. Services
Pods are temporary.
If a pod dies:
- its IP changes
- a new pod may be created elsewhere
Applications need a stable endpoint.
That is what a Kubernetes Service provides.
7. What a Service Does
A Service:
- gives a stable virtual IP
- load balances traffic
- routes traffic to matching pods
Example:
Service: backend-service
↓
backend-pod-1
backend-pod-2
backend-pod-3
Clients talk to:
backend-service
instead of individual pod IPs.
Service Types
| Type | Purpose |
|---|---|
| ClusterIP | Internal cluster access |
| NodePort | Expose via node port |
| LoadBalancer | Cloud external load balancer |
| ExternalName | DNS alias |
8. kube-proxy
Now the important question:
How does a Service actually route traffic?
That is handled by:
kube-proxy
kube-proxy Responsibilities
kube-proxy runs on every node and:
- watches Services and Endpoints
- creates routing rules
- load balances traffic to pods
Example
You send traffic to:
backend-service:80
kube-proxy decides:
→ backend-pod-2:8080
Technologies Used
kube-proxy may use:
| Mode | Description |
|---|---|
| iptables | Linux packet rules |
| IPVS | Advanced load balancing |
| userspace | Older method |
9. DNS in Kubernetes
Remembering pod IPs is impossible.
So Kubernetes provides internal DNS.
This is handled by:
CoreDNS
Example:
- CoreDNS
10. What CoreDNS Does
CoreDNS automatically creates DNS records for Services and Pods.
Example:
backend-service.default.svc.cluster.local
resolves to the Service IP.
Applications usually just use:
http://backend-service
Example Flow
frontend pod
↓ DNS query
CoreDNS
↓ returns Service IP
backend-service → 10.96.0.10
↓
kube-proxy routes traffic
↓
backend pod
11. Ingress
Services expose applications.
But exposing MANY services externally becomes messy.
Example:
| Service | Port |
|---|---|
| app1 | 30001 |
| app2 | 30002 |
| app3 | 30003 |
Ingress solves this.
12. What Ingress Does
Ingress is an HTTP/HTTPS routing layer.
It routes external traffic to Services.
Example:
example.com/api → api-service
example.com/web → web-service
Important
Ingress works at:
- HTTP layer (Layer 7)
It can:
- route by hostname
- route by URL path
- terminate TLS/SSL
- provide HTTPS
Ingress Controller
Ingress rules need an implementation.
Common controllers:
- NGINX Ingress Controller
- Traefik
- HAProxy Ingress
Examples:
- NGINX Ingress Controller
- Traefik
13. NetworkPolicies
By default:
all pods can usually talk to all other pods
This may be insecure.
NetworkPolicies act like Kubernetes firewalls.
14. What NetworkPolicies Control
They define:
- which pods may communicate
- allowed ingress traffic
- allowed egress traffic
Example
Allow only frontend → backend
frontend pod ✅ backend
random pod ❌ backend
Important Detail
NetworkPolicies only work if:
- your CNI plugin supports them
Example:
- Calico supports them
- Flannel alone does not fully support them
15. Full End-to-End Flow
Here is the complete picture:
Internet User
↓
Ingress
↓
Service
↓
kube-proxy
↓
Backend Pods
Meanwhile:
- CoreDNS resolves names
- CNI provides networking
- Overlay networking connects nodes
- NetworkPolicies secure traffic
16. One-Sentence Summary of Each Component
| Component | Purpose |
|---|---|
| Pod | Running application unit |
| Flat Network | All pods can directly reach each other |
| CNI | Implements Kubernetes networking |
| Overlay Network | Virtual pod network across nodes |
| Service | Stable access/load balancing for pods |
| kube-proxy | Routes Service traffic to pods |
| CoreDNS | Internal DNS for Services/pods |
| Ingress | HTTP/HTTPS external routing |
| NetworkPolicy | Firewall rules for pods |
A very useful way to visualize Kubernetes networking:
Pods = computers
Services = load balancers
Ingress = reverse proxy/API gateway
CoreDNS = DNS server
NetworkPolicies = firewall
CNI = network infrastructure
kube-proxy = traffic router
No comments:
Post a Comment