
Kubernetes SIG Storage 2022 年度报告解读CSI 迁移全面 GA、五大存储特性落地与社区演进【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本篇文章基于 Kubernetes 社区仓库中 SIG Storage 2022 年度报告 的完整内容展开系统梳理该 SIG 在 v1.24v1.26 三个版本周期内取得的 GA 里程碑、KEP 工作全景、CSI 迁移进展以及社区治理与健康指标。读者读完可以掌握 2022 年 Kubernetes 存储领域的关键特性卷扩容、本地临时存储隔离、内联 CSI 卷、存储容量调度、fsgroup 透传等各自对应的 KEP 编号与落地版本理解 CSI 迁移从核心到各大云厂商插件的演进节奏并获得参与 SIG Storage 贡献的完整入口与行动清单。一、SIG Storage 的职责边界与 2022 年工作背景在深入年度报告之前有必要明确 SIG Storage 的使命。根据 SIG Storage Charter 与 README 的定义SIG Storage 负责确保不同类型的文件与块存储无论是临时还是持久、本地还是远端在容器被调度的任何位置都可用具体覆盖卷的 provisioning/创建、attach、mount、unmount、detach 与删除存储容量管理容器临时存储用量、卷扩容等基于存储影响容器调度数据引力、可用性等以及快照等通用存储操作。这一职责边界决定了 2022 年度报告的主体内容KEPKubernetes Enhancement Proposal驱动特性落地与CSIContainer Storage Interface生态推进。报告覆盖 v1.24、v1.25、v1.26 三个版本周期体现了 SIG 以设计 → alpha → beta → GA节奏在例会中持续跟踪每个特性进展的治理方式。二、2022 年度五大 GA 里程碑详解年度报告首先列出的核心成就是五个 KEP 在本年度达到 GAGeneral Availability它们共同覆盖了从调度前容量感知到挂载时权限透传的完整存储链路。1. 存储容量约束与 Pod 调度KEP-1472v1.24 GAKEP-1472 为 CSI 卷提供了基于节点存储容量的调度约束能力。在它之前kube-scheduler 无法感知各节点上 CSI 卷的剩余容量导致动态供给的卷可能被调度到容量不足的节点。该特性引入CSINode上的容量信息与调度打分机制让数据引力data gravity和存储可用性真正进入调度决策。此特性在 2021 年度报告见 annual-report-2021.md中即被列为 stable 目标2022 年随 v1.24 正式发布。2. 卷扩容 GAKEP-284v1.24 GAKEP-284 让持久卷PV可以在线扩容。此前卷一旦供给完成其大小便被锁定该特性打通了PersistentVolumeClaim扩容请求到 CSIControllerExpandVolume的完整链路允许用户在StorageClass中设置allowVolumeExpansion: true后动态扩大卷尺寸。它与 CSI 的 external-resizer 侧车组件配合实现属于 SIG Storage 子项目 kubernetes-csi 的核心能力之一。3. 本地临时存储容量隔离 GAKEP-361v1.25 GAKEP-361 解决了容器临时存储emptyDir、日志、容器可写层的容量隔离与驱逐问题。此前本地临时存储的使用不受限制单个 Pod 可能耗尽节点磁盘。该特性为每个 Pod 设置了临时存储限额结合 kubelet 的驱逐机制实现容量隔离是生产集群稳定性建设的关键一环。4. 内联 CSI 临时卷 GAKEP-596v1.25 GAKEP-596 允许在 Pod 的 volume 定义中直接内联引用 CSI 卷而非必须通过 PV/PVC 间接引用适用于卷的生命周期与 Pod 生命周期一致的临时场景。它丰富了临时卷ephemeral volume的供给方式与已有的 emptyDir 形成互补特别适合需要 CSI 驱动提供缓存或临时数据盘的场景。5. 挂载时将 Pod fsgroup 提供给 CSI 驱动KEP-2317v1.26 GAKEP-2317 在挂载阶段把 Pod 的fsGroup信息传递给 CSI 驱动。此前 CSI 驱动无法在NodeStageVolume/NodePublishVolume阶段感知 Pod 指定的组 ID导致驱动侧无法正确设置卷权限。该特性通过扩展 CSI 请求字段对应 KEP-3107 的SecretRef机制演进让驱动能在挂载时完成正确的所有权设置改善了多用户共享存储场景的权限正确性。三、2022 年 KEP 工作全景v1.24 / v1.25 / v1.26年度报告给出了完整的 KEP 进展清单以下按成熟度阶段整理供读者按版本检索。Alpha 阶段新特性引入KEP 编号特性目标版本1432Volume Health Monitor卷健康监控v1.241979Object Storage Support对象存储支持COSIv1.252644Honor Persistent Volume Reclaim Policy尊重 PV 回收策略v1.262924In-tree 插件到 CSI 迁移 —— Ceph CephFSv1.263107NodeExpandVolume 请求新增 SecretRef 字段v1.253294跨命名空间快照供给卷v1.26Beta 阶段功能稳定化KEP 编号特性目标版本2268非优雅停机Non-graceful shutdownv1.262589In-tree 插件到 CSI 迁移 —— Portworxv1.252923In-tree 插件到 CSI 迁移 —— Ceph RBDv1.263333追溯性默认 StorageClass 分配Retroactive default StorageClassv1.26Stable 阶段正式 GAKEP 编号特性目标版本1472Storage Capacity Constraints for Pod Schedulingv1.241487In-tree 到 CSI 迁移 —— AWSv1.251488In-tree 到 CSI 迁移 —— GCE PDv1.251489In-tree 到 CSI 迁移 —— Cinderv1.241490In-tree 到 CSI 迁移 —— Azure Diskv1.241491In-tree 到 CSI 迁移 —— vSpherev1.261885In-tree 到 CSI 迁移 —— Azure Filev1.262317挂载时向 CSI 驱动提供 Pod fsgroupv1.26284Growing Persistent Volume size卷扩容v1.24361Local Ephemeral Storage Capacity Isolationv1.25596Ephemeral Inline CSI Volumesv1.25625In-tree Storage Plugin to CSI Migration核心迁移框架v1.25从列表可以清晰看到2022 年是 CSI 迁移的丰收年——核心迁移框架KEP-625与 AWS、GCE PD、Cinder、Azure Disk、Azure File、vSphere 等主流云厂商插件先后达到 GA这与 volume-plugin-faq.md 中SIG Storage 的长期目标是让绝大多数 in-tree 插件都拥有对应的 CSI 兼容实现并完成迁移的目标完全一致。四、CSI 迁移从 in-tree 到 out-of-tree 的主线工程年度报告将CSI Migration 取得巨大进展列为非 KEP 维度的核心亮点称核心 CSI 迁移以及 AWS、GCE PD、OpenStack Cinder、Azure Disk、Azure File、vSphere 的插件迁移在 2022 年全部达到 GA。理解这一成就需要回到卷插件架构演进的背景。volume-plugin-faq.md 明确指出Kubernetes 卷插件有三种实现方式In-tree 卷插件已弃用与 Kubernetes 核心二进制一起编译、链接、发布扩展核心 API要求把代码合入核心仓库Out-of-tree FlexVolume 驱动已弃用基于 exec 的插件接口驱动二进制必须安装在宿主机上Out-of-tree CSI 驱动推荐标准化的容器存储接口自 Kubernetes 1.13 起 GA。SIG Storage 不再接受新的 in-tree 插件原因是多方面的in-tree 插件与 Kubernetes 发布节奏强耦合、社区需要为所有插件负责测试与维护、插件 bug 可能击穿核心组件如 kubelet、kube-controller-manager、插件获得与核心组件同等的特权、且要求插件源码公开。CSI 则通过标准化接口与 sidecar 架构external-provisioner、external-attacher、external-resizer、external-snapshotter、livenessprobe、node-driver-registrar 等完整清单见 README 的 kubernetes-csi 子项目节解耦了这些问题。因此2022 年多个云厂商插件的迁移 GA 意味着这些存储系统可以彻底移除对 in-tree 插件的依赖用户只需部署对应的 CSI 驱动即可获得同等甚至更强的能力拓扑感知、快照、扩容等 FlexVolume 时代无法提供的能力。这一主线在后续年度报告中持续延伸——Portworx2023 beta、2025 GA、Ceph RBD/CephFS2023 beta等相继推进印证了年度报告所描述路线的长期性。五、非 KEP 驱动的社区运营举措年度报告专门回答了有哪些未通过 KEP 跟踪的举措其中最重要的是一项治理创新SIG Storage 启动了 Issue Triage 看板与每周 Issue 分诊会议。这一机制建立了从issue 上报到分诊 → 指派 → 修复的闭环配套看板与会议议程记录在 README 的会议一节 中有对应说明每周三 10:00 PT 的 Regular SIG Issue Triage Meeting。在后续 2023、2024、2025 年度报告中需要更高效的 issue triage 帮助始终位列求助清单可见该机制是 SIG 长期运营的抓手。从治理流程看这与 sig-governance.md 规定的 SIG 运营检查项相互呼应年度报告需要在每个周期核对 README、CONTRIBUTING、sigs.yaml 中的子项目与负责人信息、会议记录链接是否准确。六、项目健康与贡献机会清单年度报告用专门篇幅说明了社区最需要帮助的领域对有意参与的开发者是直接的招贤榜代码修复与评审SIG 在修复 bug 与代码评审层面普遍缺人号召贡献者先研读 CONTRIBUTING 指南再参加 SIG Storage 会议 找到感兴趣的项目Issue 分诊每周的 issue triage 会议欢迎更多人加入提高分诊效率CSI 一致性测试为 CSI 驱动编写 conformance tests测试体系编写更多测试、监控 test grid 健康度、推进 out-of-tree 测试框架、增强 CSI release tools文档写作改善 CSI 侧与 Storage 侧的文档质量。其中 CONTRIBUTING.md 是新贡献者的核心入口它汇集了从 2016 年到 2023 年的一系列演讲、文档与视频如 Kubernetes Storage 101、Storage Classes Dynamic Provisioning、PV/PVC Controller Deep Dive 等并给出了明确的参与路径特性提案先提 PR 并放入 SIG 会议议程讨论、在达成共识前不要急于写实现、实现 PR 必须包含功能测试、e2e 测试与文档。从源码治理角度SIG 的成员层级遵循通用的 社区成员阶梯即 Member → Reviewer → Approver → 维护者存储相关 issue 通过 GitHub 上sig/storage标签聚合多个 GitHub Teamsig-storage-api-reviews、sig-storage-bugs、sig-storage-feature-requests、sig-storage-pr-reviews、sig-storage-test-failures 等按职责分流详见 sigs.yaml 中 SIG Storage 的 contact 定义。七、社区健康指标与成员规模年度报告记录了截至 2023 年 3 月 10 日的 devstats 社区健康数据这些指标是 SIG 判断协作效率的依据PR 从提交到合并的时效7 天移动平均sig-storage 仓库组指标最大值平均值中位数open 到 LGTM小时3.05 周1.37 天中位数LGTM 到 approve小时8.25 小时0.18 小时中位数approve 到 merge小时3.29 天0.74 小时85 分位open 到 LGTM小时13.49 周1.13 周85 分位LGTM 到 approve小时3.09 周10.03 小时85 分位approve 到 merge小时2.65 周1.26 小时从数据可以推断LGTM 到 approve、approve 到 merge 的中位数普遍很短小时级说明评审与合入环节运转顺畅耗时大头集中在open 到 LGTM即从 PR 提交到获得首个 LGTM 的等待期这正是 SIG 呼吁更多 reviewer 参与的原因。Issue 处理时效7 天移动平均截至 2023/3/10指标最小值最大值平均值中位数关闭 issue 耗时0.25 小时30.65 周3.61 周平均新增 issue 数0.143.140.88成员规模2022 年度主要 Slack 频道成员数sig-storage5373 人、csi1399 人主要邮件列表成员数749 人主要会议参会人数估算25 人SIG 自有包的唯一 reviewer36 人SIG 自有包的唯一 approver30 人。与 2021 年度报告sig-storage 4767 人、csi 1126 人、邮件列表 702 人对比2022 年各渠道成员数均有增长反映了 CSI 迁移 GA 带来的生态热度。此外年度报告确认 SIG 有来自多家公司/机构的贡献者且有少量来自最终用户公司的贡献者参与新特性开发。八、子项目与工作组布局持续运营的子项目年度报告列出了 2022 年持续运营的 9 个子项目均可在 README 的 Subprojects 一节 与 sigs.yaml 中找到完整的所有者OWNERS信息external-storage外部供给器生态如 sig-storage-lib-external-provisioner、local-static-provisionergit-syncgit 同步工具gluster-provisionerGlusterFS 外部供给器kubernetes-cosi容器对象存储接口Container Object Storage Interface对应 KEP-1979 对象存储支持的落地载体kubernetes-csiCSI 核心生态含 host-path 示例驱动、external-provisioner/attacher/resizer/snapshotter、livenessprobe、node-driver-registrar、csi-test、csi-release-tools、csi-translation-lib 等数十个仓库mount-utilsKubernetes 核心仓库 staging 出的挂载工具库nfs-provisionerNFS 供给器volume-populators卷数据填充器lib-volume-populator、volume-data-source-validatorvolumesKubernetes 核心仓库的 pkg/volume 卷插件代码。协同工作组SIG Storage 2022 年与四个工作组保持协同Data Protection数据保护其 KEP 相关工作在项目跟踪表中登记并在 SIG Storage 会议中讨论Multitenancy多租户无固定沟通机制Policy策略无固定沟通机制Structured Logging结构化日志通过结构化日志的 PR 提交与评审协作。其中 Data Protection 工作组在 wg-data-protection 目录 有独立的年度报告与白皮书文档可供延伸阅读。九、年度运营检查与社区更新年度报告的 Operational 部分确认了 SIG 在 2022 年完成的全部治理检查项全部勾选 [x]审核并更新 README.md审核并更新 CONTRIBUTING.md审核 sigs.yaml 中的子项目列表与关联 OWNERS 文件核对 sigs.yaml 中 SIG 领导chairs、tech leads、子项目 owners的准确性与活跃度在 README.md 中链接 2022 年会议记录与录像完成社区级分享KubeCon Europe 2022 与 KubeCon NA 2022 的 SIG Storage Deep Dive 演讲。这些检查项遵循 sig-governance.md 的年度运营要求也是社区仓库中所有 SIG 年度报告的通用模板结构。读者在 annual-report-2021.md、annual-report-2023.md、annual-report-2024.md、annual-report-2025.md 中可以看到这一结构的逐年演进。十、结语从年度报告看 Kubernetes 存储的演进脉络与参与路径SIG Storage 2022 年度报告的核心叙事可以概括为三条线能力落地线卷扩容KEP-284、本地临时存储隔离KEP-361、内联 CSI 卷KEP-596、存储容量调度KEP-1472、fsgroup 透传KEP-2317五大 GA加上对象存储KEP-1979、跨命名空间快照KEP-3294等 alpha 探索持续拓展存储能力边界架构迁移线CSI 迁移核心框架KEP-625及 AWS、GCE PD、Cinder、Azure Disk、Azure File、vSphere 六类插件 GA标志着 Kubernetes 存储正式走向一切皆 CSI的 out-of-tree 时代该路线在后续年度持续兑现社区治理线Issue Triage 看板与每周分诊会议落地配合 devstats 健康指标跟踪构建了可度量的社区运营体系。对于想参与其中的读者最直接的行动路径是先通过 CONTRIBUTING.md 建立 Kubernetes 存储概念基础从修复 bug 与 issue 分诊入手看板与每周会议见 README 会议节熟悉代码后参与代码评审最终沿着 社区成员阶梯 成长为 reviewer 与 approver。仓库本身是只读的所有探索、学习与提案讨论均可围绕上述文档与会议机制展开。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考