【K8s】专题十五（2）：Kubernetes 网络之 CNI

本文内容均来自个人笔记并重新梳理，如有错误欢迎指正！

如果对您有帮助，烦请点赞、关注、转发、订阅专栏！

---

专栏订阅入口

| 精选文章 | Kubernetes | Docker | Linux | 羊毛资源 | 工具推荐 |

---

往期精彩文章

【Docker】（全网首发）Kylin V10 下 MySQL 容器内存占用异常的解决方法

【Docker】（全网首发）Kylin V10 下 MySQL 容器内存占用异常的解决方法（续）

【K8s】专题十五（1）：Kubernetes 网络之概念总览

目录

一、基本介绍

二、基本流程

三、CNI 与 CRI 协作

四、其他相关

1、CNI 插件网络模式

2、Bridge 与 veth-pair

3、kube-proxy

一、基本介绍

在 Kubernetes 中，CNI（Container Network Interface，容器网络接口）是一个标准化的网络模型接口，负责定义容器如何在网络层面进行交互和通信。

CNI 采用一种插件化机制，支持集成不同的网络方案。在容器创建过程中，Kubelet 组件通过调用所需的 CNI 插件，即可使用相应的网络方案完成容器的网络配置，实现灵活的容器网络连接、网络资源释放等功能。常见的 CNI 插件包括 Calico、Flannel、Cilium 等。

由此，CNI 通过标准化接口和插件化机制，为 Container Runtime（容器运行时）和 CNI 插件之间提供了一个通用接口，增强了 Kubernetes 网络的灵活性和可扩展性。

GitHub 地址：containernetworking/cni - GitHub

CNI 规范文档：SPEC.md

二、基本流程

• 创建配置文件：CNI 插件安装完成后，会为每个 Node 节点创建 CNI 配置文件（如 /etc/cni/net.d/xxnet.conf），用于定义 CNI 插件的类型和配置
• 调用插件：Kubelet 组件根据 CNI 配置文件调用相应的 CNI 插件，通常可以完成 ADD、CHECK、DELETE、GC 和 VERSION 五种操作
• 创建接口设备：CNI 插件为 Node 节点和容器的网络命名空间创建 veth-pair 设备，该设备一端位于容器中，命名为 eth0，另一端位于 Node 节点中，命名为 vethxxxx 形式
• 分配地址：CNI 插件调用 IPAM 模块，为 Pod 分配互不冲突的 IP 地址
  • IPAM（（IP Address Management，IP 地址管理）模块负责分配和管理 Pod 的 IP 地址
• 配置规则：CNI 插件通过配置必要的路由规则和 iptables 规则，以确保 Pod 之间及 Pod 与外部网络的通信

三、CNI 与 CRI 协作

在 Kubernetes 中，CRI（Container Runtime Interface，容器运行时接口）是负责管理容器运行时的标准化接口。

CRI 通过调用 CNI 插件来配置或清理容器网络，以确保容器网络配置过程与容器生命周期（主要是容器创建、销毁过程）紧密协调。

以容器创建过程为例，CNI 与 CRI 协作流程大致如下：

• Kubelet 到 CRI：Kubelet 组件调用 CRI，为已完成 Node 节点调度的 Pod 创建容器
• CRI 到 Pod：CRI 在 Pod 中创建和启动容器
• Pod 到 CRI：Pod 中的所有容器启动运行后，向 CRI 返回信号
• CRI 到 Kubelet：CRI 通知 Kubelet 组件，容器已准备就绪
• Kubelet 到 CNI：Kubelet 组件调用 CNI 为 Pod 中的容器设置网络
• CNI 到 Pod：CNI 为 Pod 中的容器配置网络，将其连接到网络接口
• Pod 到 CNI：Pod 中的容器网络配置完成后，向 CNI 返回信号
• CNI 到 Kubelet：CNI 通知 Kubelet 组件，Pod 的网络已准备就绪
• Kubelet 到 Pod：Kubelet 组件与 Pod 进行交互，获取 Pod 状态等

四、其他相关

1、CNI 插件网络模式

• 覆盖网络（Overlay Network）
  • CNI 插件通过 Overlay Network 模式，以 VXLAN 或 IPIP 等再次封装数据包后进行传输的方式，实现集群内 Pod 之间的互相访问，常见的有：
    • Flannel 插件的 VXLAN 模式
    • Calico 插件的 VXLAN、IPIP 模式
• 底层网络（Underlay Network）
  • CNI 插件通过 Underlay Network 模式，以节点作为路由设备、Pod 学习路由条目的方式，实现复杂场景下（如跨集群、跨云环境）集群外部直接访问集群内 Pod，常见的有：
    • Flannel 插件的 HOST-GW 模式
    • Calico 插件的 BGP 模式
    • Cilium 插件的 Native-Routing 模式

2、Bridge 与 veth-pair

Bridge 和 veth-pair 都是 Linux 中的虚拟网络接口。

Pod 通过 veth-pair 将自己的 Network Namespace 与 Node 节点的 Network Namespace 打通，然后使用 Bridge 将所有 veth-pair 连接在一起，实现大量 Pod 之间的互通和管理。

常见的 Bridge 有 docker0（Docker 服务启动时自动创建的网桥）、tunl0（由 Calico 插件的 IPIP 模式创建）、vxlan.calico（由 Calico 插件的 VXLAN 模式创建）。

3、kube-proxy

kube-proxy 作为 Node 节点的一个组件，主要作用是监视 Service 对象和 Endpoint 对象的变化（添加、移除）并刷新负载均衡，即通过 iptables 或 IPVS 配置 Node 节点的 Netfilter，实现网络流量在不同 Pod 间的负载均衡，并为 Service 提供内部服务发现。

kube-proxy 和 CNI 插件本质上都只是为 Linux 内核提供配置，而实际的数据包处理仍由内核完成，因此面临以下问题：

• 随着集群中 Service 对象和 Pod 对象数量的增长，iptables 的规则匹配效率会下降，即使 IPVS 进行了优化依然面临性能开销
• 频繁的 Service 对象和 Pod 对象更新会导致规则重新应用，可能带来网络延迟或中断
• 强依赖于 Linux 内核的 Netfilter，一旦内核配置不当或不兼容，可能会引发网络问题

当前，Cilium 等插件通过 eBPF 等技术可以绕过 Linux 内核，直接在用户空间处理数据包，实现了无代理的服务流量转发，完全可以替代 kube-proxy。但需要注意在使用 Istio 的场景下，若出现诸如 Service 对象的 port 与 targetPort 不一致等情况，可能导致 Istio 无法命中对应的路由规则。