在容器化应用架构中，网络构成分布式系统的核心连接机制。容器本质上通过隔离机制（如网络命名空间）实现独立性，但需支持高效的内部和跨节点通信。这正是 Container Network Interface (CNI) 的核心价值所在。作为一套标准化接口规范和插件实现体系，CNI 为容器提供可靠、可扩展的网络功能，使其具备与物理主机相当的独立网络标识。在 Kubernetes 等容器编排系统中，CNI 是实现 Pod 间通信和网络资源管理的关键组件。

CNI 的演进背景：容器网络的挑战与痛点

CNI 出现之前，容器网络面临显著的碎片化和扩展性问题。早期容器运行时（如 Docker）主要依赖桥接（bridge）模式，该模式在单主机环境中有效，但扩展到分布式集群时暴露诸多局限。主要挑战包括：

跨节点通信缺失：不同主机上的容器 IP 地址受限于本地桥接设备，无法实现直接路由。这阻碍了大规模集群的构建，常需依赖非标准化的临时解决方案。

生命周期管理耦合：容器启动时缺乏自动 IP 分配机制，终止时资源（如 IP 地址）无法高效回收，导致地址池耗尽和手动运维负担。

跨平台兼容性不足：不同容器运行时（如 Docker 与 Containerd）和编排框架（如 Kubernetes 与 Mesos）采用专有网络实现，缺乏统一接口，影响系统移植性和集成。

CNI 的引入解决了这些问题，通过将网络管理从运行时解耦，提供标准化接口。CNI 并非单一可执行程序，而是一套规范定义的网络操作协议（包括创建、配置和销毁），辅以二进制插件实现，从而实现网络管理的模块化和标准化。

CNI 的核心功能：为容器赋予网络自治能力

CNI 聚焦于容器网络生命周期的四个关键操作，通过插件机制确保模块化和扩展性。这些操作使容器在网络层面获得与物理主机相当的自治性。

1. 网络接口创建：实现容器网络接入

容器运行于独立的 Linux 网络命名空间中，以确保隔离。CNI 插件在该命名空间内生成虚拟网络接口（如 eth0），接口一端驻留容器内部，另一端连接主机侧的桥接、隧道或叠加网络设备（如 veth pair）。此过程相当于为容器建立物理层连接，实现与主机及外部网络的互通。

2. IP 地址分配：IPAM 子系统的作用

CNI 通过 IP Address Management (IPAM) 子系统为容器分配唯一的 IPv4/IPv6 地址、子网掩码和默认网关。IPAM 插件（如 host-local 或 dhcp）管理集群级地址池，确保无冲突分配。在 Kubernetes 环境中，每个 Pod 的 IP 均由此机制生成，支持全局唯一性。

IPAM 的独立设计允许无缝替换插件，实现分配策略的灵活调整，而不影响整体框架。

3. 路由与转发配置：数据路径优化

CNI 配置容器的路由表和转发规则，确保数据包高效传输。对于集群内部流量，可采用叠加网络（如 Flannel 的 VXLAN 封装）或路由协议（如 Calico 的 BGP 动态路由）；对于外部流量，则设置默认网关。此机制保障了端到端的连通性，无需额外手动干预。

4. 资源回收：销毁阶段的自动化清理

容器终止时，CNI 执行资源释放操作，包括移除虚拟接口、回收 IP 地址至池中，并删除关联路由和端口配置。此自动化流程防止资源泄漏，维护网络环境的稳定性。

CNI 的设计边界：专注核心，扩展外围

CNI 严格限定于基础网络操作，避免功能膨胀，将高级特性委托给插件扩展或其他组件：

不处理网络策略：如 Kubernetes 的 NetworkPolicy（访问控制规则），由特定插件（如 Calico 或 Cilium）实现，而非 CNI 规范的核心。

不涉及负载均衡或端口映射：Kubernetes 的 Service 抽象依赖 kube-proxy 或类似组件处理。

不参与容器生命周期管理：CNI 仅响应添加（ADD）和删除（DEL）调用，不涉及容器监控或状态跟踪。

这种设计原则确保 CNI 的轻量级和可扩展性。

CNI 的运作原理：基于生命周期的调用流程

CNI 采用事件驱动模型，按需执行，无需常驻进程。在 Kubernetes 中，节点代理 kubelet（以二进制形式运行）担任调用者。核心操作围绕 ADD（网络创建）和 DEL（网络销毁）命令展开。

ADD 操作：网络初始化流程

kubelet 创建容器的网络命名空间。

设置环境变量（如 CNI_COMMAND=ADD、CNI_NETNS=命名空间路径、CNI_IFNAME=eth0），并将 JSON 格式的网络配置（从 /etc/cni/net.d 加载）作为标准输入传递给插件。

插件（位于 /opt/cni/bin 的二进制可执行文件）执行序列：创建接口、通过 IPAM 分配地址、配置路由，并集成至集群网络。

以 JSON 格式返回结果（包括 IP、网关等），kubelet 更新 Pod 元数据。

DEL 操作：网络清理流程

kubelet 检测容器删除，设置 CNI_COMMAND=DEL 并调用插件。

插件逆向执行：移除接口、释放 IP、清理路由。

返回成功响应，kubelet 删除命名空间。

CNI 的战略意义：集群网络的基础保障

CNI 的架构设计提供了多项关键优势，使其成为容器集群不可或缺的组件：

标准化接口：统一 API 确保插件（如 Flannel、Calico、Cilium）跨运行时和编排平台兼容。

模块化解耦：网络实现可独立替换（如从 Flannel 迁移至 Calico），无需修改核心系统。

可扩展性支持：解决跨节点路由挑战，支撑生产级 Kubernetes 集群的规模化部署。

资源高效：二进制插件无外部依赖、部署简便，仅在调用时激活。

缺失 CNI 将导致容器网络标准化缺失，严重制约集群编排效率。

CNI 在 Kubernetes 中的部署实践：简洁与鲁棒性

无论 Kubernetes 采用二进制或容器化部署，CNI 均以二进制插件形式存在：

插件存放于 /opt/cni/bin 目录。

配置文件位于 /etc/cni/net.d。

kubelet 在 Pod 生命周期事件中直接执行插件。

此设计确保了部署的简洁性和跨环境移植性。

结语：CNI 在容器网络中的核心地位

本质上，CNI 构成容器网络的标准化框架，通过规范和插件机制，提供独立 IP 分配、接口创建、跨节点连通性和资源自动化管理。它是 Kubernetes 等平台的底层支撑，使容器从隔离实体转型为互联网络。缺失 CNI 将削弱云原生架构的潜力。

随着技术发展，CNI 的模块化特性将适应 IPv6、eBPF 优化和多网络场景。对于容器技术从业者，深入掌握 CNI 是构建高效网络系统的关键。

openEBS lvm_localpv

常见的网络设备

Catalog

Last update: 2025-01-24