一、为什么需要Overlay网络？
想象一下你管理着一个由几十台服务器组成的Kubernetes集群。每台服务器上运行着不同的Pod（可以理解成集装箱），这些Pod需要互相通信。但问题来了：不同服务器上的Pod可能使用相同的IP地址范围，就像两个小区都用"1号楼"来命名，快递员会完全搞不清楚该送到哪里。
这就是Overlay网络要解决的问题。它像在这些服务器之间架设了一条专用隧道，让不同主机上的Pod能够直接通信，就像它们都在同一个局域网里一样。最常见的两种隧道技术就是VXLAN和GRE。
二、VXLAN隧道详解
VXLAN（Virtual Extensible LAN）就像给网络数据包穿了一件"马甲"。它把原始的网络包整个打包，加上新的源目地址，这样就能跨过底层网络传输了。
技术栈：Kubernetes + Flannel(VXLAN模式)
# flannel配置示例 (kube-flannel.yml)
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
---
# 特别注意这里的网络配置
net-conf.json: |
{
"Network": "10.244.0.0/16", # 整个集群的Pod IP范围
"Backend": {
"Type": "vxlan", # 使用VXLAN模式
"VNI": 1, # 虚拟网络标识符
"Port": 8472 # UDP端口号
}
}
这段配置告诉Flannel：
- 为所有Pod分配10.244.0.0/16范围内的IP
- 使用VXLAN创建虚拟网络
- 通过UDP 8472端口通信
实际传输时，数据包会被这样封装：
[ 外部UDP头 ][ VXLAN头 ][ 原始以太网帧 ]
三、GRE隧道方案
GRE（Generic Routing Encapsulation）是另一种隧道技术，它比VXLAN更简单直接，就像用透明胶带把两个网络粘在一起。
技术栈：Kubernetes + Calico(GRE模式)
# calico配置示例 (calico.yaml)
apiVersion: crd.projectcalico.org/v1
kind: IPPool
metadata:
name: default-ipv4-ippool
spec:
cidr: 192.168.0.0/16 # Pod使用的IP范围
ipipMode: Always # 启用GRE隧道
natOutgoing: true # 允许Pod访问集群外部
关键区别：
- GRE没有VXLAN的复杂头部，性能略好
- 但缺少VXLAN的扩展字段（如VNI）
- 通常使用IP协议号47，不依赖UDP端口
四、典型应用场景对比
场景1：跨机房部署
- VXLAN更适合，因为它的24位VNI可以支持1600万个虚拟网络
- 示例：在北京和上海机房部署同一个Kubernetes集群
场景2：高性能计算
- GRE可能更合适，因为封装开销更小
- 示例：机器学习训练集群中Worker节点间的通信
场景3：混合云环境
- VXLAN更常用，因为主流云厂商都支持
- 示例：AWS EKS + 本地数据中心的混合部署
五、性能调优技巧
- MTU设置：隧道会增加包头大小，通常需要调小MTU
# 查看当前MTU值
ip link show flannel.1 | grep mtu
# 设置MTU（通常在1450左右）
ifconfig flannel.1 mtu 1450
- 网络策略优化：避免不必要的跨节点通信
# 示例：让前端Pod尽量调度到同节点
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values: ["frontend"]
topologyKey: "kubernetes.io/hostname"
六、常见问题排查
问题1：Pod间无法ping通 检查步骤：
- 确认隧道接口已启动
ip addr show flannel.1 # 对于VXLAN
ip addr show tunl0 # 对于GRE
- 检查路由表
route -n
# 应该能看到类似这样的路由
# 10.244.1.0/24 via 10.244.1.0 dev flannel.1
问题2：网络延迟高 可能原因：
- 封装/解封装消耗CPU
top -p $(pgrep flanneld) # 查看flannel进程CPU使用率
七、技术选型建议
- 选择VXLAN当：
- 需要支持多租户隔离
- 预计会扩展到大规模集群
- 运行在异构网络环境中
- 选择GRE当：
- 追求极致性能
- 网络环境简单统一
- 不需要高级网络功能
八、安全注意事项
- 加密问题：原生VXLAN/GRE都不加密
# 解决方案：使用IPsec加密
# flannel配置示例
net-conf.json: |
{
"EnableIPv4": true,
"Backend": {
"Type": "vxlan",
"VNI": 1,
"Port": 8472,
"PSK": "MySecretKey" # 预共享密钥
}
}
- 网络隔离：即使使用隧道，也要配置NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: db-isolation
spec:
podSelector:
matchLabels:
role: db
ingress:
- from:
- podSelector:
matchLabels:
role: api
九、未来发展趋势
- eBPF技术正在改变网络栈的实现方式
- Cilium等项目开始提供基于eBPF的替代方案
- 服务网格(Service Mesh)与网络层的融合
十、总结回顾
Overlay网络就像给Kubernetes集群搭建的"立交桥系统"，让Pod可以无视底层网络差异自由通信。VXLAN和GRE是两种主要的技术方案：
- VXLAN功能更丰富，适合复杂场景
- GRE更轻量，适合性能敏感场景
- 实际选择要考虑团队熟悉度、网络规模等因素
无论选择哪种方案，都要记得：
- 提前规划IP地址空间
- 关注MTU等细节配置
- 不要忽视网络安全设置
评论