为什么从 Flannel 切换到 Calico

“为什么从 Flannel 切换到 Calico” 时，他们希望了解你对 CNI 插件的技术选型能力以及实际问题的解决经验。以下是结构化回答建议：

---

1. 直接原因（痛点驱动）

“我们遇到 Flannel 的以下关键问题，促使切换：”

• 网络策略（NetworkPolicy）缺失：
  Flannel 仅提供基础网络连通性，无法实现 Pod 间的安全隔离（如微服务需要按需放行特定流量）。
  举例：某次安全审计要求隔离支付服务（payment-service）与前端服务，Flannel 无法实现，而 Calico 可通过 NetworkPolicy 精准控制。

• 性能瓶颈：

  • Flannel 的 VXLAN 模式有 额外封装开销（约 10-20% 带宽损耗）。
  • 大规模集群中，Flannel 的 iptables 规则膨胀导致网络延迟增加（如超过 1000 个 Pod 时延迟波动明显）。

• 故障排查困难：
  Flannel 的日志和监控能力较弱，曾因 ARP 缓存问题导致跨节点 Pod 通信失败，耗时 2 天定位，而 Calico 提供 calicoctl 和可视化工具（Calico UI）快速诊断。

---

2. Calico 的核心优势（解决方案）

“Calico 解决了这些问题，并带来额外收益：”

• 网络策略（NetworkPolicy）支持：

  • 实现 L3-L4 层 ACL（如只允许 frontend Pod 访问 backend:6379）。
  • 支持 deny 规则和日志记录（便于安全审计）。

• 更高性能：

  • BGP 路由模式 避免 overlay 开销（直连 Pod IP，适合金融级低延迟场景）。
  • eBPF 数据平面（可选）进一步提升吞吐量（测试环境提升 30%）。

• 企业级特性：

  • 跨集群网络（通过 Calico Enterprise 的 GlobalNetworkPolicy）。
  • 与 Istio 集成实现 零信任网络（L7 策略 + L4 Calico 策略叠加）。

• 运维友好：

  • calicoctl 命令行工具直接操作网络策略。
  • Prometheus 指标暴露完善（如 felix_active_local_endpoints 监控健康状态）。

---

3. 迁移过程与验证（落地经验）

“我们的迁移步骤和验证方法：”

1. 前期测试：

   • 在非生产集群部署 Calico，对比 Flannel 的延迟（ping）和吞吐量（iperf3）。
   • 验证 NetworkPolicy 是否生效（如 kubectl exec 测试策略拦截）。

2. 灰度切换：

   • 逐个节点移除 Flannel 并安装 Calico（避免一次性全量切换）。
   • 使用 kubectl drain 确保 Pod 重建后绑定新 CNI。

3. 监控回滚指标：

   • 重点关注：
     • 核心服务跨节点通信延迟（如数据库访问 P99 延迟）。
     • DNS 解析成功率（避免 CoreDNS 因策略失效）。
   • 准备回滚脚本（快速重装 Flannel）。

“最终效果”：

• 网络延迟降低 15%（BGP 模式 vs Flannel VXLAN）。
• 安全事件响应时间从 小时级 缩短到 分钟级（借助 NetworkPolicy 快速隔离问题 Pod）。

---

4. 面试回答示例

面试官：
“你们为什么从 Flannel 切换到 Calico？”

回答：
“我们切换的核心原因是 Flannel 无法满足生产环境的安全和性能需求，具体分三方面：

1. 安全短板：
   • 金融业务需隔离不同部门 Pod，Flannel 缺乏 NetworkPolicy 支持，而 Calico 实现了基于标签的微服务 ACL。
2. 性能问题：
   • Flannel 的 VXLAN 模式在跨可用区通信时带宽损耗达 20%，切换 Calico BGP 后延迟降低 15%。
3. 运维瓶颈：
   • 曾因 Flannel 的 ARP 问题导致全网中断，Calico 的 felix 组件提供实时健康监测。

迁移时，我们通过灰度发布和 calicoctl 逐步验证，最终在零宕机前提下完成切换。现在还能通过 Calico 的 GlobalNetworkPolicy 管理多集群网络策略。”

---

5. 可能追问与应对

1. “有没有遇到 Calico 的坑？”
   → “早期版本（v3.15）的 BGP 模式需要手动配置节点对等体（peer），后来改用 calico-node 自动发现。升级到 v3.25 后问题解决。”

2. “为什么不用 Cilium？”
   → “Cilium 的 eBPF 模式对内核版本要求高（需 ≥ 4.19），而我们的生产环境跑在 CentOS 7（内核 3.10），短期无法升级。”

3. “Calico 的资源消耗是否更高？”
   → “Calico 的 felix 组件每个节点多占用约 50MB 内存，但换来的安全性和性能收益远超成本。”

---

6. 总结回答要点

• 痛点驱动：Flannel 的缺陷（安全/性能/运维）是切换主因。
• 数据支撑：用量化指标（延迟降低 15%）和事故案例增强说服力。
• 落地细节：展示你对迁移风险和解决方法的理解。