Kubernetes CRI容器运行时接口完全指南从设计原理到实现与验证【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读CRIContainer Runtime Interface容器运行时接口是 Kubernetes 在节点侧定义的一组规范、protobuf API 与配套库它划清了 kubelet 与容器运行时如 containerd、cri-o之间的边界。本文以 contributors/devel/sig-node/container-runtime-interface.md 为主体结合本仓库中 kubelet 组件说明、CRI 网络规范、容器指标与测试策略等姊妹文档系统讲解 CRI 的产生动机、API 组成、网络与指标扩展、历史版本演进、已知问题与验证方法。读完本文你将理解 kubelet 如何通过 CRI 管理 Pod 与容器的完整生命周期并掌握运行时接入 Kubernetes 所需的测试与发布流程。CRI 是什么kubelet 与运行时之间的标准接口CRI 由三部分构成规格与需求specifications/requirements定义运行时必须满足的行为契约原文档标注为to-be-added即持续演进中protobuf API定义 kubelet 与运行时之间的 gRPC 消息与 RPC 服务即 Kubernetes 中staging/src/k8s.io/cri-api/pkg/apis/runtime/v1/api.proto对应的那一组定义配套库libraries例如 Kubernetes 中pkg/kubelet/cri/streaming为 exec、attach、port-forward 等流式请求提供实现支撑。从项目定位看CRI 是容器运行时在节点上与 kubelet 集成的唯一通道。文档撰写时 CRI API 处于 Alpha 阶段且自 Kubernetes 1.7 起CRI-Docker 集成成为默认方案历史版本信息详见下文版本演进一节。在理解 CRI 前需要先建立一条关键链路kubelet 通过 CRI 把声明式的 Pod Spec 翻译成命令式的运行时操作运行时再进一步交给 OCI 运行时如 runc完成底层操作系统级容器设置。这条链路在本仓库 kubelet.md 中有完整的代码级描述下文会展开。为什么需要 CRI从内部接口到插件化生态在 CRI 出现之前容器运行时如docker、rkt是通过在 kubelet 内部实现一个高层的内部接口来完成集成的。这种做法存在两个根本性问题入门门槛极高运行时集成方必须理解 kubelet 内部实现并且要把代码贡献到 Kubernetes 主仓库任何改动都要经过 Kubernetes 核心评审不可扩展每新增一个运行时都会在 Kubernetes 主仓库中产生一笔持续性的维护开销随着运行时数量增长维护成本会线性膨胀。Kubernetes 的定位是可扩展平台。CRI 正是为了实现可插拔的容器运行时、构建更健康的生态而迈出的小而关键的一步运行时作者只需面向稳定的 CRI API 编程无需触碰 kubelet 内部逻辑。从本仓库 kubelet.md 的实现描述可以印证这一分层kubelet 的kuberuntime模块承担声明式 API 到命令式 CRI API的翻译例如在startContainer流程中它会先生成容器配置将 Kubernetes API 对象翻译为 CRI spec再调用 CRI 的CreateContainer与StartContainer。运行时是否真正以 OCI 方式创建容器kubelet 完全不关心。如何使用 CRI启用方式与版本约束CRI 的使用方式随 Kubernetes 版本不同而有差异。文档以 1.5 时代为例给出了显式开启所需的额外参数API Server 侧设置--feature-gatesStreamingProxyRedirectstrue开启流式请求代理重定向特性门控kubelet 侧设置--experimental-critrue显式开启实验性的 CRI 支持。文档同时提醒CRI 当时仍处于早期阶段社区正在积极吸收开发者反馈以改进 API虽然尽力保持向后兼容但开发者仍应预期偶尔会出现破坏性 API 变更。安装与配置的权威指引以官方 CRI 安装文档为准。Kubelet 是否使用 CRI答案是总是使用文档给出了明确结论除 rktnetes 集成之外kubelet 总是使用 CRI。旧的非 CRI Docker 集成已在 Kubernetes 1.7 中被彻底移除。结合本仓库 kubelet.md可以看清 CRI 在 kubelet 实际运行中的位置Pod 创建kubelet 观察到绑定到本节点的 Pod 后进入SyncPod主流程最终交由kuberuntime_manager.SyncPod处理容器操作Sandbox 生命周期kubelet 通过createPodSandbox创建 Pod 沙箱sandbox沙箱是 CRI 中承载 Pod 网络与命名空间的抽象容器生命周期kubelet 通过 CRI 依次调用CreateContainer、StartContainer、StopContainer等 RPC稳态维护PLEGPod Lifecycle Event Generator以约 2 秒为周期轮询运行时检测状态变化触发同步循环终止与回收KillPod经由 CRI 停止容器与沙箱容器 GC 与镜像 GC 周期性清理已退出容器和未使用镜像。也就是说从 Pod 的诞生到终结kubelet 对容器的每一次操作都经由 CRI 这一层统一出口完成。深入 CRI 网络规范沙箱操作与网络生命周期CRI 对网络的要求由 kubelet-cri-networking.md 专门规定它是对 Kubernetes Pod 网络需求的扩展但不涉及 Service 等上层网络抽象。核心要求可归纳为三条1. 网络生命周期必须随沙箱操作管理kubelet 期望运行时 shim 在沙箱操作中同步管理 Pod 网络RPC网络行为要求RunPodSandbox必须完成网络设置包括分配 Pod IP、配置网络接口与默认路由。成功后 Pod 沙箱必须拥有集群内可路由的 IP网络设置失败必须返回错误若网络已设置则跳过设置继续执行StopPodSandbox必须拆除 Pod 网络拆除失败必须返回错误若网络已拆除则跳过继续执行RemovePodSandbox若网络尚未拆除可以顺带拆除拆除失败必须返回错误PodSandboxStatus响应中必须包含沙箱网络状态无法构造网络状态时返回空网络状态2. 用户级网络配置由运行时 shim 直接处理凡是不直接暴露在 Kubernetes API 中的网络配置如hairpin-mode、cni-bin-dir、cni-conf-dir、network-plugin、network-plugin-mtu、non-masquerade-cidr等应由运行时 shim 自行处理。CRI 迁移完成后kubelet 将不再触碰这些配置。3. API 暴露的配置通过UpdateRuntimeConfig下发通过 Kubernetes API 暴露的网络配置例如podCIDR经由UpdateRuntimeConfig接口传递给运行时 shim。不同运行时/网络实现可自行决定处理或忽略这些更新。可扩展性设计kubelet 对 shim 如何管理网络一无所知shim 可以自由使用 CNI、CNM 或任何其他实现只要满足 CRI 网络需求与 Kubernetes 网络需求即可运行时 shim 对 Pod 网络配置拥有完整可见性随着更多网络特性的出现CRI 本身将持续演进。深入 CRI 容器指标CPU、内存与文件系统统计在 CRI 之前kubelet 依赖独立的 cAdvisor 库获取容器 CPU、内存等指标每个接入 Kubernetes 的运行时都需要在 cAdvisor 中增加对应包来支持指标跟踪这构成了又一个独立集成点。CRI 成为新抽象后自然演进为由 CRI 直接承载容器指标消除这一额外的集成点详见 cri-container-stats.md。指标 API 设计CRI 暴露两个指标相关 RPC// ContainerStats returns stats of the container. If the container does not // exist, the call returns an error. rpc ContainerStats(ContainerStatsRequest) returns (ContainerStatsResponse) {} // ListContainerStats returns stats of all running containers. rpc ListContainerStats(ListContainerStatsRequest) returns (ListContainerStatsResponse) {}返回的ContainerStats消息覆盖三类资源// ContainerStats provides the resource usage statistics for a container. message ContainerStats { // Information of the container. ContainerAttributes attributes 1; // CPU usage gathered from the container. CpuUsage cpu 2; // Memory usage gathered from the container. MemoryUsage memory 3; // Usage of the writable layer. FilesystemUsage writable_layer 4; } // CpuUsage provides the CPU usage information. message CpuUsage { // Timestamp in nanoseconds at which the information were collected. Must be 0. int64 timestamp 1; // Cumulative CPU usage (sum across all cores) since object creation. UInt64Value usage_core_nano_seconds 2; } // MemoryUsage provides the memory usage information. message MemoryUsage { // Timestamp in nanoseconds at which the information were collected. Must be 0. int64 timestamp 1; // The amount of working set memory in bytes. UInt64Value working_set_bytes 2; } // FilesystemUsage provides the filesystem usage information. message FilesystemUsage { // Timestamp in nanoseconds at which the information were collected. Must be 0. int64 timestamp 1; // The underlying storage of the filesystem. StorageIdentifier storage_id 2; // UsedBytes represents the bytes used for images on the filesystem. // This may differ from the total bytes used on the filesystem and may not // equal CapacityBytes - AvailableBytes. UInt64Value used_bytes 3; // InodesUsed represents the inodes used by the images. // This may not equal InodesCapacity - InodesAvailable because the underlying // filesystem may also be used for purposes other than storing images. UInt64Value inodes_used 4; }设计要点为何使用带时间戳的缓存统计每个资源用量消息都包含一个timestamp标明统计数据的采集时刻。原因在于不同资源如文件系统的采集成本差异很大更新频率可能低于其他资源。有了时间戳消费方kubelet可以判断数据的新鲜程度同时给运行时调整采集节奏的灵活性。需要特别指出CRI 不规定统计的更新频率但 kubelet 对某些资源有最低新鲜度保证的需求以便在资源压力下及时回收这类需求将被逐步纳入 CRI 规范。此外Kubelet 负责按 QoS 类别创建 Pod 级 cgroup 并作为父 cgroup 传给运行时确保 Pod 沙箱、容器等所有资源都被计入对应 cgroup因此 kubelet 自己借助内建 cAdvisor就能跟踪 Pod 级资源用量CRI 指标增强聚焦于容器级。演进状态容器指标 RPC 在 Kubernetes 1.7 中加入 CRI但当时 kubelet 尚未消费1.8 起 kubelet 才获得通过 CRI stats 消费容器指标的选项并依据相应开关函数决定指标来源使用 CRI stats 还是旧版 cAdvisor stats。规范、设计文档与提案原文档给出了一组 CRI 相关的规范/设计文档与提案清单外部链接此处不再重复输出仓库内可深入阅读的部分如下原始提案Kubernetes 1.5 发布的 CRI 总体方案网络规范kubelet-cri-networking.md上文已详解容器指标cri-container-stats.md上文已详解Exec/attach/port-forward 流式请求定义了 kubelet 与运行时之间流式通道的转发/重定向机制容器 stdout/stderr 日志定义了容器日志路径与格式规范。CRI 运行时实现盘点文档列出了当时活跃的 CRI 运行时实现cri-o为 Kubernetes 量身打造的轻量运行时直接面向 OCI 容器rktlet让 rkt 通过 CRI 接入 kubelet 的 shimfrakti基于 hypervisor 的运行时 shim提供更强的隔离性cri-containerdcontainerd 的 CRI 插件实现如今已是 Kubernetes 节点侧事实标准Node E2E 测试文档即默认要求 containerd 开启 CRI 插件见 e2e-node-tests.mdsingularity-cri面向 HPC 场景的 Singularity 容器运行时 shim。这些实现从侧面印证了 CRI 的插件化价值无论底层是 OCI 兼容运行时、rkt、hypervisor 还是 HPC 专用运行时都能通过实现同一套 CRI API 接入 Kubernetes。版本演进与状态更新原文档以版本为线索记录了 CRI 的成熟过程是理解其演进脉络的重要史料Kubernetes v1.5CRI v1alpha1发布 CRI v1alpha1 版本此版本需通过--feature-gatesStreamingProxyRedirectstrueapiserver与--experimental-critruekubelet显式开启。Kubernetes v1.6Docker-CRI 集成进入 Beta 并默认启用升级建议升级 kubelet 前先 drain 节点若选择原地升级kubelet 会重启节点上所有 Kubernetes 托管的容器资源与性能实测无性能回退kubelet 内存占用因 CRI 的 gRPC 序列化而略有增加约每个 Pod 0.27MB禁用方式设置--enable-crifalse可回退到旧实现但旧实现已被弃用计划在下个版本移除鼓励尽早迁移到 CRI其他变化Docker 容器命名/标签方案在 1.6 中有显著变化这被视为实现细节外部工具或脚本不应依赖。Kubernetes v1.7Docker-CRI 集成 GA容器指标 API 落地Docker CRI 集成提升为 GA一般可用旧的非 CRI Docker 集成从 kubelet 中完全移除弃用的--enable-cri参数一并删除CRI 扩展支持从运行时收集容器指标对应上文容器指标 API。已知问题与边界以 1.5 版本为基准原文档记录了 1.5 版本时的已知问题供集成方与使用者参考此后可能已修复CRI 层面容器指标尚未定义于 CRI对应 issue 27097——该问题在 1.7 由容器指标 API 解决新的容器日志路径/格式尚未被日志管道如 fluentd、GCL支持对应 issue 36401CRI 可能与其他实验性特性如 Seccomp不兼容流式服务器需要加固认证问题对应 issue 36666避免在重定向 URL 中包含用户数据对应 issue 36187。Docker CRI 集成层面Docker 兼容性仅支持 Docker v1.11 与 v1.12网络不支持主机端口host ports对应 issue 35457不支持带宽整形bandwidth shaping对应 issue 37315流式请求不支持以nsenter作为 exec 处理器--exec-handlernsenter对应 issue 35747。如何验证你的运行时CRI 测试策略CRI 的价值建立在可验证之上。本仓库 cri-testing-policy.mdSIG-Node 所有规定了运行时实现者必须执行的测试与结果发布流程必测与推荐测试必测requiredNode conformance test suite节点一致性套件平台无关验证 OS 镜像的一致性Node feature test suite节点特性套件展示运行时在特定 OS 发行版上支持哪些特性强推荐strongly recommendedKubernetes conformance test suite集群级 E2E覆盖 CRI 与节点级测试无法覆盖的网络等领域因网络涉及运行时、云厂商与集群组件的深度集成建议向相关 SIG 寻求指导或赞助。Node E2E 测试框架与兼容 OS 镜像验证方法见 e2e-node-tests.md本地运行make test-e2e-nodeLinux only需 etcd、开启 CRI 插件的 containerd、CNI 配置远程运行make test-e2e-node REMOTEtruekubelet 在启用 swap 的主机上默认拒绝启动需通过TEST_ARGS--kubelet-flags--fail-swap-onfalse放行。此外运行时开发者被强烈鼓励在开发过程中运行低层的 CRI 验证测试套件cri-tools 项目中的 validation 套件。测试结果发布流程在 Kubernetes community 仓库提交提案简要说明运行时、提供至少两位维护者并将提案指派给 SIG-Node leads测试结果发布在sig-node标签页下组织方式为sig-node - sig-node-cri-{Kubernetes-version} - [包含必测任务的页面]任何时候只保留最近三个 Kubernetes 版本与 master 分支的结果与 Kubernetes 发布节奏一致。测试任务维护与 pre-submit测试至少每晚运行一次若测试被认为未积极维护SIG-Node 可酌情将其移出测试网格测试连续通过超过 2 周后维护者可申请将其纳入 PR pre-submit 测试pre-submit 对测试容量与稳定性要求显著更高若测试 flaky 或失败且维护者未及时修复SIG leads 可将运行时移出 pre-submit当前 SIG-Node 只接受将 Node conformance 测试提升为 pre-submit集群级 conformance 涉及更广范围可能需要其他 SIG 联合赞助Windows 容器仍处早期阶段建议按白名单特性集运行部分测试。小结CRI 是 Kubernetes 节点侧最关键的抽象之一它以一组 protobuf API 与配套库把 kubelet 与容器运行时的集成从内部接口 主仓库贡献转变为稳定 API 独立实现并配套了网络生命周期、容器指标、流式请求等细化规范与一整套验证测试策略。对于想要为 Kubernetes 实现或选用运行时的工程师本文连同仓库内的 kubelet-cri-networking.md、cri-container-stats.md、cri-testing-policy.md、kubelet.md 与 e2e-node-tests.md 构成了完整的从原理到验证的参考闭环。联系方式SIG-Node 邮件列表 sig-nodekubernetes.ioSlack 频道 #sig-node。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
