当面试官让你对比 CNI 插件时，他到底在考察什么？

引言

面试的时候问到了很多次，但是回答的不是很全面，尽管有时候面试官听着还可以，但是自己知道回答还不够全面，所以我们就深入了解下。

如果文章哪里有问题，还望指出。

最后有相关的学习群，有兴趣可以加入。

开始

引言：容器网络的挑战与演进

在 Kubernetes 集群中，容器网络是支撑微服务通信的基石。随着云原生技术的普及，网络性能、安全性和可扩展性成为架构师的核心考量。本文将深入探讨两大主流 CNI 插件——Flannel 与 Calico 的设计原理、工作模式对比及生产环境选型策略，通过原理剖析、性能测试和真实案例，助您构建最佳容器网络方案。

第一章：Flannel 设计解析与实现细节

1.1 Flannel 架构全景

Flannel 是 Kubernetes 最轻量的 Overlay 网络方案，其核心架构包含三部分：

图片

核心组件职责：

• • Flanneld：守护进程，负责节点子网管理、路由表更新和隧道维护。
• • Backend：数据平面实现（VXLAN/host-gw/UDP），决定流量转发逻辑。
• • CNI 插件：配置 Pod 网络命名空间（veth pair + IPAM）。

1.2 Flannel 工作模式深度剖析

模式 1：VXLAN（Virtual Extensible LAN）

实现原理：

• • 虚拟隧道端点（VTEP）：每个节点创建 vxlan0 设备，通过 UDP 4789 端口封装 L2 帧。
• • MAC 地址学习：利用 FDB（Forwarding Database）记录目标 Pod MAC 与节点 IP 的映射。
• • 多播组管理：初始阶段通过多播发现邻居节点（生产环境建议静态配置）。

数据包生命周期：

图片

性能优化技巧：

# 调整 VXLAN MTU 避免分片（通常设为物理 MTU - 50）
ifconfig vxlan0 mtu 1450

# 启用 UDP 校验和卸载（需网卡支持）
ethtool -K eth0 tx-udp_tnl-csum-segmentation on
1.
2.
3.
4.
5.

模式 2：host-gw（Host Gateway）

实现原理：

• 直接路由：节点充当网关，通过静态路由将目标 Pod 子网指向对应节点物理 IP。

• 无隧道开销：要求节点间 L2 互通（同一子网），否则路由不可达。

路由表示例：

# Node1 路由表
10.244.1.0/24 via 192.168.0.2 dev eth0  # Pod 子网 -> Node2
10.244.2.0/24 via 192.168.0.3 dev eth0  # Pod 子网 -> Node3
1.
2.
3.

适用场景与限制：

• 优势：吞吐量接近物理网络（无封装开销），延迟降低 40%+。

• 限制：节点必须位于同一 L2 网络，跨子网需 BGP 或手动配置路由。

1.3 Flannel 高级特性与局限

多后端支持：

• UDP 模式（已弃用）：用户态封装，性能差，仅用于旧内核兼容。

• AWS VPC 后端：直接使用 AWS 路由表，需配合 aws-vpc-cni。

局限分析：

• 网络策略缺失：依赖 Kubernetes 原生 NetworkPolicy，功能有限。

• 扩展性瓶颈：大规模集群（>1000 节点）路由表膨胀问题。

第二章：Calico 架构设计与高级功能

2.1 Calico 组件协作模型

Calico 采用分布式架构，控制平面与数据平面解耦：

图片

核心组件职责：

• Felix：配置本地路由、ACL 和端点状态。

• BIRD：BGP 客户端，广播路由到物理网络。

• Typha：大规模集群中降低 API Server 负载。

2.2 Calico 工作模式详解

模式 1：BGP（Border Gateway Protocol）

实现原理：

• 对等体发现：节点与物理路由器（ToR）建立 BGP 会话，交换路由信息。

• 路由传播：每个节点宣告自身 Pod CIDR（如 10.244.1.0/24）。

• ECMP 支持：通过 BGP 多路径实现负载均衡。

配置示例（Calico BGP）：

apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: peer-tor
spec:
  peerIP: 192.168.0.254
  asNumber: 64512
  nodeSelector: all()
1.
2.
3.
4.
5.
6.
7.
8.

模式 2：IP-in-IP 隧道

实现原理：

• 隧道封装：跨子网通信时，将原始 IP 包封装在另一个 IP 包中（协议号 4）。

• 动态封装策略：通过 ipipMode 控制：

Always：所有流量封装。

CrossSubnet：仅跨子网流量封装。

性能影响：

2.3 Calico 网络策略实战

L4 策略示例：

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: deny-db-external
spec:
  selector: role == 'database'
  ingress:
    - action: Allow
      protocol: TCP
      source:
        namespaceSelector: project == 'prod'
      destination:
        ports: [5432]
  egress:
    - action: Deny
      destination:
        nets: [0.0.0.0/0]
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

L7 策略示例（需 Cilium 集成）：

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: http-methods
spec:
  selector: app == 'api'
  ingress:
    - action: Allow
      http:
        methods: ['GET', 'POST']
      source:
        serviceAccounts:
          names: ['frontend-sa']
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

第三章：Flannel vs Calico 全方位对比

3.1 核心能力矩阵

3.2 性能基准测试

测试环境：

• 节点规格：AWS m5.xlarge (4 vCPU, 16GB RAM)

• 集群规模：10 节点，100 Pod/节点

• 工具：iperf3 和 kubectl benchmark

结果对比：

3.3 生产环境选型决策树

图片

第四章：真实案例与故障复盘

4.1 案例 1：电商大促 Flannel VXLAN 性能瓶颈

现象：

• 促销期间 API 网关延迟从 50ms 飙升至 800ms。

• 节点 CPU 使用率高达 90%，vxlan0 接口出现丢包。

根因分析：

• VXLAN 封装导致单核处理瓶颈（Linux 内核协议栈限制）。

• MTU 不匹配引发大量分片，加剧 CPU 负担。

解决方案：

1. 切换到 host-gw 模式（节点间 L2 互通）。

2. 优化内核参数：

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
1.
2.

3. 升级为 Calico BGP 模式长期规划。

4.2 案例 2：Calico BGP 路由震荡导致服务中断

现象：

• 每 5 分钟出现 30 秒服务不可用。

• BIRD 日志显示路由持续撤回/更新。

根因分析：

• 节点与 ToR 交换机 BGP 会话超时时间不匹配。

• 交换机配置 hold-time=90s，节点默认 hold-time=180s。

解决方案：

apiVersion: projectcalico.org/v3
kind: BGPConfiguration
metadata:
  name: bgp-settings
spec:
  logSeverityScreen: Info
  nodeToNodeMeshEnabled: false
  asNumber: 64512
  listenPort: 179
  prefixes:
    - cidr: 10.244.0.0/16
  bgpPeers:
    - peerIP: 192.168.0.254
      asNumber: 64513
      holdTime: 90s  # 与交换机对齐
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

第五章：未来趋势与演进方向

5.1 eBPF 对容器网络的影响

• Cilium 的崛起：替代 iptables 实现高性能策略实施。

• XDP 加速：在网卡驱动层处理流量，降低延迟。

• 服务网格融合：Sidecar 模式向 CNI 层转移。

5.2 多云网络架构

• Submariner：跨集群 L3 连通 + 服务发现。

• Network Policy Federation：统一管理多集群策略。

• 零信任安全：基于 SPIFFE 的身份感知网络。

结语：构建面向未来的容器网络

选择 Flannel 还是 Calico，本质是在简单性与能力丰富性之间权衡。对于初创公司或中小集群，Flannel 的极简设计能快速上线；而中大型企业需要 Calico 的策略引擎和精细控制。随着 eBPF 和硬件卸载技术的成熟，未来的容器网络将向着更高性能、更智能化的方向持续演进。

行动指南：

1. 在开发环境使用 Flannel 快速验证业务。

2. 生产环境优先 Calico，预留策略扩展能力。

3. 定期评估网络架构，跟随社区演进。