Kubernetes WG Checkpoint Restore 2025 年度报告解读Checkpoint/Restore 工作组落地与 Kubernetes 容器检查点恢复全景【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/communityCheckpoint/Restore检查点/恢复是 Kubernetes 社区讨论了五年以上的功能方向目标是让工作负载容器与 Pod能够透明地被“冻结并保存”再在需要时恢复运行从而支撑故障容错、资源利用率优化与冷启动加速等场景。本篇文章以 Kubernetes Community 仓库中 wg-checkpoint-restore/annual-report-2025.md 为核心结合该工作组 宪章、工作组主页、仓库主清单 sigs.yaml 以及 sig-list.md 等文档系统解读工作组在 2025 年度的成立背景、组织形态、当前状态与下一步规划帮助读者理解 Kubernetes 社区如何以工作组形式推进 Checkpoint/Restore 的 API 设计与实现以及你该如何参与其中。一、年度报告核心信息一个在 2025 年 12 月正式成立的工作组2025 年度报告 是这份文档的主体篇幅虽短但信息量明确这是一个刚刚完成起步的工作组。1.1 本年度重点工作What work did the WG do this year报告原文明确指出In 2025, the working group was established and held its first meeting in December. The working group set up all the usual infrastructure like mailing list, calendar, Slack channel, and Zoom meeting.翻译过来即工作组于 2025 年成立并在 12 月召开了第一次会议工作组搭建了常规协作基础设施包括邮件列表mailing list、日历calendar、Slack 频道与 Zoom 会议。这意味着 2025 年度的工作重点并非技术实现而是组织起步bootstrapping建立沟通渠道、确定会议节奏、对齐成员。这与 宪章 中早期阶段主要提供一个明确定义的地点供社区查找信息、提问、讨论在 Kubernetes 中启用 checkpoint 和 restore 的下一步的交付物描述完全一致。1.2 需要帮助的领域Areas needing help报告回答是否有需要帮助的领域/子项目如活跃 OWNERS 少于 2 人时表示由于工作组刚刚开始工作目前尚不需要帮助。这也与 wg-checkpoint-restore/OWNERS 的现状吻合——该文件指定了唯一的 approvers/reviewers 组wg-checkpoint-restore-leads权限集中、结构简洁。1.3 运维清单Operational与赞助 SIG报告列出了一份标准的年度运维检查清单README.md 内容准确性复核与更新若需要sigs.yaml 中的 WG 负责人信息准确且活跃若需要则更新2025 年会议记录与录像已链接到 README.md若需要则更新/上传已向赞助 SIG 提供更新包括 SIG Apps、SIG Auth、SIG Node、SIG Scheduling——目前均标注 No updates yet (WG established in December 2025)这些条目均以未勾选[ ]状态呈现反映了新工作组第一年万事待兴的真实状态基础设施已就位但内容填充与跨 SIG 汇报仍在路上。清单中引用的 wg-governance.md 是 Kubernetes 工作组治理模板定义了工作组的角色与组织管理要求。二、背景纵深Checkpoint/Restore 为什么值得一个专门工作组年度报告本身只记录 2025 年的组织进展但要想真正读懂这份报告需要理解工作组要解决的技术问题。这些背景完整记录在 宪章 中。2.1 目标在 Kubernetes 中透明地检查点与恢复工作负载宪章 Scope 部分开门见山The Checkpoint/Restore Working Group aims to solve the problem of transparently checkpointing and restoring workloads in Kubernetes, a functionality discussed for over five years.即该工作组致力于解决在 Kubernetes 中透明地保存checkpoint与恢复restore工作负载的问题——这一功能在社区中已被讨论了五年以上。工作组将交付 Kubernetes 中 Checkpoint/Restore 功能的设计与实现并作为社区信息和讨论的中心枢纽。值得注意的是这个议题在仓库中的历史痕迹可以追溯到更早在 sig-node/archive/meeting-notes-2017.md 中就已有 Pod checkpointing proposal 的讨论到 2021 年SIG Node 会议记录meeting-notes-2021.md中出现了 checkpoint/restore KEP reworked and ready for review 的阶段性进展。宪章中引用的 kep2008 可以看到该 KEP 对应的能力已随 v1.25 进入 Alpha并在 2025 年度报告 中标注为 v1.33 状态。2.2 解决的问题域容错、资源利用率与启动加速宪章明确列出该功能将解决的一批问题故障容错fault tolerance通过检查点保存运行状态崩溃或节点故障后可恢复而非从零重启改善资源利用率improved resource utilization空闲工作负载可先被冻结保存释放资源给其他负载需要时再恢复加速应用启动时间accelerated application startup times恢复一个已有的内存状态远比冷启动并完成初始化快。2.3 范围内与范围外In scope / Out of scope宪章对工作组的边界做了清晰界定范围内包括识别 Kubernetes checkpoint/restore 的核心用例如实时迁移 live migration、故障容错、调试 debugging、快照 snapshotting并收集利益相关方需求调研并提出 Kubernetes 中 checkpoint/restore 操作的 API与各 SIG 协作实现 checkpoint/restore 功能与 API 的最佳集成为开发者提供checkpoint 友好应用设计的指导为运维人员提供功能管理建议与上游项目CRI-O、containerd、CRIU、gVisor紧密合作保证对齐与集成复审既有实现发现并修复潜在低效点——宪章特别举例现有 checkpoint 归档格式已被识别为速度瓶颈的主要来源之一。范围外包括不关注 Kubernetes Pod/容器之外的一般操作系统级检查点不规定应用内部的检查点逻辑只聚焦 Kubernetes 平台对容器/Pod 状态的编排。2.4 交付物路线图宪章将交付物分为两个阶段早期阶段为社区提供一个明确定义的地点供查找信息、提问、讨论下一步。后续阶段使用kubectl检查点并恢复单个容器使用kubectl检查点并恢复整个 Pod将容器/Pod 检查点纳入调度决策scheduling decisions。第三项尤其值得关注——它意味着 checkpoint/restore 不只是运行时CRI能力还将深刻影响调度器设计这正是 SIG Scheduling 成为赞助 SIG 的原因。三、组织架构谁在牵头如何协作3.1 赞助 SIG 与利益相关方Checkpoint/Restore 横跨多个 SIG因为它们分别持有 Kubernetes 核心组件与插件中相关代码的所有权。宪章列出的利益相关方与 sigs.yaml 中的stakeholder_sigs一致SIG与 Checkpoint/Restore 的关联SIG Node拥有 kubelet、CRI 集成与运行时checkpoint 执行端SIG Scheduling调度决策中集成检查点状态恢复调度、资源再分配SIG Authcheckpoint 归档的访问控制与安全归档含内存页可能有敏感数据SIG Apps应用工作负载的使用场景与 API 形态SIG Node 在 2025 年度报告 中明确写道The SIG is happy to sponsor ... two new working groups: WG node lifecycle and WG checkpoint restore.——直接印证了 WG Checkpoint Restore 是在 2025 年由 SIG Node 等赞助成立的新工作组。3.2 负责人与沟通渠道根据 sigs.yaml第 3666–3718 行与 wg-checkpoint-restore/README.md工作组当前由四位 co-chairs 领导与 OWNERS_ALIASES 中的wg-checkpoint-restore-leads一一对应Adrian ReberadrianreberRed Hat——长期深耕 checkpoint/restoreCRIU 与 CRI-O 集成的主要推动者Andrey VelichkevichandreyvelichApplePeter HunthaircommanderRed Hat——CRI-O 核心维护者Radostin Stoyanovrst0gitUniversity of Oxford——CRIU 领域研究者。Steering Committee Liaison指导委员会联络人为 Benjamin ElderBenTheElder。沟通渠道包括Slack#wg-checkpoint-restore邮件列表wg-checkpoint-restorekubernetes.ioGitHubissues/PR 使用wg/checkpoint-restorelabel 标记会议两组定期会议详见下文 3.3与仓库中 communication/slack-config/channels.yaml 等社区通信基础设施配套3.3 会议节奏来自 sigs.yaml 的结构化数据sigs.yaml 中记录了两组会议的完整元数据比 README 更结构化会议时间频率用途Regular WG Meeting (Asia/Europe)每周三 08:00 UTC双周bi-weekly覆盖亚太与欧洲时区Regular WG Meeting (Europe/America)每周四 17:00 UTC每周weekly覆盖欧洲与美洲时区两组会议共用同一 Zoom 链接95866823079、同一份会议记录文档与同一 YouTube 录像播放列表。加入邮件列表即可在日历中自动收到会议邀请——这也是年度报告中calendar基础设施的实际体现。四、从历史脉络看技术现状年度报告之外的事实虽然 2025 年度报告只讲组织建设但仓库中的 SIG Node 会议记录与年度报告提供了丰富的历史技术上下文让读者能理解工作组接下来要做什么。以下事实均有仓库记录可查4.1 KEP-2008 与容器检查点功能的演进v1.252022SIG Node 2022 年度报告 记录了 2008 - Forensic Container Checkpointing 随 v1.25 发布Alpha 阶段的容器检查点能力落地持续演进SIG Node 2024 年度报告 将其标注为 v1.30 状态2025 年度报告 更新为 v1.33安全性考量SIG Node 2022 会议记录 记录了关于如何保护 checkpoint 的讨论——checkpoint 归档包含全部内存页可能含有 secrets、随机数讨论方案包括为 kubelet checkpoint API 端点增加额外授权、将其运行在独立端口、以及用 ocicrypt 加密归档。Alpha 阶段的设计共识是checkpoint 归档仅允许本地 root 用户访问Beta 阶段再考虑更细粒度的授权。这些正是宪章中与 SIGs 合作实现最佳集成复审既有实现所指的具体工作背景。4.2 归档格式与 OCI 镜像方向SIG Node 2022 会议记录 还揭示了两个关键技术方向最初 checkpoint 归档写入本地文件系统随后成功实现了将 checkpoint 打包为OCI 镜像存入本地 registrycontainerd 与 CRI-O 均已完成实验性实现这是社区早期讨论时就提出的诉求曾讨论是否完全放弃本地文件系统归档、只保留镜像形式以及是否移除 checkpoint 目的地参数。宪章中现有 checkpoint 归档格式已被识别为速度瓶颈的表述与这些讨论一脉相承——归档格式的演进正是工作组要复审与优化的核心议题之一。4.3 实操层面的历史示例供理解使用方式SIG Node 2024 会议记录 中给出了 Alpha 阶段的真实操作路径可以帮助读者具象化checkpoint/restore 是什么通过 kubelet checkpoint API 对容器发起检查点curl -s --insecure --cert /var/run/kubernetes/client-admin.crt --key /var/run/kubernetes/client-admin.key -X POST https://localhost:10250/checkpoint/default/counters/counter或将kubectl alpha checkpoint counters加入 kubectl对应 kubernetes/kubernetes#120898检查点产物形如/var/lib/kubelet/checkpoints/checkpoint-pod-name_namespace-name-container-name-timestamp.tar用buildah将其制作为可运行镜像buildah add $newcontainer checkpoint.tar /、buildah config --annotationio.kubernetes.cri-o.annotations.checkpoint.namecounter、buildah commit $newcontainer checkpoint-image:latest。Pod 级检查点的思路是遍历 Pod 内所有容器逐一创建 checkpoint再基于元数据不含 checkpoint重建 Pod。当前 WG 宪章中使用 kubectl 检查点/恢复容器与 Pod的交付物正是要在此基础上推进到标准化 API 与调度集成。五、如何参与与后续展望5.1 参与路径对于希望跟进或参与的开发者仓库给出了清晰的入口阅读 工作组主页 README 获取会议、议程与录像链接阅读 宪章 charter.md 了解范围、边界与交付物加入邮件列表接收会议邀请参与双周/每周例会在 Slack#wg-checkpoint-restore频道提问与讨论在 Kubernetes 仓库中以wg/checkpoint-restorelabel 提交 issue/PR关注 sig-list.md 中的工作组条目含负责人与会议信息的汇总索引。5.2 时间线与解散机制宪章对工作组的生命周期做了明确规划首个任期的第一个季度提出草案路线图draft roadmap识别关键任务之后促进社区成员协作探索可能的 API 并起草集成提案提交给相关 SIG解散条件达成交付物容器/Pod 级 checkpoint/restore、调度集成后即可解散工作组不会长期转为 SIG。5.3 下一步观察点综合年度报告与宪章2026 年值得关注的工作组里程碑包括首季度路线图发布宪章要求在第一个季度内提出草案路线图API 提案成型探索 checkpoint/restore 的 Kubernetes API 形态并提交 SIG 评审与 CRI-O / containerd / CRIU / gVisor 的对齐继续推进运行时层面的集成如 checkpoint 归档格式优化向四个赞助 SIG 的首轮正式汇报年度报告清单中 No updates yet 的状态将被逐步填充kubectl 层面的 checkpoint/restore 命令从历史讨论如kubectl drain --checkpoint原型走向正式实现。六、总结2025 年度的 WG Checkpoint Restore 年度报告 是一份组织奠基性质的文档它记录了一个横跨 SIG Node、SIG Scheduling、SIG Auth、SIG Apps 的工作组如何在 2025 年 12 月完成成立、召开首次会议并搭好全部协作基础设施。要理解这份报告的重量需要结合 宪章 看到其背后的技术雄心——解决 Kubernetes 中透明 checkpoint/restore 这一讨论了五年以上的议题覆盖故障容错、资源利用与启动加速并最终把检查点能力带入调度决策。对于社区观察者这份报告意味着 Kubernetes 容器检查点/恢复工作正式从零散的个人与 SIG 推动走向专门的社区组织化推进对于开发者参与入口已经全部开放——从加入邮件列表、参加例会到提交wg/checkpoint-restore标记的 issue/PR再到在宪章范围内探索 API 提案都是切实可行的贡献方式。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考