Kubernetes SIG Storage 2024 年度报告解读GA 里程碑、CSI 生态与存储演进全景【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/communitySIG StorageStorage Special Interest Group是 Kubernetes 社区中负责文件与块存储的核心小组其 2024 年度报告sig-storage/annual-report-2024.md系统梳理了该年度四个 GA 里程碑、三个 Beta 进展与多个 Alpha 特性覆盖从 Kubelet 卷管理、PV 生命周期到 CSI 快照、在线卷修改等关键能力。本文以这份年度报告为主线结合本仓库中的 SIG Storage Charter、README、贡献指南 与根目录 sigs.yaml 中的权威条目逐项解读这些特性解决的真实问题及其工作机制帮助读者建立对 Kubernetes 存储演进脉络的完整认知。一、SIG Storage 的职责边界年度报告背后的治理框架要理解年度报告中的每一项成果首先要明确 SIG Storage 到底管什么。根据 SIG Storage Charter 的定义SIG Storage 负责确保不同类型的文件与块存储无论是临时还是持久、本地还是远程在容器被调度的任何位置都可用具体包括卷的全生命周期操作供给/创建provisioning/creating、挂接attaching、挂载/卸载mounting/unmounting、摘除detaching以及删除deleting存储容量管理容器临时存储ephemeral storage用量、卷扩容volume resizing等基于存储影响调度数据引力data gravity、可用性等通用存储操作快照snapshotting等。在范围内in scope的特性包括 Persistent Volume Claims / Persistent Volumes、Storage Classes 与动态供给、Kubernetes 卷插件、Container Storage InterfaceCSI以及与 SIG-Node 共有的 Secret/ConfigMap/DownwardAPI/EmptyDir 卷。范围外out of scope则包括远端存储的数据通路如 GCE PD、AWS EBS、NFS 的比特传输与存放位置以及容器可写层由 SIG Node 负责。这一职责边界解释了为什么 2024 年度报告的核心成果几乎都集中在PV/PVC 控制器、Kubelet 卷管理器、CSI 侧车sidecar生态三个层面——它们正是 charter 中明确由 SIG Storage 拥有的代码、二进制与服务Kubernetes 内部控制器与 API、外部 sidecar 容器与二进制、接口以及对应的单元/集成/E2E 测试。该 charter 内容同步维护在根目录 sigs.yaml 的- dir: sig-storage条目中二者互为印证。二、2024 年度 GA 里程碑四个特性进入正式稳定年度报告首先列出四个在 2024 年达成GAGeneral Availability的 KEP标志着它们已默认启用、API 稳定并承诺向后兼容。1. KEP 3756Robust VolumeManager Reconstructionv1.30 GAKEP 3756 改善了 Kubelet 处理已挂载卷的方式——具体而言是在Kubelet 重启后对卷进行更健壮的重建reconstruction。从实现位置看卷的挂载/卸载状态机运行在 Kubelet 的卷管理器volume manager中这在 SIG Storage README 中也有明确指引pkg/kubelet/volumemanager属于 SIG Storage 拥有的代码路径。传统上Kubelet 重启后需要从磁盘上的挂载点信息反推出卷状态若重建失败可能导致卷被错误地视为已卸载或发生重复挂载。该特性使重建过程更快、更健壮从而让节点重启后的存储恢复更可靠尤其对运行有状态工作负载的节点意义重大。2. KEP 3141Prevent Unauthorized Volume Mode Conversionv1.30 GAKEP 3141 防止在从 Volume Snapshot 创建 Persistent Volume Claim时发生未经授权的卷模式volume mode转换。在 Kubernetes 中卷模式分为Filesystem与Block两种。当用户基于一个快照创建 PVC 时如果快照源卷的模式与新声明的模式不一致例如将块设备卷的快照声明为文件系统卷就存在数据损坏或语义错配的风险。该特性在 GA 后禁止这种未经授权的转换从数据安全角度补齐了快照工作流的一个漏洞。3. KEP 3762PersistentVolume 最近一次阶段迁移时间v1.31 GAKEP 3762 为PersistentVolumeStatus增加了一个字段记录 PersistentVolume最近一次发生 phase阶段迁移的时间戳。例如你可以精确测量一个 PV 从Pending迁移到Bound花费了多长时间。这带来的直接价值是可用于度量与 SLO卷供给耗时是存储服务质量的直观指标便于监控与排障结合事件时间线快速定位 PV 生命周期中的异常停滞点。4. KEP 1847StatefulSet 创建的 PVC 自动删除v1.32 GA与 SIG-Apps 共管KEP 1847 允许StatefulSet 创建的 PVC 在卷不再被使用时被自动删除以减轻对不会永久存活的 StatefulSet 的管理负担。该特性与 SIG-Apps 共同拥有co-owned是年度报告中少见的跨 SIG 协作成果。传统上 StatefulSet 删除后其 PVC 会保留这是有状态应用数据持久化的设计初衷但对于临时性或可重建的有状态工作负载这会造成资源泄漏与清理负担。该特性引入策略化自动清理机制让用户按需选择 PVC 生命周期策略。三、Beta 进展三个迈向稳定的重要特性除了 GA2024 年还有三个 KEP 推进到Beta阶段功能已默认可用或可显式开启等待进一步打磨后进入 GA。1. KEP 3751VolumeAttributesClass ModifyVolumev1.31 BetaKEP 3751 将 Kubernetes Persistent Volume API 扩展为允许用户在卷供给之后动态修改卷选项例如 IOPS 与吞吐量。这意味着过去需要删除-重建或依赖厂商特定流程才能完成的性能调整现在可以基于VolumeAttributesClass声明式地完成。年度报告同时给出一个谨慎的提示该 enhancement 在当前状态下被标记为有代码冻结风险at risk for code freeze说明即使进入 Beta其推进节奏仍受版本窗口影响读者在评估生产使用时需关注其最终落地状态。2. KEP 1790Recover from Volume Expansion Failurev1.32 BetaKEP 1790 允许用户在卷扩容失败后通过重试一个更小的尺寸来恢复。在文件系统或存储后端扩容中途失败时卷可能处于不一致状态此前用户几乎没有自救手段。该特性提供了一条恢复路径——用较小尺寸重试将卷恢复到可用状态避免因扩容失败导致数据不可用。3. KEP 3476Volume Group Snapshotv1.32 BetaKEP 3476 引入了VolumeGroupSnapshot API用于同时对多个卷拍摄快照并保证这些快照的一致性例如同一时间点的应用一致性快照组。这是对既有 VolumeSnapshot单卷快照的重要扩展。对于需要跨多个卷保持一致备份的应用如数据库多数据卷场景这是关键能力也印证了 SIG Storage 在快照方向从单卷向多卷组演进的路径。四、2024 年 KEP 全景Alpha / Beta / Stable 完整清单年度报告还给出了 2024 年对应 v1.30、v1.31、v1.32 三个版本KEP 工作的完整分类清单。下面按阶段整理供读者对照检索。Alpha 阶段KEP主题关键进展1710Speed up recursive SELinux label changeSELinuxMount在 v1.30 进入 AlphaSELinuxChangePolicy在 v1.32 进入 AlphaKEP 1710 围绕 SELinux 标签递归修改的性能优化展开其中SELinuxMount让挂载时即可获得正确的 SELinux 上下文避免容器启动时全量递归 relabelSELinuxChangePolicy则允许用户选择更灵活的标签变更策略。Beta 阶段KEP主题进入 Beta 版本1790Recover from volume expansion failurev1.322644Honor Persistent Volume Reclaim Policyv1.313476Volume Group Snapshotv1.323751VolumeAttributesClass ModifyVolumev1.312589Portworx in-tree 到 CSI 驱动迁移v1.31 默认开启on-by-default其中 KEP 2589 属于in-tree 插件向 CSI 迁移的大方向。仓库中的 volume-plugin-faq.md 详细解释了这一背景SIG Storage 已不再接受新的 in-tree 卷插件原因是 in-tree 插件与 Kubernetes 发布强耦合、难以独立测试与维护、插件 bug 可能拖垮核心组件、并迫使插件源码公开因此目标是逐步为大多数既有 in-tree 插件提供 CSI 兼容实现并完成迁移。Portworx 迁移在 v1.31 默认开启正是这一长期战略在 2024 年的落地案例。Stable 阶段KEP主题GA 版本3141Prevent unauthorised volume mode conversionv1.303756Robust VolumeManager reconstruction after kubelet restartv1.303762PersistentVolume last phase transition timev1.311847Auto remove PVCs created by StatefulSetv1.32与 SIG-Apps 共管五、生态与组织变化新子项目、工作组与持续迭代年度报告同时披露了 2024 年 SIG Storage 在生态组织层面的变化这些条目在 sigs.yaml 的- dir: sig-storage段中均有对应记录。子项目Subprojects变化2024 年新增external-snapshot-metadata——围绕 CSI 快照元数据snapshot metadata service的外部组件负责向用户与工具提供快照内文件系统元数据检索能力服务于精细化备份与恢复场景持续维护中external-storage、git-sync、gluster-provisioner、kubernetes-cosi容器对象存储接口、kubernetes-csi、mount-utils、nfs-provisioner、volume-populators、volumes。从 sigs.yaml 与 SIG Storage README 看kubernetes-csi子项目名下托管着大量 CSI 生态组件external-provisioner、external-attacher、external-resizer、external-snapshotter、external-health-monitor、livenessprobe、node-driver-registrar、csi-test、csi-release-tools、csi-driver-host-path 等它们是 CSI 在 Kubernetes 中落地的基础设施volume-populators则支撑 AnyVolumeDataSource / 数据填充population工作流。这解释了年度报告中增强 CSI 发布工具这一诉求为何被反复提及——CSI sidecar 生态的发布工程是 SIG 的核心运营负担之一。工作组Working Groups变化2024 年新增Servingwg-serving/持续进行中Data Protectionwg-data-protection/、Policyarchive/wg-policy/、Structured Loggingarchive/wg-structured-logging/。其中 WG Data Protection 关注备份/恢复/容灾方向的应用保护与数据保护工作流其白皮书见 wg-data-protection/data-protection-workflows-white-paper.md与 SIG Storage 的快照、克隆能力直接衔接WG Policy 则以 SIG Storage 为利益相关方之一负责梳理 Kubernetes 策略相关实现的整体架构。需要帮助的领域年度报告也坦率列出了 SIG 需要外部帮助的方向对想参与贡献的开发者是明确的切入点测试与发布工程编写更多测试、监控 test grid 健康度、推进测试框架 out-of-tree 化、增强 CSI 发布工具文档需要文档写作者改善 CSI 侧及存储整体文档Issue 治理SIG 有每周 issue triage 会议但需要更高效的 issue 分类与修复协助。结合 CONTRIBUTING.md 的指引参与路径包括从 contributors/guide 起步、带着特性提案参加 Storage SIG 会议提案合并后再写实现能显著加快评审、认领存储相关 issue、或按 volume-plugin-faq.md 的指导为新的存储平台开发 CSI 驱动。六、运营与治理年度自检清单年度报告最后列出了 2024 年的运营任务自检结果全部勾选完成这些是 committee-steering/governance/sig-governance.md 规定的 SIG 年度义务sig-storage/README.md 经审阅并在必要时更新sig-storage/CONTRIBUTING.md 经审阅并在必要时更新其他贡献类文档如 devel 目录或贡献者指南经审阅并在必要时更新sigs.yaml 中的子项目列表及其关联 OWNERS 文件经审阅并在必要时更新sigs.yaml 中的 SIG 领导chairs、tech leads、subproject leads信息准确且活跃并更新了必要内容2024 年会议纪要与录屏已从 sig-storage/README.md 链接并可访问。从 sigs.yaml 的当前条目看SIG Storage 的领导架构为ChairsHemant KumarRed Hat与 Xing YangVMwareTech LeadsJan ŠafránekRed Hat与 Michelle AuGoogleEmeritus Leads 包括 Bradley Childs 与 Saad Ali。SIG 拥有 7 个 GitHub 团队api-reviews、bugs、feature-requests、misc、pr-reviews、proposals、test-failures并维持三类例会每周一次的 CSI 实现会议、每周一次的 issue triage 会议、每两周一次的常规 SIG 会议详情见 sig-storage/README.md 的 Meetings 章节。若想参与可通过仓库内的 governance 文档了解角色与流程并在相应 Slack 频道#sig-storage或邮件列表中加入讨论。七、总结2024 年 SIG Storage 的演进主线综合年度报告与仓库内文档可以提炼出 2024 年 SIG Storage 的三条演进主线稳定性与可观测性Robust VolumeManager Reconstruction3756与 PV 阶段迁移时间3762分别从恢复健壮性与生命周期可观测两个维度夯实了卷管理底座数据安全与一致性Prevent Unauthorized Volume Mode Conversion3141堵住快照恢复路径的漏洞Volume Group Snapshot3476将一致性快照能力从单卷扩展到卷组运维弹性与声明式管理StatefulSet PVC 自动删除1847、VolumeAttributesClass ModifyVolume3751、扩容失败恢复1790共同指向减少人工干预、让存储资源随声明式策略自管理。对于 Kubernetes 用户建议按如下方式消化这些成果先确认所在集群版本对应的特性门控与 API 状态Beta/GA 差异影响默认启用行为再结合 sig-storage/charter.md 与 sig-storage/README.md 定位相关代码与会议资料最后通过 sig-storage/CONTRIBUTING.md 与 sig-storage/volume-plugin-faq.md 找到参与或二次开发的入口。SIG Storage 的 2024 年是存量稳定化与能力横向扩展并进的一年——前者让存储更可靠后者让存储更灵活。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考