CNI准入策略架构通信与Webhook集成 - 第1节

1.1 CNI 的定义与核心职责

Container Network Interface（CNI）是 Cloud Native Computing Foundation（CNCF）旗下的一个项目，它定义了一组用于配置容器网络接口的规范、库和插件。CNI 的核心目标是为容器运行时提供一种标准化的方式，以管理网络接口的创建、连接、断开和删除。

CNI 规范的核心是一个简单的 JSON 协议，容器运行时通过该协议调用 CNI 插件，完成网络配置。其基本操作包括：

• ADD：为容器创建并配置网络接口。
• DEL：删除容器的网络接口并清理资源。
• CHECK：验证容器的网络配置是否仍然有效。
• VERSION：查询插件支持的 CNI 规范版本。

1.2 CNI 在 Kubernetes 中的核心地位

在 Kubernetes 集群中，CNI 是网络模型的基础实现层。Kubernetes 要求每个 Pod 都拥有一个独立的 IP 地址，并且所有 Pod 之间可以直接通信，无需 NAT。这一要求完全依赖 CNI 插件来满足。

Kubernetes 通过 kubelet 调用 CNI 插件，完成 Pod 网络的生命周期管理。其工作流程如下：

1. kubelet 从 API Server 接收到创建 Pod 的指令。
2. kubelet 调用容器运行时（如 containerd）创建容器。
3. 容器运行时在容器创建完成后，调用 CNI 插件执行 ADD 操作。
4. CNI 插件为容器分配 IP 地址，创建网络接口，并配置路由规则。
5. Pod 网络就绪，可以与其他 Pod 或 Service 通信。

CNI 插件在 Kubernetes 集群中承担以下核心职责：

职责领域	具体功能	典型实现
IP 地址管理（IPAM）	为 Pod 分配唯一的 IP 地址，避免冲突	host-local, dhcp, Calico IPAM
网络连通性	确保同一节点和跨节点的 Pod 可以通信	Flannel VXLAN, Calico BGP
网络策略	实现 Kubernetes NetworkPolicy 定义的流量规则	Calico, Cilium, Weave Net
服务发现与负载均衡	部分 CNI 插件集成 kube-proxy 或 eBPF 实现	Cilium eBPF, Calico kube-proxy

1.3 为什么需要准入策略通信机制

在 Kubernetes 集群中，CNI 插件拥有对节点网络栈的完全控制权。一个配置错误或恶意的 CNI 插件可能导致：

• Pod IP 地址冲突，导致通信中断。
• 网络策略绕过，安全隔离失效。
• 节点网络资源耗尽，影响其他工作负载。
• 敏感流量被劫持或泄露。

因此，引入 准入策略通信机制 成为必要。该机制的核心目标是在 CNI 插件执行网络配置之前，对配置请求进行验证和授权，确保只有符合集群安全策略的网络操作才能被执行。

准入策略通信机制需要解决以下关键问题：

问题维度	具体描述	准入策略作用
身份验证	确认 CNI 插件调用者的身份是否合法	验证 kubelet 或容器运行时的凭证
权限控制	限制 CNI 插件可操作的网络资源范围	基于 RBAC 或 OPA 策略控制 IP 池、子网
配置校验	检查 CNI 配置参数是否符合集群规范	验证 IP 分配、MTU、路由规则等参数
审计日志	记录所有 CNI 操作，用于故障排查和安全审计	记录 ADD/DEL 操作的时间、请求者、参数

1.4 CNI 准入策略通信机制架构总览

下图展示了 CNI 准入策略通信机制的整体架构，以及各组件之间的交互关系：

上图展示了 CNI 准入策略通信机制的核心流程：

1. 请求发起：kubelet 收到 Pod 创建指令后，通知容器运行时启动容器。
2. 策略检查：容器运行时在调用 CNI 插件之前，先向准入策略引擎发送网络配置请求。
3. 决策返回：准入策略引擎根据预定义的策略（如 OPA 规则、Kyverno 策略）做出允许或拒绝的决策。
4. 执行配置：如果决策为允许，容器运行时调用 CNI 插件执行网络配置；否则，拒绝操作并记录日志。
5. 审计记录：所有决策和操作均被记录到审计日志，用于后续分析和安全审计。