Many people start learning Kubernetes networking by jumping straight into:
- Pod
- Service
- Ingress
- CNI
- Flannel
- Calico
The more they learn, the more confused they become.
The real problem is:
Kubernetes networking is not a standalone system; it is an abstraction layer built on top of Linux networking.
If you do not understand Linux networking, concepts such as Pod, Service, and VXLAN all become black boxes.
1. Networking boils down to three core concepts
You can reduce the entire network model to three things:
设备
地址
转发
They correspond to:
设备：
网卡
交换机
路由器
地址：
MAC
IP
转发：
交换
路由
NAT
2. MAC and IP addresses
MAC addresses
MAC is a Layer 2 address.
00:11:22:33:44:55
It identifies a device within the same LAN.
IP addresses
IP is a Layer 3 address.
192.168.1.10
10.244.1.2
8.8.8.8
It identifies devices across networks.
3. Switches, ARP, and routers
A switch operates at Layer 2 and looks only at MAC addresses, not IP, TCP, or HTTP.
ARP is responsible for:
IP -> MAC
A router operates at Layer 3:
查看目标 IP
↓
查路由表
↓
决定下一跳
An example routing table:
ip route
192.168.1.0/24 dev eth0
default via 192.168.1.1
This means:
同网段直接发送
其他流量交给默认网关
4. NAT
Private addresses cannot be routed directly over the public network:
192.168.x.x
172.16.x.x
10.x.x.x
So the router performs SNAT:
SRC 192.168.1.10
↓
SRC 公网 IP
It also records connection mappings in conntrack, allowing the system to restore the original source information for return traffic.
5. Linux network namespaces
Namespaces are a Linux isolation mechanism.
A network namespace isolates an entire network stack:
网卡
IP
路由表
ARP 表
iptables
端口空间
So a container is not a virtual machine, but rather:
普通 Linux 进程
+
Namespace 隔离
+
Cgroups 限制
+
RootFS 文件系统
6. veth pairs
Linux provides veth pair to connect namespaces.
It works like a virtual network cable:
vethA <====> vethB
7. Linux bridges
A bridge is a software switch.
ContainerA
|
Bridge
|
ContainerB
It works just like a physical switch:
学习 MAC
查 MAC 表
转发数据帧
8. Docker networking
The default Docker network structure is:
Container
eth0
│
veth
│
docker0
│
Host
docker0 is a Linux bridge, and Docker also assigns it an IP address:
docker0 = 172.17.0.1
So docker0 acts as both the switch and the default gateway for containers.
Docker maintains its own IPAM:
172.17.0.0/16
Container IP addresses are usually assigned by Docker:
172.17.0.2
172.17.0.3
172.17.0.4
9. What is a Pod?
A Pod is not a container.
A Pod can contain multiple containers:
Pod
├── app
└── sidecar
The component that actually owns the network namespace is the pause container.
pause container
└── Network Namespace
app
└── 加入 pause 的 Network Namespace
sidecar
└── 加入 pause 的 Network Namespace
So multiple containers in the same Pod share:
IP
localhost
端口空间
10. Kubernetes networking on a single node
For example, many CNI plugins create a bridge similar to docker0 on a node:
cni0
The structure is:
PodA
|
veth
|
cni0
|
veth
|
PodB
When Pods on the same node communicate:
PodA ARP 查询 PodB MAC
↓
cni0 广播
↓
PodB 回复
↓
cni0 根据 MAC 表转发
This process is essentially Layer 2 switching.
11. What is CNI?
Kubernetes itself does not implement networking.
It uses CNI plugins to handle Pod networking.
Common CNI plugins include:
Flannel
Calico
Cilium
CNI is responsible for:
创建 veth
配置 IP
配置路由
接入 Bridge 或其他数据平面
维护跨节点通信
Pod IP addresses are usually assigned by the CNI's IPAM module, not automatically by Kubernetes or Linux.
12. Cross-node Pod communication
Suppose:
Node1
PodA = 10.244.1.2
Node2
PodB = 10.244.2.2
PodA accesses PodB:
10.244.1.2 -> 10.244.2.2
The question is:
Node1 怎么知道 10.244.2.0/24 在 Node2？
That is the problem CNI has to solve.
13. VXLAN
VXLAN is:
L2 Overlay over L3
In other words:
把二层网络封装到三层 IP 网络里面
The original Pod packet:
SRC 10.244.1.2
DST 10.244.2.2
After VXLAN encapsulation:
Outer IP:
SRC Node1IP
DST Node2IP
UDP
VXLAN Header
Inner IP:
SRC 10.244.1.2
DST 10.244.2.2
The packet structure is:
Outer Ethernet
Outer IP
UDP
VXLAN
Inner Ethernet
Inner IP
TCP
HTTP
The underlying physical network sees only:
Node1IP -> Node2IP
When Node2 receives the packet, it removes the VXLAN encapsulation and delivers the original Pod packet to PodB.
14. What is flannel.1?
flannel.1 is not a process.
It is a Linux VXLAN network device, similar to:
eth0
docker0
cni0
vethxxx
In the routing table:
10.244.2.0/24 dev flannel.1
This means:
去 10.244.2.0/24 的流量
交给 flannel.1 这个 VXLAN 设备处理
The Linux kernel then handles the VXLAN encapsulation.
flanneld is the actual process. It is responsible for:
创建 flannel.1
写路由表
维护 Node 和 PodCIDR 的映射
15. The essence of a Service
A Service provides a stable point of access.
For example:
Service IP = 10.96.0.10
However, this IP address usually is not assigned to any physical network interface.
At its core, a Service is:
虚拟 IP
+
iptables / IPVS 转发规则
16. kube-proxy
kube-proxy watches:
Service
Endpoint / EndpointSlice
Then it generates forwarding rules.
For example:
10.96.0.10:8080
↓ DNAT
10.244.1.2:8080
So when you access a Service, the actual sequence is:
访问 Service IP
↓
iptables / IPVS 命中规则
↓
DNAT 到某个后端 Pod IP
↓
通过 CNI 网络转发到目标 Pod
17. CoreDNS
When accessing a service name from inside a Pod:
curl user-service
Name resolution proceeds as follows:
user-service
↓
CoreDNS
↓
Service ClusterIP
↓
kube-proxy
↓
Pod IP
18. Ingress
Ingress is a set of rules, not an actual gateway process.
The component that actually handles traffic is the Ingress Controller. Examples include:
Nginx Ingress Controller
Traefik
APISIX
Kong
The path of an external request is:
Browser
↓
LoadBalancer / NodePort
↓
Ingress Controller
↓
Service
↓
Pod
Ingress Controllers are typically Layer 7 reverse proxies that can inspect:
Host
Path
TLS
HTTP Header
19. Putting the full chain together
Linux networking fundamentals:
MAC
↓
ARP
↓
交换机
↓
路由器
↓
路由表
↓
NAT
Container networking fundamentals:
Namespace
↓
veth
↓
Bridge
↓
IPAM
↓
Docker 网络
Kubernetes networking:
Pod
↓
CNI
↓
PodCIDR
↓
cni0 / route / eBPF
↓
VXLAN / BGP
↓
Service
↓
CoreDNS
↓
Ingress
20. Final conclusion
Kubernetes networking is not a brand-new system that appeared out of nowhere.
At its core, it is:
Linux 网络能力
+
CNI 自动化
+
Kubernetes 声明式编排
More specifically:
Kubernetes 网络
=
Namespace
+
veth
+
Bridge
+
Route
+
NAT
+
iptables / IPVS
+
VXLAN / BGP / eBPF
+
CNI
The right way to understand Kubernetes networking is not to memorize Pod, Service, and Ingress first. Start by understanding: