企业官网建设流程全解析

Kubernetes SIG Storage 2024 年度报告解读：GA 里程碑、CSI 生态与存储演进全景

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community

SIG Storage（Storage 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 Interface（CSI），以及与 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 年达成GA（General Availability）的 KEP，标志着它们已默认启用、API 稳定并承诺向后兼容。

1. KEP 3756：Robust VolumeManager Reconstruction（v1.30 GA）

KEP 3756 改善了 Kubelet 处理已挂载卷的方式——具体而言，是在Kubelet 重启后对卷进行更健壮的"重建"（reconstruction）。

从实现位置看，卷的挂载/卸载状态机运行在 Kubelet 的卷管理器（volume manager）中，这在 SIG Storage README 中也有明确指引：pkg/kubelet/volumemanager属于 SIG Storage 拥有的代码路径。传统上，Kubelet 重启后需要从磁盘上的挂载点信息反推出卷状态，若重建失败可能导致卷被错误地视为已卸载或发生重复挂载。该特性使重建过程更快、更健壮，从而让节点重启后的存储恢复更可靠，尤其对运行有状态工作负载的节点意义重大。

2. KEP 3141：Prevent Unauthorized Volume Mode Conversion（v1.30 GA）

KEP 3141 防止在从 Volume Snapshot 创建 Persistent Volume Claim时发生未经授权的卷模式（volume mode）转换。

在 Kubernetes 中，卷模式分为Filesystem与Block两种。当用户基于一个快照创建 PVC 时，如果快照源卷的模式与新声明的模式不一致（例如将块设备卷的快照声明为文件系统卷），就存在数据损坏或语义错配的风险。该特性在 GA 后禁止这种未经授权的转换，从数据安全角度补齐了快照工作流的一个漏洞。

3. KEP 3762：PersistentVolume 最近一次阶段迁移时间（v1.31 GA）

KEP 3762 为PersistentVolumeStatus增加了一个字段，记录 PersistentVolume最近一次发生 phase（阶段）迁移的时间戳。

例如，你可以精确测量一个 PV 从Pending迁移到Bound花费了多长时间。这带来的直接价值是：

• 可用于度量与 SLO：卷供给耗时是存储服务质量的直观指标；
• 便于监控与排障：结合事件时间线快速定位 PV 生命周期中的异常停滞点。

4. KEP 1847：StatefulSet 创建的 PVC 自动删除（v1.32 GA，与 SIG-Apps 共管）

KEP 1847 允许StatefulSet 创建的 PVC 在卷不再被使用时被自动删除，以减轻对"不会永久存活"的 StatefulSet 的管理负担。

该特性与 SIG-Apps 共同拥有（co-owned），是年度报告中少见的跨 SIG 协作成果。传统上 StatefulSet 删除后其 PVC 会保留（这是有状态应用数据持久化的设计初衷），但对于临时性或可重建的有状态工作负载，这会造成资源泄漏与清理负担。该特性引入策略化自动清理机制，让用户按需选择 PVC 生命周期策略。

三、Beta 进展：三个迈向稳定的重要特性

除了 GA，2024 年还有三个 KEP 推进到Beta阶段，功能已默认可用或可显式开启，等待进一步打磨后进入 GA。

1. KEP 3751：VolumeAttributesClass ModifyVolume（v1.31 Beta）

KEP 3751 将 Kubernetes Persistent Volume API 扩展为允许用户在卷供给之后动态修改卷选项，例如 IOPS 与吞吐量。

这意味着，过去需要"删除-重建"或依赖厂商特定流程才能完成的性能调整，现在可以基于VolumeAttributesClass声明式地完成。年度报告同时给出一个谨慎的提示：该 enhancement 在当前状态下被标记为有代码冻结风险（at risk for code freeze），说明即使进入 Beta，其推进节奏仍受版本窗口影响，读者在评估生产使用时需关注其最终落地状态。

2. KEP 1790：Recover from Volume Expansion Failure（v1.32 Beta）

KEP 1790 允许用户在卷扩容失败后，通过重试一个更小的尺寸来恢复。

在文件系统或存储后端扩容中途失败时，卷可能处于不一致状态，此前用户几乎没有自救手段。该特性提供了一条恢复路径——用较小尺寸重试，将卷恢复到可用状态，避免因扩容失败导致数据不可用。

3. KEP 3476：Volume Group Snapshot（v1.32 Beta）

KEP 3476 引入了VolumeGroupSnapshot API，用于同时对多个卷拍摄快照，并保证这些快照的一致性（例如同一时间点的应用一致性快照组）。

这是对既有 VolumeSnapshot（单卷快照）的重要扩展。对于需要跨多个卷保持一致备份的应用（如数据库多数据卷场景），这是关键能力，也印证了 SIG Storage 在快照方向从单卷向多卷组演进的路径。

四、2024 年 KEP 全景：Alpha / Beta / Stable 完整清单

年度报告还给出了 2024 年（对应 v1.30、v1.31、v1.32 三个版本）KEP 工作的完整分类清单。下面按阶段整理，供读者对照检索。

Alpha 阶段

KEP 1710 围绕 SELinux 标签递归修改的性能优化展开，其中SELinuxMount让挂载时即可获得正确的 SELinux 上下文，避免容器启动时全量递归 relabel；SELinuxChangePolicy则允许用户选择更灵活的标签变更策略。

Beta 阶段

其中 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 阶段

五、生态与组织变化：新子项目、工作组与持续迭代

年度报告同时披露了 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 年新增：Serving（wg-serving/）；
• 持续进行中：Data Protection（wg-data-protection/）、Policy（archive/wg-policy/）、Structured Logging（archive/wg-structured-logging/）。

其中 WG Data Protection 关注备份/恢复/容灾方向的应用保护与数据保护工作流（其白皮书见 wg-data-protection/data-protection-workflows-white-paper.md），与 SIG Storage 的快照、克隆能力直接衔接；WG Policy 则以 SIG Storage 为利益相关方之一，负责梳理 Kubernetes 策略相关实现的整体架构。

需要帮助的领域

年度报告也坦率列出了 SIG 需要外部帮助的方向，对想参与贡献的开发者是明确的切入点：

1. 测试与发布工程：编写更多测试、监控 test grid 健康度、推进测试框架 out-of-tree 化、增强 CSI 发布工具；
2. 文档：需要文档写作者改善 CSI 侧及存储整体文档；
3. 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 Kumar（Red Hat）与 Xing Yang（VMware）；Tech LeadsJan Šafránek（Red Hat）与 Michelle Au（Google）；Emeritus 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 的三条演进主线：

1. 稳定性与可观测性：Robust VolumeManager Reconstruction（3756）与 PV 阶段迁移时间（3762）分别从"恢复健壮性"与"生命周期可观测"两个维度夯实了卷管理底座；
2. 数据安全与一致性：Prevent Unauthorized Volume Mode Conversion（3141）堵住快照恢复路径的漏洞，Volume Group Snapshot（3476）将一致性快照能力从单卷扩展到卷组；
3. 运维弹性与声明式管理：StatefulSet PVC 自动删除（1847）、VolumeAttributesClass ModifyVolume（3751）、扩容失败恢复（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