Kubernetes网络核心：CNI超简指南

一文读懂 CNI：Kubernetes 网络的 “连接器”，小白也能轻松理解

如果你玩过搭积木，就知道不同形状的积木要靠 “连接件” 才能拼在一起，组成完整的造型。在 Kubernetes（简称 K8s）这个 “容器积木世界” 里，每个容器（Pod）就像一块积木，而CNI就是让这些 “容器积木” 能互相通信、也能和外界沟通的 “专属连接器”。

今天这篇文章就用大白话讲清楚：CNI 到底是什么、它为什么必不可少、有哪些常见类型，全程不堆技术黑话，哪怕你刚接触 K8s，也能轻松看明白。

一、先搞懂：没有 CNI 的 K8s，容器就是 “孤岛”

在说 CNI 之前，先想想一个问题：K8s 里的 Pod（容器的集合），为什么能互相访问？比如你在 Pod A 里执行ping Pod B，为什么能通？

其实，刚创建的 Pod 就像 “没插网线的电脑”—— 虽然存在于 K8s 集群里，但没有网络身份（IP 地址），也没法和其他 Pod 通信，更别说连外网了。这时候，就需要一个工具帮 Pod “插上网线”“分配 IP”“打通通信路径”，这个工具就是 CNI。

举个真实场景：

你在 K8s 里部署了一个 Web 应用（Pod 1）和一个数据库（Pod 2），Web 应用需要读取数据库的数据才能正常工作。如果没有 CNI：

1. Pod 1 和 Pod 2 没有 IP 地址，就像两台没联网的电脑；

1. 就算手动给它们分配 IP，也没有 “路由规则” 让它们找到对方；

1. 外面的用户想访问 Web 应用，更是无从下手。

而有了 CNI 之后，这些问题都能自动解决：CNI 会给每个 Pod 分配唯一的 IP，配置好路由，让 Pod 之间能互相通信，还能对接集群外的网络 —— 简单说，CNI 就是 K8s 集群的 “网络管理员”。

二、CNI 到底是什么？一句话说清核心定位

官方给 CNI 的定义是 “容器网络接口（Container Network Interface）”，听着有点绕，我们换个通俗的说法：

CNI 是一套 “约定好的规则”+“实现这些规则的工具” ——K8s 会按照这套规则，让 CNI 工具帮 Pod 完成 “网络配置”，比如分配 IP、设置路由、打通通信。

打个比方：K8s 就像 “小区物业”，Pod 是 “小区里的住户”，CNI 就是 “电信公司”。物业（K8s）会告诉电信公司（CNI）：“新来了一户住户（Pod），麻烦给它装网、分配宽带账号（IP）、确保能和其他住户（其他 Pod）通网”。电信公司（CNI）就按照既定流程（规则）完成这些操作，最后住户（Pod）就能正常上网了。

关键要记住：CNI 不是一个具体的 “软件”，而是一套 “标准”，市面上有很多符合这套标准的工具（比如 Flannel、Calico、Weave），就像 “电信公司” 有不同品牌一样，你可以根据需求选。

三、CNI 的 2 个核心作用：没有它，K8s 玩不转

CNI 的工作就两件事，但每一件都是 K8s 的 “刚需”，少了任何一个，集群都没法正常用。

1. 给 Pod “分配身份证”：IP 地址管理

每个 Pod 在 K8s 里都需要一个唯一的 IP 地址（就像每个人的身份证号），这样其他 Pod 才能找到它。CNI 的第一个核心作用，就是 “自动给 Pod 分配 IP，并确保不会重复”。

具体怎么做？

• CNI 会先确定一个 “IP 地址池”（比如10.244.0.0/16，这个网段里有 6 万多个 IP，足够大多数集群用）；

• 当 K8s 创建 Pod 时，会调用 CNI 工具，从 IP 池里选一个没被用过的 IP 分配给 Pod；

• Pod 被删除后，CNI 会把这个 IP 回收，放回 IP 池，供其他新 Pod 使用。

就像小区里的快递柜，每个格子（IP）对应一个住户（Pod），住户搬走（Pod 删除）后，格子就空出来给新住户用，不会浪费。

2. 让 Pod “打通电话”：网络通信配置

光有 IP 还不够，Pod 之间要通信，还需要 “路由规则”（就像地图，告诉数据包该走哪条路）和 “网络隔离控制”（比如哪些 Pod 能互相访问，哪些不能）。CNI 的第二个核心作用，就是配置这些 “通信规则”。

举两个常见场景：

• Pod 之间通信：CNI 会在每个 K8s 节点上配置路由表，告诉节点 “如果要访问10.244.1.5这个 IP，数据包要发给节点 A”，这样 Pod 1（在节点 A）就能和 Pod 2（在节点 B）互通；

• Pod 访问外网：CNI 会配置 “网络地址转换（NAT）” 规则，让 Pod 的私有 IP 能转换成节点的公网 IP，这样 Pod 就能访问百度、阿里云这些外网服务了；

• 网络策略控制：部分 CNI 工具（比如 Calico）还能实现 “网络隔离”，比如你可以设置 “只有 Web Pod 能访问数据库 Pod，其他 Pod 不行”，CNI 会帮你把这个规则落实到节点的网络配置里。

四、常见的 CNI 工具：3 个主流选择，各有特点

前面说过，CNI 是 “标准”，具体要靠 “工具” 来实现。市面上有很多 CNI 工具，这里介绍 3 个最常用的，帮你搞懂它们的区别，方便后续选择。

1. Flannel：最简单的 “入门款”，适合新手

Flannel 是 CNI 里的 “小米手机”—— 简单、轻量、易部署，没有复杂配置，新手拿来就能用。

它的工作原理很简单：在每个 K8s 节点上创建一个 “虚拟网卡（flannel.1）”，然后用 “VXLAN” 技术（可以理解成 “虚拟网线”）把所有节点的虚拟网卡连起来，形成一个 “虚拟局域网”。Pod 的 IP 就从这个虚拟局域网的 IP 池里分配，Pod 之间的通信都通过这个虚拟局域网转发。

优点：部署快（一条命令就能装）、资源占用少（每个节点只跑一个小容器）、几乎不用配置；

缺点：功能简单，不支持 “网络策略”（没法做 Pod 间的访问控制），性能一般（VXLAN 转发会有轻微延迟）；

适合场景：测试环境、小型集群、对网络功能要求不高的场景。

2. Calico：功能最全的 “专业款”，适合生产环境

Calico 是 CNI 里的 “华为 Mate 系列”—— 功能强、性能好、支持复杂场景，是生产环境的首选。

它的工作原理有两种模式：

• BGP 模式：不依赖 “虚拟网卡”，而是让每个节点通过 BGP 协议（一种互联网常用的路由协议）互相交换路由信息，直接打通节点间的通信，性能比 Flannel 好很多；

• VXLAN 模式：和 Flannel 类似，适合跨云、跨数据中心的场景（BGP 模式在这些场景下配置复杂）。

优点：支持 “网络策略”（能精细控制 Pod 访问）、性能好（BGP 模式几乎没有转发延迟）、支持大规模集群（能轻松应对上千个节点）；

缺点：配置比 Flannel 复杂一点（但官方有现成的安装清单，复制粘贴就能用）；

适合场景：生产环境、需要网络隔离的场景（比如金融、电商）、大规模集群。

3. Weave Net：最灵活的 “全能款”，适合跨节点场景

Weave Net 是 CNI 里的 “苹果手机”—— 设计优雅、自带 “网络修复” 功能，适合节点分布在不同地方的场景（比如部分节点在上海，部分在北京）。

它的工作原理：在每个节点上创建一个 “虚拟网桥（weave）”，然后用 “加密隧道” 把所有节点的网桥连起来，不管节点在哪个地方，只要能通外网，就能组成一个集群网络。而且如果某个节点宕机，Weave 会自动找其他路径转发数据包，保证网络不中断。

优点：支持跨地域集群、自带网络加密（Pod 通信数据不会被窃取）、支持网络策略；

缺点：资源占用比 Flannel 高，大规模集群下性能不如 Calico；

适合场景：跨地域集群、对网络安全性要求高的场景。

五、CNI 怎么用？3 步在 K8s 里安装 Flannel（新手教程）

前面说了这么多，不如动手试试。这里以最简单的 Flannel 为例，教你用 3 步在 K8s 里安装 CNI，感受一下它的作用。

前提：已有 K8s 集群

首先要确保你已经有一个 K8s 集群（至少 1 个 master 节点 + 1 个 worker 节点），如果还没有，可以参考 K8s 官方文档快速搭建（比如用kubeadm工具，半小时就能搞定）。

第一步：下载 Flannel 的安装清单

Flannel 官方提供了现成的 “安装清单（YAML 文件）”，里面写好了所有需要部署的组件，直接下载就行：

# 下载Flannel安装清单（v0.26.1版本，稳定版）curl -O https://github.com/flannel-io/flannel/releases/download/v0.26.1/kube-flannel.yml

第二步：部署 Flannel

用 K8s 的kubectl apply命令部署清单，K8s 会自动按照清单里的配置启动 Flannel 组件：

kubectl apply -f kube-flannel.yml

第三步：验证安装是否成功

部署后等待 1~2 分钟，然后执行以下命令，查看 Flannel 的 Pod 状态：

# 查看kube-system命名空间下的Flannel Podkubectl get pods -n kube-system -l app=flannel

如果输出里的 Pod STATUS 都是 “Running”，说明 Flannel 安装成功了：

NAME READY STATUS RESTARTS AGEkube-flannel-ds-abcde 1/1 Running 0 1mkube-flannel-ds-fghij 1/1 Running 0 1m

测试：Pod 之间能否通信

安装完成后，我们创建两个测试 Pod，看看它们能不能互相通信：

# 创建第一个Pod（nginx）kubectl run nginx-pod --image=nginx:alpine# 创建第二个Pod（busybox，用来测试通信）kubectl run busybox-pod --image=busybox:1.35 --command -- sh -c "sleep 3600"# 等待Pod就绪（STATUS变成Running）kubectl get pods

然后从 busybox-pod 里 ping nginx-pod 的 IP：

# 先获取nginx-pod的IP（假设是10.244.1.2）NGINX_IP=$(kubectl get pod nginx-pod -o jsonpath='{.status.podIP}')# 从busybox-pod执行ping命令kubectl exec -it busybox-pod -- ping -c 3 $NGINX_IP

如果输出 “3 packets transmitted, 3 received”，说明两个 Pod 能互相通信，CNI 已经正常工作了！

六、常见问题：小白最容易踩的 2 个坑

1. 安装 CNI 后，Pod 一直处于 “Pending” 状态？

原因：K8s 创建 Pod 时，会等待 CNI 给 Pod 分配 IP，如果 CNI 没装好，Pod 就会卡在 “Pending”，并提示 “NetworkPlugin cni failed to set up pod ...”。

解决方法：

1. 先查看 CNI 的 Pod 状态，看是不是有 Pod 没启动：

kubectl get pods -n kube-system | grep -E "flannel|calico|weave"

1. 如果有 Pod 处于 “CrashLoopBackOff” 状态，查看日志找原因：

# 假设Flannel Pod叫kube-flannel-ds-abcdekubectl logs -n kube-system kube-flannel-ds-abcde

1. 常见原因：节点的防火墙挡住了 CNI 的通信端口（比如 Flannel 需要 8472 端口，Calico 需要 179 端口），关闭防火墙或开放对应端口即可。

2. Pod 能互相通信，但访问不了外网？

原因：CNI 的 “NAT 规则” 没配置好，导致 Pod 的私有 IP 没法转换成节点的公网 IP。

解决方法：

1. 先检查节点的路由表，看有没有 CNI 配置的路由：

# 查看路由表，找包含Pod网段的路由（比如10.244.0.0/16）ip route

1. 如果有路由，再检查节点的 iptables 规则（CNI 会添加 NAT 规则）：

# 查看NAT表的规则，找包含Pod网段的规则iptables -t nat -L | grep 10.244

1. 如果没有对应的规则，重启 CNI 的 Pod，让 CNI 重新配置规则：

# 重启Flannel Pod（其他CNI类似）kubectl delete pods -n kube-system -l app=flannel

七、总结：CNI 到底有多重要？

简单说，没有 CNI，K8s 就是 “半身不遂” ——Pod 虽然能创建，但没法通信、没法访问外网，根本发挥不了 “容器编排” 的作用。

如果你是 K8s 新手，刚开始可以用 Flannel 入门，感受 CNI 的基本功能；如果要部署生产环境，优先选 Calico，它的网络策略和性能能满足大部分场景需求；如果你的集群节点跨地域，Weave Net 会是更好的选择。

最后记住一句话：CNI 是 K8s 的 “网络基石”，搞懂它，你就掌握了 K8s 运维的核心技能之一。