目录
- 一、核心概念与目标
- 二、工作流程
- 三、CNI插件类型
- 四、CNI配置与插件管理
Container Networking Interface (CNI) 是一种标准化的网络插件接口,用于在容器运行时(如Docker、containerd、CRI-O等)与底层网络堆栈之间建立桥梁,为容器提供网络连接能力。CNI简化了容器网络的配置和管理,使得不同的容器运行时和网络解决方案能够无缝集成到Kubernetes等容器编排平台中。
一、核心概念与目标
-
标准化接口:CNI定义了一组规范化的API(应用程序编程接口)和数据结构,供容器运行时调用以配置容器网络。这样,无论使用哪种具体的网络插件(如Calico、Flannel、Weave Net等),只要它们遵循CNI接口,就能与容器运行时和Kubernetes等编排系统兼容。
-
网络插件化:CNI将网络功能抽象为可插拔的插件,每个插件负责一种或多种网络功能,如IP地址分配、网络命名空间配置、网桥创建、隧道封装等。这种模块化设计允许用户根据需求选择或组合不同的插件来构建灵活、定制化的网络方案。
-
一次配置,全程生效:CNI插件在容器创建时被调用一次,执行网络配置;在容器销毁时再次被调用,执行网络清理。这种“按需配置”的方式避免了不必要的网络资源浪费,也简化了网络管理。
二、工作流程
-
容器创建时:
- 调用插件:当Kubernetes的kubelet准备创建一个新容器时,它会调用容器运行时,后者通过CNI接口触发网络插件。
- 配置网络:网络插件接收来自kubelet的网络配置信息(如网络名称、容器ID、沙箱路径等),并根据这些信息为容器配置网络。这通常包括创建网络命名空间、设置IP地址、添加路由规则、配置网络设备(如veth pair、网桥等)等步骤。
- 返回结果:插件完成配置后,将网络信息(如IP地址、子网掩码、网关、DNS等)写入容器运行时提供的网络配置文件(如
/var/run/netns/<container_id>
),然后返回一个包含所有配置细节的JSON对象给kubelet。
-
容器销毁时:
- 清理网络:当kubelet决定销毁一个容器时,它再次通过CNI接口调用网络插件,请求清理与该容器关联的网络资源。插件负责撤销之前配置的网络设备、删除路由规则、释放IP地址等。
- 确认清理:插件完成清理后,返回一个简单的成功或失败消息给kubelet。
三、CNI插件类型
-
覆盖网络(Overlay Networks):如Calico、Flannel、Weave Net等,使用隧道技术(如VXLAN、Geneve、IP-in-IP等)在物理网络之上构建逻辑二层网络,实现跨主机容器间的通信。这类插件通常提供网络策略、路由控制等高级功能。
-
主机网络(Host Networking):如
host-local
插件,直接将容器放入主机的网络命名空间,容器共享主机的网络栈,无需额外的网络设备或隧道封装。这种方式简单直接,适用于对网络性能要求高、不需要网络隔离的应用场景。 -
MACVLAN & IPVLAN:这两种网络模式使容器获得独立的MAC或IP地址,直接在物理网络中表现为独立的网络设备,具有接近裸机的网络性能和透明的网络可见性。
-
第三方网络服务集成:如AWS VPC CNI、GCE PD CNI等,与云服务商的网络服务(如虚拟私有云、负载均衡器等)深度集成,简化云上Kubernetes集群的网络配置。
四、CNI配置与插件管理
-
配置文件:CNI的配置通常保存在Kubernetes节点上的
/etc/cni/net.d/
目录下,每个网络插件有一个对应的配置文件(如10-calico.conflist
)。这些文件定义了插件的类型、插件的具体配置参数以及网络配置的优先级等信息。 -
插件链(Plugin Chain):CNI支持插件链的概念,即一个网络配置可以由多个插件组成,每个插件负责一部分网络功能。插件按照配置文件中定义的顺序依次执行,共同完成容器的网络配置。
-
多网络支持:Kubernetes支持Pod使用多个网络接口(multi-networking),这意味着一个Pod可以同时关联多个CNI网络。这种能力使得Pod可以根据业务需求接入多个网络环境,如公网、私网、服务网格等。