CNI插件之Flannel

深入解析Kubernetes网络插件Flannel：原理、实战与生产避坑指南

---

一、为什么需要Flannel？Kubernetes网络的底层挑战

Kubernetes设计理念要求所有Pod能直接通过IP通信，但跨主机容器网络是天然障碍。想象一个场景：

• Node A上的Pod 1（10.244.1.2）需要访问Node B上的Pod 2（10.244.2.3）
• 若无网络插件，两个Pod位于不同主机的Docker网桥中，网络完全隔离

这就是Flannel的核心价值——构建覆盖网络（Overlay Network），穿透物理网络拓扑，让所有Pod仿佛在同一个局域网中互通。

---

二、Flannel的三大核心机制

1. 子网分配：为每个节点划分IP池

Flannel通过两种方式管理子网：

• Kubernetes API模式（推荐）：从集群的CIDR（如10.244.0.0/16）中为每个Node分配子网（如10.244.1.0/24）。
• etcd模式（旧版）：依赖独立的etcd集群存储网络配置。

查看节点子网分配：

kubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}'
# 输出示例：10.244.0.0/24 10.244.1.0/24 10.244.2.0/24

2. 数据转发：跨主机通信的三种模式

Flannel支持多种后端实现，生产环境中常见以下三种：

模式	原理	性能	适用场景
VXLAN	通过隧道封装数据包，形成虚拟二层网络	中	跨云/跨机房等复杂网络环境
host-gw	利用主机作为网关，直接修改路由表指向目标节点	高	同机房裸机集群（需二层互通）
UDP	用户态封装数据包，兼容性最强但性能差	低	仅测试环境使用

配置示例（指定host-gw模式）：

# kube-flannel.yml
net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "host-gw"
    }
  }

3. 地址管理：CNI插件集成

Flannel通过CNI（Container Network Interface）与Kubelet协作：

1. 当Pod创建时，Kubelet调用Flannel CNI插件。
2. 插件为Pod分配IP，并配置虚拟网卡（如veth设备）。
3. IP地址写入Pod的status.podIP字段。

---

三、生产环境部署与调优

1. 安装Flannel

# 使用Kubernetes官方清单部署
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

2. 关键配置参数调优

• MTU调整：避免VXLAN封装导致分片

  # 在kube-flannel.yml中添加
  args:
  - --iface=eth0           # 指定物理网卡
  - --ip-masq=true         # 启用IP伪装（NAT出口流量）
  - --mtu=1450             # 根据物理网络调整
  

• 网络模式选择：

  • 同机房裸金属集群：优先使用host-gw（性能接近物理网络）。
  • 公有云VPC环境：使用VXLAN（兼容云网络限制）。

3. 与NetworkPolicy的兼容性

Flannel本身不支持网络策略，需额外安装Calico的Policy-only模式：

# 安装Calico策略组件
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/crds.yaml
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml
cat <<EOF | kubectl apply -f -
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: tigera-secure
spec:
  variant: Calico
  registry: docker.io
  calicoNetwork:
    bgp: Disabled
    ipPools:
    - cidr: 10.244.0.0/16
      encapsulation: None      # 禁用Calico的数据平面，仅用策略
EOF

---

四、生产环境常见问题与诊断

1. Pod跨节点无法通信

• 检查Flannel Pod状态：

  kubectl get pods -n kube-system -l app=flannel
  # 所有Pod应为Running状态
  

• 验证节点路由表（host-gw模式）：
  在Node上执行ip route show，应看到其他节点的Pod子网路由：

  10.244.1.0/24 via 192.168.1.2 dev eth0 
  10.244.2.0/24 via 192.168.1.3 dev eth0
  

2. Flannel占用大量CPU（UDP模式）

• 现象：flanneld进程CPU使用率高，网络延迟波动。
• 解决方案：切换到host-gw或VXLAN模式，避免用户态封装。

3. IP地址耗尽

• 原因：单个节点子网太小（默认/24网段提供254个IP）。
• 扩容方案：
  1. 修改Flannel的--network参数（如10.244.0.0/14）。
  2. 删除所有节点并重置PodCIDR（需重新部署集群）。

---

五、Flannel的局限性：何时该考虑其他插件？

尽管Flannel简单易用，但在以下场景需评估替代方案：

需求	Flannel能力	推荐替代方案
网络策略（L3/L4）	❌ 不支持	Calico、Cilium
高性能Service代理	❌ 依赖kube-proxy	Cilium（eBPF）
跨集群网络	❌ 不支持	Cilium Cluster Mesh
L7层流量控制	❌ 不支持	Istio + Envoy

---

六、总结：Flannel的最佳实践

1. 适用场景：中小规模集群、测试环境、对网络策略无硬性需求。
2. 模式选择：同机房用host-gw，跨网络用VXLAN，彻底避免UDP模式。
3. 监控指标：
   • 节点路由表正确性
   • Flanneld进程的CPU/内存
   • 跨节点Pod的Ping延迟
4. 升级策略：在维护窗口内逐个节点重启Flannel DaemonSet。

最终建议：对于刚接触Kubernetes的团队，Flannel是快速搭建集群网络的理想选择；当业务增长到需要高级网络功能时，再平滑迁移至Cilium或Calico。