Kubernetes CRI 网络规范深度解析Pod 沙箱网络生命周期与可插拔运行时设计【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文基于 Kubernetes Community 仓库中 SIG Node 的 CRI 网络规范文档系统讲解容器运行时接口CRIContainer Runtime Interface对 Pod 网络的完整要求从RunPodSandbox建网、StopPodSandbox拆网到UpdateRuntimeConfig下发podCIDR的配置通道再到 kubelet 对运行时网络实现方式的无感知设计。读完本文你将掌握 CRI 网络接口的核心契约、kubelet 与运行时 shim 的职责边界以及 CNI/CNM 等可插拔方案如何在此契约下落地并能结合仓库中的测试与 e2e 示例验证配置的正确性。背景CRI 与 Pod 网络职责的转移CRIContainer Runtime Interface 是一套由规范、protobuf API 与配套库组成的接口目标是让任意容器运行时如 containerd、cri-o通过统一 API 与 kubelet 集成。在 CRI 出现之前容器运行时如 docker、rkt通过实现 kubelet 内部的高层接口完成集成门槛高且维护成本随运行时数量线性增长。CRI 将这一过程标准化后网络这一最复杂的维度也顺理成章地被纳入接口契约。本规范kubelet-cri-networking.md在 Kubernetes Pod 网络需求之上进一步明确了 CRI 层面对运行时的网络要求。需要特别强调的是它的边界该文档不规定 Kubernetes 网络栈上层如Service的需求也不讨论 kubelet 之上控制面的网络组件它聚焦的是节点上Pod 沙箱这一层——即 Pod 从建网、配置 IP、设置路由到拆除网络的完整生命周期由谁负责、如何负责。这一职责转移的最终形态是Pod 网络生命周期的管理权从 kubelet 完全移交给 runtime shimkubelet 只通过 CRI 的沙箱操作与配置更新接口间接影响网络。这也解释了为什么容器运行时会话的仓库文档container-runtime-interface.md把网络规范列为 CRI 的核心子规格之一。核心需求Pod 网络生命周期必须与沙箱操作绑定规范的第一条也是最重要的一条要求是kubelet 期望 runtime shim 管理 Pod 网络的整个生命周期且网络操作必须与 Pod 沙箱操作严格同步。下面逐条拆解四个关键接口的具体契约。RunPodSandbox建网即沙箱创建RunPodSandbox在创建 Pod 沙箱时必须完成网络的建立具体包括但不限于为 Pod 分配 IP 地址配置 Pod 的网络接口配置 Pod 的默认网络路由。规范给出了三条强约束成功语义若RunPodSandbox成功返回kubelet 即认定该 Pod 沙箱拥有一个在 k8s 集群内可路由routable的 IP。这是集群内 Pod 互通的先决条件。失败语义若建网失败RunPodSandbox必须返回错误沙箱创建随之失败。幂等语义若 Pod 网络已经建立RunPodSandbox必须跳过网络设置直接继续避免重复建网。从仓库中的 e2e 测试视角可以印证这一点节点 e2e 测试要求kubelet 需要 CNI 二进制文件加上一份网络配置测试 Pod 才能被分配 IP 和 loopback 接口见 e2e-node-tests.md 附录这正是RunPodSandbox建网能力的真实落地场景。StopPodSandbox拆网即沙箱停止StopPodSandbox在停止沙箱时必须拆除 Pod 网络同样有三条对应约束网络拆除失败时必须返回错误若网络已经拆除则跳过拆除操作继续执行幂等拆除动作与沙箱停止动作在时序上严格关联保证停止后不会残留网络配置。RemovePodSandbox清理兜底RemovePodSandbox在移除沙箱时允许may拆除 Pod 网络——前提是网络尚未被拆除。这为Stop 时已拆网与Stop 后残留网络两种情况都提供了明确语义已拆则跳过未拆则补拆无论哪种路径拆网失败都必须返回错误。PodSandboxStatus网络状态必须可查询PodSandboxStatus的响应必须包含 Pod 沙箱的网络状态。当 runtime shim 因某种原因无法构建网络状态时必须返回空的网络状态empty network status而不是报错中断以保证状态查询接口的稳定可用。四个接口合起来构成一条完整的生命周期闭环创建建网→ 状态查询含网络状态→ 停止拆网→ 移除兜底清理。任何运行时只要实现 CRI就必须同时遵守这套网络生命周期契约否则 Pod 网络行为将与 kubelet 的预期不一致。配置通道两条路径、两种责任规范将网络配置清晰地划分为两类分别走不同的传递通道这是理解 CRI 网络模型的关键。路径一用户级配置由 runtime shim 直接处理有一类用户提供的网络配置并不通过 Kubernetes API 暴露规范明确要求由 runtime shim 直接处理且 kubelet 在 CRI 迁移完成后不再处理这些配置。文档列出的典型项包括配置项语义hairpin-mode是否开启 hairpin 模式允许 Pod 通过其自身 IP 访问自己暴露的端口常见于某些负载均衡/NAT 场景cni-bin-dirCNI 插件二进制文件所在目录cni-conf-dirCNI 网络配置文件所在目录network-plugin使用的网络插件名如cni、kubenet等network-plugin-mtu网络插件使用的 MTU 值non-masquerade-cidr不做 SNAT 伪装masquerade的 CIDR 白名单仓库中能找到这些 kubelet 标志在真实测试环境中的用法。例如 test-suite.md 中节点 e2e 测试的 kubelet 启动参数即为--kubelet-flags--network-plugin --cni-bin-dir通过显式传空值来覆盖默认网络插件与 CNI 二进制目录说明这两个标志在 kubelet 侧确实存在且测试环境会按需注入。而在 CRI 模型下这类参数最终要由 runtime shim 消费——这也正是kubelet 不再处理的含义kubelet 只负责透传节点级配置网络插件的装载、解析与执行全部下沉到 shim。路径二API 暴露的配置通过 UpdateRuntimeConfig 下发另一类配置通过 Kubernetes API 暴露例如podCIDR节点 Pod 网段。这类配置由 kubelet 通过UpdateRuntimeConfig接口传达给 runtime shim。规范对这条通道的约束较为宽松但语义清晰每种 runtime 与网络实现的适用配置不同shim 可以根据自身实现选择处理或忽略来自UpdateRuntimeConfig的更新这是配置协商而非强制下发——运行时按需消费kubelet 不做强校验。这种设计保证了接口的通用性podCIDR对 CNI 类运行时通常用于 IPAMIP 地址管理或路由通告但对某些网络实现可能无意义shim 有权忽略。从仓库的 e2e 环境配置可反推其实际影响e2e-node-tests.md 附录中的 CNI bridge 配置即通过host-localIPAM 在10.88.0.0/16子网内分配地址这类网段分配与路由配置正是podCIDR下发后需要 shim 配合的部分。可扩展性kubelet 对网络实现保持无感知规范用三条原则定义了 CRI 网络的可扩展性边界实现自由kubelet 对 runtime shim 如何管理网络视而不见——shim 可以自由使用CNIContainer Network Interface、CNMDocker libnetwork 的容器网络模型或任何其他实现只要满足本规范与 k8s 网络需求即可。配置透明runtime shim 对 Pod 网络配置拥有完全可见性full visibility即 shim 能读取到建网所需的全部信息不依赖 kubelet 代劳。随需演进随着更多网络特性出现CRI 规范本身将持续演进。这一协议化思路与 CRI 的整体设计一脉相承正如 container-runtime-interface.md 所述CRI 旨在通过小而重要的接口实现可插拔运行时、构建更健康的生态。网络层面把如何实现完全留给 shim把何时建网、何时拆网、状态如何上报固化为契约正是该理念在节点网络维度的具体化。仓库中的 CNI 落地示例节点 e2e 测试文档的附录给出了一套完整的 CNI 安装与配置流程可作为理解shim 如何消费cni-bin-dir与cni-conf-dir的实操样例安装 CNI 插件二进制到/opt/cni/bin对应cni-bin-direxport CNI_VERSIONv1.4.0 # 替换为近期的稳定版本 wget https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz sudo mkdir -p /opt/cni/bin sudo tar Cxzvf /opt/cni/bin cni-plugins-linux-amd64-${CNI_VERSION}.tgz写入网络配置到/etc/cni/net.d对应cni-conf-dir。文档中的 bridge 示例同时演示了接口、网关、NAT 与 IPAM 子网/路由的完整定义{ cniVersion: 1.0.0, name: containerd-net, plugins: [ { type: bridge, bridge: cni0, isGateway: true, ipMasq: true, promiscMode: true, ipam: { type: host-local, ranges: [ [{ subnet: 10.88.0.0/16 }], [{ subnet: 2001:db8:4860::/64 }] ], routes: [ { dst: 0.0.0.0/0 }, { dst: ::/0 } ] } } ] }这段配置恰好覆盖了RunPodSandbox建网契约的全部要素分配 IPhost-local IPAM、配置网络接口bridgecni0、设置默认路由0.0.0.0/0与::/0并额外体现了isGateway网关与ipMasqSNAT 伪装与non-masquerade-cidr白名单逻辑互补等选项。任何 CRI runtime shim 在收到RunPodSandbox后执行 CNI ADD 时正是读取此类配置完成建网。关联问题与演进脉络文档末尾记录的关联 issue 反映了 CRI 网络能力落地时的关键工程节点#28667client/server 容器运行时的 kubelet 网络插件问题——即网络插件逻辑究竟该放 kubelet 还是运行时的早期讨论最终导向了本规范shim 负责建网的结论。#37316CRI 网络的总纲问题umbrella issue用于跟踪 CRI 网络相关需求与实现的整体进度。结合仓库中的历史记录可以进一步确认这一演进方向社区会议纪要communication/meeting-notes-archive中多次出现将更多 kubenet 迁移到 CNI流量整形traffic shaping迁移为 CNI 插件等讨论说明 kubelet 内置网络功能逐步外置到 CNI 生态与kubelet 不再处理network-plugin等配置的规范表述完全同向。而 CRI 容器指标规范 中runtime 需确保 Pod 沙箱使用全部资源的表述也从侧面说明沙箱含其网络命名空间的完整性由 runtime 统一兜底与网络生命周期下沉到 shim 的设计一致。结语一份写给运行时实现者的契约CRI 网络规范本质上是一份面向容器运行时实现者的契约它不规定建网用什么技术CNI、CNM 皆可却严格规定建网/拆网在何时发生与沙箱生命周期绑定、失败如何处理必须报错、状态如何上报PodSandboxStatus含网络状态、配置从哪来用户级配置 shim 自理podCIDR等 API 配置走UpdateRuntimeConfig。对于运行时开发者遵守这套契约意味着 Pod 网络行为可预期对于 kubelet 侧开发者则意味着网络细节可以被彻底屏蔽让节点组件得以保持精简。读懂这份规范是理解现代 CRI 运行时containerd、cri-o 等网络实现的前提。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考