引言:为什么 Kubernetes 需要网络插件?
在 Kubernetes 集群中,网络通信面临着两大核心挑战:
-
Pod 间直接通信:如何让集群中的任意两个 Pod 能够直接通信,无论它们是否在同一个节点上
-
服务发现与负载均衡:如何通过 Service 抽象实现流量的智能转发
这就好比在一个大型办公楼中,需要解决"办公室间直接通信"和"前台服务转接"的问题。Calico 和 Flannel 这类 CNI(容器网络接口)插件,正是为了解决第一个问题而生。
一、Kubernetes 网络基础架构演进
传统架构(v1.23 及之前)
kubelet → dockershim → Docker daemon → containerd → CNI插件 → Pods
-
依赖 Docker 的 docker0 网桥
-
网络栈相对复杂,存在冗余层
现代架构(v1.24 及之后)
kubelet → containerd/CRI-O → CNI插件 → Pods
-
移除 dockershim,更简洁的架构
-
CNI 插件直接管理容器网络
二、Flannel:简单高效的覆盖网络解决方案
核心原理
Flannel 采用 Overlay Network(覆盖网络) 技术,通过隧道封装实现跨节点 Pod 通信。
地址管理
# Flannel 的典型网络配置
Network: 10.244.0.0/16 # 集群总网段
SubnetLen: 24 # 每个节点的子网大小
SubnetMin: 10.244.1.0 # 起始子网
SubnetMax: 10.244.255.0 # 结束子网
数据流向(VXLAN 模式)
Pod A (10.244.1.2) → flanneld → 封装(VXLAN) → 物理网络 → flanneld → 解封装 → Pod B (10.244.2.3)
工作流程详解
-
地址分配:Flannel 为每个节点分配唯一的子网段
-
隧道建立:在节点间创建虚拟网络隧道
-
数据封装:将原始数据包封装在宿主机的网络包中
-
路由转发:通过底层网络传输到目标节点
-
数据解封:目标节点解封装并交付给目标 Pod
优缺点分析
优点:
-
部署简单,配置门槛低
-
对底层网络要求低,兼容性好
-
社区成熟,稳定性高
缺点:
-
封装解封装带来性能开销
-
网络策略功能有限
-
大规模集群性能表现一般
三、Calico:高性能的BGP路由方案
核心原理
Calico 利用 BGP(边界网关协议) 实现路由分发,追求零封装或最小封装的直接路由。
BGP 协议基础
-
自治系统(AS):每个节点可视为一个独立的网络系统
-
路由广播:节点间互相通告 Pod 路由信息
-
路径选择:基于最短路径等算法优化路由
数据流向(BGP 模式)
Pod A (10.244.1.2) → calico vRouter → 路由表查询 → 物理网络 → calico vRouter → Pod B (10.244.2.3)
工作流程详解
-
IPAM管理:Calico 分配真实的 IP 地址给每个 Pod
-
路由学习:每个节点学习整个集群的路由信息
-
直接路由:数据包直接路由到目标节点,无需隧道封装
-
策略执行:在网络边界实施安全策略
网络策略功能
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend
spec:
podSelector:
matchLabels:
role: frontend
ingress:
- from:
- podSelector:
matchLabels:
role: backend
ports:
- protocol: TCP
port: 80
优缺点分析
优点:
-
性能接近物理网络,延迟低
-
强大的网络策略能力
-
支持大规模集群部署
缺点:
-
配置相对复杂
-
对底层网络有特定要求
-
学习曲线较陡峭
四、技术对比与选型指南
功能特性对比
特性 | Flannel | Calico |
---|---|---|
网络模型 | Overlay 网络 | 路由直接转发 |
数据封装 | VXLAN/UDP 封装 | 无封装或 IPIP 封装 |
性能表现 | 中等,有封装开销 | 高性能,接近物理网络 |
网络策略 | 有限,需额外组件 | 原生强大支持 |
安装复杂度 | 简单 | 中等 |
资源消耗 | 较低 | 中等 |
适用规模 | 中小集群 | 各种规模集群 |
性能基准测试对比
场景 | Flannel | Calico |
---|---|---|
同节点 Pod 通信 | ≈ 本地通信 | ≈ 本地通信 |
跨节点 Pod 通信 | 有 10-15% 性能损耗 | 接近物理网络性能 |
网络策略执行 | 性能影响较大 | 优化的策略执行引擎 |
选型建议
选择 Flannel 当:
-
集群规模较小(节点数 < 100)
-
对网络性能要求不是极致
-
希望快速部署和简单维护
-
底层网络环境复杂或不可控
选择 Calico 当:
-
集群规模大或预期会快速增长
-
对网络性能有严格要求
-
需要细粒度的网络策略控制
-
底层网络支持 BGP 或允许 IPIP
五、实战部署示例
Flannel 部署
# 使用 kubectl 部署 Flannel
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
# 验证部署
kubectl get pods -n kube-system -l app=flannel
Calico 部署
# 下载 Calico 配置文件
curl https://docs.projectcalico.org/manifests/calico.yaml -O
# 部署 Calico
kubectl apply -f calico.yaml
# 验证部署
kubectl get pods -n kube-system -l k8s-app=calico-node
六、高级特性与最佳实践
Flannel 后端选择
-
VXLAN:推荐选择,性能较好
-
Host-gw:要求二层网络可达,性能最佳
-
UDP:不推荐,仅用于调试
Calico 配置优化
# 启用 IPIP 模式用于跨网段通信
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
name: default-ipv4-ippool
spec:
cidr: 192.168.0.0/16
ipipMode: Always
natOutgoing: true
网络策略最佳实践
-
默认拒绝所有流量,按需开放
-
使用命名空间进行网络隔离
-
定期审计和优化网络策略
-
监控网络策略的执行效果
七、故障排查与监控
常见问题排查
# 检查节点网络状态
kubectl get nodes -o wide
# 查看 Pod 网络配置
kubectl describe pod <pod-name>
# 检查 CNI 插件状态
kubectl get pods -n kube-system | grep flannel
kubectl get pods -n kube-system | grep calico
# 网络连通性测试
kubectl run test-pod --image=busybox --rm -it -- ping <target-pod-ip>
监控指标
-
网络延迟和丢包率
-
带宽利用率
-
网络策略执行计数
-
节点间连接状态
总结
Flannel 和 Calico 代表了 Kubernetes 网络插件的两种不同设计哲学:简单易用 vs 高性能与控制力。
-
Flannel 以其简单可靠的特性成为入门和中小规模集群的首选,让用户能够快速建立可工作的网络环境。
-
Calico 则以其卓越的性能和强大的策略能力,满足企业级应用对网络性能和安全的严苛要求。
在实际生产环境中,选择哪个插件应该基于具体的业务需求、团队技术能力和基础设施环境。对于大多数场景,可以从 Flannel 开始,当需要更高级功能时再迁移到 Calico。无论选择哪种方案,良好的网络规划、持续的监控和及时的优化都是确保 Kubernetes 网络稳定可靠的关键。
随着 Kubernetes 生态的不断发展,网络插件也在持续进化,建议保持对 CNI 生态的关注,及时采用新的特性和优化方案。