先把概念说清楚
在 Kubernetes 里，Pod 的网络不是“天然就通”的。系统只负责把 Pod 放到节点上，至于 Pod 如何获得 IP、如何接入宿主机网络、如何与集群内外通信，依赖的就是 CNI（Container Network Interface）这一套标准与实现。
CNI 本身不是某一个插件名，而是一组接口规范。它定义了容器运行时在创建、删除 Pod 网络时应该如何调用网络插件。换句话说，Kubernetes 负责调度，CNI 负责把“能通信的网络环境”真正接起来。
如果你把容器网络理解成“地址分配、路由接入、转发策略、网络隔离”四个步骤，CNI 就是把这些步骤标准化的连接方式。不同实现可以不同，但调用入口一致，因此无论是 Calico、Flannel 还是 Cilium，背后都可以走这套机制。
CNI 在 Pod 生命周期里做了什么
从 Pod 创建到网络就绪，关键动作通常发生在节点侧，而不是控制面侧。大致流程可以理解为：
- kubelet 接收到 Pod 调度结果。
- 容器运行时启动 Pod 沙箱。
- 运行时调用 CNI 插件，申请网络配置。
- 插件创建 veth、分配 IP、写入路由或策略。
- Pod 进入 Ready 状态后，业务流量才能正式进入。
这意味着网络故障经常出现在“节点本地”层面，例如 CNI 配置文件缺失、插件二进制不存在、IP 池耗尽、MTU 不一致、iptables 规则冲突等。只盯着控制面看，往往找不到真正的根因。
常见 CNI 插件能力差异
不同 CNI 方案解决的问题重点不一样，选型时不能只看“能不能上网”，还要看治理能力。
| 关注点 | 典型能力 | 适用场景 |
|---|---|---|
| — | — | — |
| IP 分配 | 为 Pod 分配唯一地址 | 基础联网 |
| 网络隔离 | Namespace、Label、Policy 级隔离 | 多团队、多租户 |
| 跨节点通信 | VXLAN、BGP、隧道或直连 | 多节点集群 |
| 可观测性 | 流量追踪、策略命中、故障定位 | 生产环境治理 |
有些团队更关注网络简单可用，有些团队则更看重策略控制和可观测性。前者更适合标准化基础集群，后者更适合多业务混部环境。若你正在梳理容器网络的整体建设路径，可以顺着容器网络专题继续看更完整的选型思路。
插件链路为什么会影响排障
CNI 不是单个程序在工作，而是一条插件链。常见情况是“主插件 + 多个附加插件”协同完成：
- 主插件负责核心联网能力，例如分配 IP、创建接口。
- 附加插件负责 DNS、带宽、策略、端口映射等扩展能力。
这也是为什么同一个 Pod 看似“网络不通”，根因却可能分布在多个层面：
- CNI 配置文件路径不对，导致 kubelet 找不到插件。
- 二进制文件版本不一致，导致调用失败。
- IPAM 地址池不足，导致新 Pod 申请失败。
- 网络策略过严，导致东西向流量被拦截。
- 节点防火墙或内核参数错误，导致跨节点通信异常。
因此，排障不能只看 Pod 日志，还要结合节点上的 /etc/cni/net.d/、/opt/cni/bin/、ip link、iptables、ip route 以及 CNI 插件自身的日志。
选型时应该看哪些问题
如果你在做平台设计，CNI 选型最好先回答下面几个问题：
- 你的集群规模有多大，是否经常扩容？
- 业务是否需要严格网络隔离？
- 是否存在跨机房、跨可用区通信需求？
- 运维团队能否接受更复杂的调试链路？
- 未来是否需要和 Service Mesh、网络策略、可观测平台联动？
对很多企业来说，CNI 不是“单独的网络组件”，而是平台能力的一部分。它需要和节点规划、IP 规划、服务发现、网络安全一起设计，而不是临时接入一个插件就算完成。
常见误区
误区一：Kubernetes 自带完整网络能力
Kubernetes 只定义了网络模型和接口标准，真正的实现要靠 CNI 插件。没有 CNI，Pod 就算创建成功，也未必能正常通信。
误区二：只要能 ping 通就算网络正常
生产环境里，网络正常不只是连通，还包括隔离、策略、性能、稳定性和可观测性。很多问题不是“能不能通”，而是“谁能通、通到哪、是否可控”。
误区三：所有插件都一样
不同 CNI 的架构差异会直接影响性能和治理方式。VXLAN、BGP、eBPF、iptables 这些路径在性能和复杂度上的权衡完全不同。
落地建议
如果你刚开始建设 Kubernetes 网络，建议按这条顺序推进：
- 先明确 Pod CIDR、节点网段和 Service 网段规划。
- 再选一个主流 CNI，确保基础联网稳定。
- 然后补充网络策略、监控与故障排查能力。
- 最后再考虑更复杂的多集群、跨地域和零信任方案。
对于平台团队来说，CNI 的价值不在“概念先进”，而在“让网络能力可重复、可治理、可排障”。这也是容器网络从实验环境走向生产环境时，最先要补齐的一块基础能力。
常见问题
CNI 和 Kubernetes Service 是什么关系？
CNI 负责让 Pod 接入网络并获得可通信的网络环境，Service 负责为一组 Pod 提供稳定访问入口和负载均衡。CNI 解决底层 Pod 网络连通问题，Service 解决服务发现与访问抽象问题，两者位于不同层次但会共同影响请求路径。
更换 CNI 插件会影响业务吗？
会有较高风险，因为 CNI 影响 Pod IP、跨节点路由、网络策略和流量路径。生产环境更换前应先在测试集群验证网络模型、策略兼容性、MTU、性能和回滚方案，不能只按安装文档直接替换。
CNI 故障为什么常出现在节点侧？
Pod 网络的创建通常由节点上的 kubelet、容器运行时和 CNI 插件协作完成。插件二进制、配置文件、IP 池、路由、iptables 或 eBPF 状态都在节点侧体现，因此排障时只看控制面事件往往不够。
转载请注明出处：https://www.cloudnative-tech.com/p/7343/
