尧图网站建设 
云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载Rook 的 ROADMAP.md 是该项目的顶层发展规划文档它定义了未来版本的优先级与主题。本文围绕其中最新规划的Rook Ceph 1.21预计 2026 年 9 月发布以及 Kubectl 插件方向展开逐一解读每个规划条目背后的技术动因并结合当前仓库中的源码、CRD 定义与示例清单进行佐证帮助你理解 Rook 即将落地的能力边界以及如何在规划落地前预判集群演进方向。Roadmap 的定位乐观规划与社区驱动阅读 Roadmap 前需要先理解它的性质。文档开篇明确说明每个里程碑中包含的功能与主题是乐观的optimistic——部分条目还没有明确的所有者owner社区与贡献者的参与是让每个版本全部愿望清单落地成真的关键。因此Roadmap 中的日期和具体发布内容随时可能变化只用于传达整体方向。对于最实时的 issue 状态需跟踪 Rook 官方的 GitHub project boards本文仅以当前仓库内已存在的代码与文档为事实依据解读这些规划条目的现状与潜在实现路径。Rook Ceph 1.21高优先级功能清单v1.21 规划覆盖了 Ceph 内核版本升级、CSI 驱动、对象存储、OSD 生命周期管理、网络协议、NVMe-oF 与 Dashboard 安全等多个维度以下逐项展开。支持 Ceph Umbrella v21Rook v1.21 的第一个规划条目是支持 Ceph Umbrella v21。Ceph 的版本号体系一直在演进从字母代号如 Squid、T 系列到以Umbrella命名的新一代版本Rook 的每个版本都会跟随一个主流的 Ceph 大版本进行兼容与验证包括镜像构建、CRD 校验、配置项适配与端到端测试。从仓库结构看Rook 对 Ceph 版本的适配是体系化的镜像构建逻辑位于 images/ceph/Dockerfile 与 images/ceph/Makefile版本探测与校验逻辑位于 pkg/operator/ceph/version 目录而 Ceph 命令封装在 pkg/daemon/ceph/client。因此Umbrella v21 的支持意味着这些链路要针对新版本做完整回归验证。CSI 驱动cgroup v2 QoS 与 Ceph-CSI v3.18 集成CSI 方向有两个规划条目1. RBD 卷的 cgroup v2 QoS 支持相关 PR #17887该特性为 RBD 卷引入基于 cgroup v2 的 I/O 服务质量QoS控制。当前仓库中已经存在对应的功能清单可直接用于规划落地后的实践验证deploy/examples/csi/rbd/volumeattributesclass-cgroup.yaml。该清单通过 Kubernetes 的VolumeAttributesClass机制需 Kubernetes ≥ v1.34 且该特性已 GA为 RBD 卷设置 QoS底层由 Linux 内核的 cgroup v2io.max接口强制执行其前置条件包括节点 Linux 内核 ≥ 5.8节点已启用 cgroup v2使用默认的 krbd内核 RBDmounter。apiVersion: storage.k8s.io/v1 kind: VolumeAttributesClass metadata: name: rook-ceph-rbd-cgroup-qos driverName: rook-ceph.rbd.csi.ceph.com # csi-provisioner-name parameters: # Maximum read IOPS limit enforced via cgroup v2 io.max maxReadIops: 1000 # Maximum write IOPS limit enforced via cgroup v2 io.max maxWriteIops: 2000 # Maximum read bandwidth in bytes per second (104857600 100 MiB/s) maxReadBps: 104857600 # Maximum write bandwidth in bytes per second (209715200 200 MiB/s) maxWriteBps: 209715200四个参数分别对应读 IOPS、写 IOPS、读带宽字节/秒、写带宽字节/秒上限全部通过 cgroup v2io.max施加在挂载 RBD 卷的 Pod 侧。这与 Rook 既有的 RBD QoS 文档见 Documentation/Storage-Configuration/Block-Storage-RBD/rbd-qos.md形成互补后者面向 Ceph 服务端限流而 cgroup v2 方案在客户端内核侧执行尤其适合需要按 Pod 粒度隔离 I/O 的场景。2. 集成 Ceph-CSI v3.18Rook 与 Ceph-CSI 的版本绑定是规划中的重要环节。Ceph-CSI 驱动负责实际的卷管理操作RBD/CephFS 的创建、挂载、快照、克隆等Rook 通过ROOK_CSI_*环境变量与csi-ceph-conf-override等机制控制驱动的部署形态相关示例见 deploy/examples/csi-ceph-conf-override.yaml。升级到 Ceph-CSI v3.18 意味着 RBD QoS、快照、克隆等能力随上游驱动同步获得增强与缺陷修复。对象存储RGW 账户 capabilities 的运行时更新PR #17940对象存储Object Store方向的规划是增加更新 RGW 账户 capabilities 的选项。RGW 账户Account是 Rook 中用于多站点/账户管理的对象存储抽象对应的 CRD 为CephObjectAccount。从源码看Rook 对对象用户CephObjectUser的 capabilities 管理已经有完整的实现可作为该规划落地后行为的有力参照。在 pkg/operator/ceph/object/user/controller.go 中控制器会对比当前存活用户与目标用户的 capabilities先移除不再需要的 capabilitiesremove capabilities %s from user %s若没有需要移除的 capsCeph API 会返回 missing user capabilities 错误需要妥善处理再设置目标 capabilitiesset capabilities %s for user %s。capabilities 的映射关系定义在同文件userConfig构造逻辑中pkg/operator/ceph/object/user/controller.go涵盖users、buckets、metadata、usage、zone、roles、amz-cache、bilog、info等 Ceph 权限类别。这条路线条目正是将对象用户上已成熟的能力扩展到对象账户Account维度使账户级别的权限也能在 CRD 声明变更后由 Rook 自动同步到 RGW。OSD单 OSD 替换与 seastore 支持OSD 方向有两个规划条目1. 配置 metadataDevice 且多 OSD 场景下的单 OSD 替换issue #13240metadataDevice是 Rook 集群存储配置中的一个重要字段用于为 OSD 指定专用的元数据设备通常是一块高性能 NVMe SSD。当前仓库中 pkg/apis/ceph.rook.io/v1/spec_test.go 展示了该字段的 CRD 用法storage: nodes: - name: node1 metadataDevice: nvme01当一个metadataDevice上承载了多个 OSD例如多个数据盘共享一块元数据盘时某个 OSD 故障后的替换流程会变得复杂——因为元数据盘是共享的不能简单地整盘替换。该规划条目旨在让 Rook 的 OSD 替换流程相关设计见 design/ceph/osd-replacement.md能够精确到单个 OSD粒度而不影响共享同一元数据盘的其他 OSD。2. raw 模式下使用 Ceph seastore 创建 OSDissue #16678seastore 是 Ceph 新一代的对象存储后端对标 BlueStore 的演进方向。当前仓库的 OSD 存储类型枚举pkg/apis/ceph.rook.io/v1/storage.go仍只有bluestore与bluestore-rdr两种且GetOSDStoreFlag()默认回退到--bluestore——这说明 seastore 目前在 Rook 中尚未具备正式配置入口属于规划中的能力。从实现路径推断该特性落地后storage.store.type很可能扩展出seastore值并在 raw 模式非 PVC 模式下由 OSD 编排逻辑透传给ceph-osd的--seastore启动参数。在此之前OSD 后端仍以 BlueStore 系列为唯一正式选项。网络协议默认禁用 msgr1issue #17081Ceph 的消息协议经历了从 msgr1默认端口 6789到 msgr2默认端口 3300的演进。msgr2 提供加密、压缩等更现代的传输能力。Rook v1.21 规划默认禁用 msgr1 协议仅使用 msgr2以简化网络配置并提升安全基线。当前仓库已经为 msgr2 提供了完整的配置支撑CRD 层面ClusterSpec.Network.Connections.RequireMsgr2字段见 pkg/apis/ceph.rook.io/v1/types.go注释明确说明即使未启用压缩或加密也要求 msgr2端口 3300需要内核支持 msgr2内核 5.11 或 CentOS 8.4 及以上Monitor 编排层面pkg/operator/ceph/cluster/mon/spec.go 定义了DefaultMsgr2Port/DefaultMsgr2PortName的端口与命名并根据端口类型构造不同的绑定地址IPv4/IPv6 格式差异浮动 Monitorfloating mon场景下ROOK_MSGR2环境变量由floatingMonMsgr2Value()pkg/operator/ceph/cluster/mon/spec.go生成格式为msgr2_required_encryption_bool_compression_bool将 msgr2 要求与加密、压缩开关一并传递给启动逻辑。可以推断默认禁用 msgr1落地后RequireMsgr2的默认行为将反转由可选变为强制Monitor、OSD、MDS、RGW 等所有 Ceph 守护进程将只监听 msgr2 端口。NVMe-oF宣布 GAissue #18053NVMe-oFNVMe over Fabrics是 Rook 提供高性能块存储接入的重要方式通过 Ceph 的 NVMe-oF 网关将 RBD 池暴露为 NVMe 子系统。v1.21 规划将其宣布为 GA正式可用。仓库中该功能的支撑已经相当完整CRD 定义CephNVMeOFGateway及其 Spec 定义位于 pkg/apis/ceph.rook.io/v1/types.go支持自定义镜像默认参考quay.io/ceph/nvmeof、nvmeof.conf配置通过ConfigMapRef或NVMeOFConfig键值对注入、端口配置IO 端口默认 4420等示例清单deploy/examples/nvmeof.yaml、deploy/examples/nvmeof-test.yaml文档Documentation/Storage-Configuration/Block-Storage-RBD/nvme-of.md控制器实现位于 pkg/operator/ceph/nvmeof其中 connectionconfig.sh 通过ceph nvme-gw create创建网关。从 GA 的角度看该声明意味着 Rook 团队对 NVMe-oF 网关的稳定性、升级路径与运维体验已建立信心用户可以将其纳入生产负载的块存储方案评估范围。Ceph Dashboard可配置 TLS 证书issue #17984该规划条目允许用户为 Ceph Dashboard 配置 TLS 证书而不是只能使用 Rook 自生成的自签名证书。当前仓库已经具备这一能力的基础实现。CRD 层面DashboardSpec提供了两个关键字段pkg/apis/ceph.rook.io/v1/types.gossl是否启用 SSLsslCertificateRef引用CephCluster命名空间下类型为kubernetes.io/tls的 Secret。如果设置了该字段Rook 将使用此证书配置 Dashboard而非生成自签名证书。对应的控制器实现位于 pkg/operator/ceph/cluster/mgr/dashboard.go它通过 mon 配置存储设置mgr/dashboard/ssl、mgr/dashboard/ssl_server_port等配置dashboard.go并在设置sslCertificateRef时校验证书/密钥的tls.X509KeyPair合法性validateDashboardTLSKey随后将 Secret 中的证书写入mgr/dashboard/crt与mgr/dashboard/key。若后续移除该引用Rook 会恢复为自签名证书dashboard.go。用户落地方式在 CephCluster 的dashboard段配置ssl: true与sslCertificateRef: secret-name并将合规的 TLS 证书以kubernetes.io/tls类型 Secret 预先创建在集群命名空间中。Kubectl 插件CSI 驱动排障能力规划Roadmap 的最后一部分涉及 Rook 官方的 kubectl-rook-ceph 插件无承诺时间线。规划条目是收集用于排查 CSI 驱动的详细信息。这意味着插件未来可能增加子命令一键汇总 CSI 驱动的部署状态、Pod 日志、配置映射、节点注册信息等排障上下文降低 CSI 相关问题的定位成本。插件在 Rook 生态中的定位与用法可参考 Documentation/Troubleshooting/kubectl-plugin.md该文档讲解了插件的安装与常用排查命令。总结如何跟进 v1.21 规划Roadmap 是理解 Rook 发展方向的第一手材料但正如文档开篇所言其中的时间与内容都可能调整。建议的跟进方式以官方 project board 为准v1.21 的详细项目追踪在官方的 v1.21 board 上issue/PR 状态是最新事实来源关注仓库演进本文引用的 ROADMAP.md、CRD 定义pkg/apis/ceph.rook.io/v1、控制器实现如 pkg/operator/ceph/object/user/controller.go、pkg/operator/ceph/cluster/mgr/dashboard.go会随版本迭代持续变化届时可对照本文的解读校验每个条目的落地形态提前验证依赖如 cgroup v2 QoS 需要 Kubernetes ≥ v1.34 与内核 ≥ 5.8、msgr2 需要内核 5.11这些前置条件应纳入集群升级规划。一句话概括 v1.21 的主题围绕 Ceph Umbrella v21 完成全链路适配将 CSI QoS、msgr2-only、NVMe-oF、Dashboard TLS 等能力推向生产就绪。赞分享云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载相关推荐Rook Ceph NVMe-oF 网关指南用 NVMe/TCP 将 RBD 卷暴露到 Kubernetes 集群外Rook Ceph NVMe oF 网关指南用 NVMe/TCP 将 RBD 卷暴露到 Kubernetes 集群外 Rook 通过 CephNVMeOFGa云原生存储容器编排运维Rook Ceph 集群配置实战从 PG/PGP 规划到 ceph.conf 高级覆盖Rook Ceph 集群配置实战从 PG/PGP 规划到 ceph.conf 高级覆盖 导读 本文基于 Rook 官方文档 Documentation/Sto云原生存储容器编排运维Rook Ceph NVMe-oF 块存储实战指南通过 NVMe/TCP 对外提供 RBD 卷Rook Ceph NVMe oF 块存储实战指南通过 NVMe/TCP 对外提供 RBD 卷 NVMe oFNVMe over Fabrics允许 Ro云原生存储容器编排运维创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Rook Ceph 1.21 路线图解读：从 Umbrella v21 到生产级 NVMe-oF 的规划全景
云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载Rook 的 ROADMAP.md 是该项目的顶层发展规划文档它定义了未来版本的优先级与主题。本文围绕其中最新规划的Rook Ceph 1.21预计 2026 年 9 月发布以及 Kubectl 插件方向展开逐一解读每个规划条目背后的技术动因并结合当前仓库中的源码、CRD 定义与示例清单进行佐证帮助你理解 Rook 即将落地的能力边界以及如何在规划落地前预判集群演进方向。Roadmap 的定位乐观规划与社区驱动阅读 Roadmap 前需要先理解它的性质。文档开篇明确说明每个里程碑中包含的功能与主题是乐观的optimistic——部分条目还没有明确的所有者owner社区与贡献者的参与是让每个版本全部愿望清单落地成真的关键。因此Roadmap 中的日期和具体发布内容随时可能变化只用于传达整体方向。对于最实时的 issue 状态需跟踪 Rook 官方的 GitHub project boards本文仅以当前仓库内已存在的代码与文档为事实依据解读这些规划条目的现状与潜在实现路径。Rook Ceph 1.21高优先级功能清单v1.21 规划覆盖了 Ceph 内核版本升级、CSI 驱动、对象存储、OSD 生命周期管理、网络协议、NVMe-oF 与 Dashboard 安全等多个维度以下逐项展开。支持 Ceph Umbrella v21Rook v1.21 的第一个规划条目是支持 Ceph Umbrella v21。Ceph 的版本号体系一直在演进从字母代号如 Squid、T 系列到以Umbrella命名的新一代版本Rook 的每个版本都会跟随一个主流的 Ceph 大版本进行兼容与验证包括镜像构建、CRD 校验、配置项适配与端到端测试。从仓库结构看Rook 对 Ceph 版本的适配是体系化的镜像构建逻辑位于 images/ceph/Dockerfile 与 images/ceph/Makefile版本探测与校验逻辑位于 pkg/operator/ceph/version 目录而 Ceph 命令封装在 pkg/daemon/ceph/client。因此Umbrella v21 的支持意味着这些链路要针对新版本做完整回归验证。CSI 驱动cgroup v2 QoS 与 Ceph-CSI v3.18 集成CSI 方向有两个规划条目1. RBD 卷的 cgroup v2 QoS 支持相关 PR #17887该特性为 RBD 卷引入基于 cgroup v2 的 I/O 服务质量QoS控制。当前仓库中已经存在对应的功能清单可直接用于规划落地后的实践验证deploy/examples/csi/rbd/volumeattributesclass-cgroup.yaml。该清单通过 Kubernetes 的VolumeAttributesClass机制需 Kubernetes ≥ v1.34 且该特性已 GA为 RBD 卷设置 QoS底层由 Linux 内核的 cgroup v2io.max接口强制执行其前置条件包括节点 Linux 内核 ≥ 5.8节点已启用 cgroup v2使用默认的 krbd内核 RBDmounter。apiVersion: storage.k8s.io/v1 kind: VolumeAttributesClass metadata: name: rook-ceph-rbd-cgroup-qos driverName: rook-ceph.rbd.csi.ceph.com # csi-provisioner-name parameters: # Maximum read IOPS limit enforced via cgroup v2 io.max maxReadIops: 1000 # Maximum write IOPS limit enforced via cgroup v2 io.max maxWriteIops: 2000 # Maximum read bandwidth in bytes per second (104857600 100 MiB/s) maxReadBps: 104857600 # Maximum write bandwidth in bytes per second (209715200 200 MiB/s) maxWriteBps: 209715200四个参数分别对应读 IOPS、写 IOPS、读带宽字节/秒、写带宽字节/秒上限全部通过 cgroup v2io.max施加在挂载 RBD 卷的 Pod 侧。这与 Rook 既有的 RBD QoS 文档见 Documentation/Storage-Configuration/Block-Storage-RBD/rbd-qos.md形成互补后者面向 Ceph 服务端限流而 cgroup v2 方案在客户端内核侧执行尤其适合需要按 Pod 粒度隔离 I/O 的场景。2. 集成 Ceph-CSI v3.18Rook 与 Ceph-CSI 的版本绑定是规划中的重要环节。Ceph-CSI 驱动负责实际的卷管理操作RBD/CephFS 的创建、挂载、快照、克隆等Rook 通过ROOK_CSI_*环境变量与csi-ceph-conf-override等机制控制驱动的部署形态相关示例见 deploy/examples/csi-ceph-conf-override.yaml。升级到 Ceph-CSI v3.18 意味着 RBD QoS、快照、克隆等能力随上游驱动同步获得增强与缺陷修复。对象存储RGW 账户 capabilities 的运行时更新PR #17940对象存储Object Store方向的规划是增加更新 RGW 账户 capabilities 的选项。RGW 账户Account是 Rook 中用于多站点/账户管理的对象存储抽象对应的 CRD 为CephObjectAccount。从源码看Rook 对对象用户CephObjectUser的 capabilities 管理已经有完整的实现可作为该规划落地后行为的有力参照。在 pkg/operator/ceph/object/user/controller.go 中控制器会对比当前存活用户与目标用户的 capabilities先移除不再需要的 capabilitiesremove capabilities %s from user %s若没有需要移除的 capsCeph API 会返回 missing user capabilities 错误需要妥善处理再设置目标 capabilitiesset capabilities %s for user %s。capabilities 的映射关系定义在同文件userConfig构造逻辑中pkg/operator/ceph/object/user/controller.go涵盖users、buckets、metadata、usage、zone、roles、amz-cache、bilog、info等 Ceph 权限类别。这条路线条目正是将对象用户上已成熟的能力扩展到对象账户Account维度使账户级别的权限也能在 CRD 声明变更后由 Rook 自动同步到 RGW。OSD单 OSD 替换与 seastore 支持OSD 方向有两个规划条目1. 配置 metadataDevice 且多 OSD 场景下的单 OSD 替换issue #13240metadataDevice是 Rook 集群存储配置中的一个重要字段用于为 OSD 指定专用的元数据设备通常是一块高性能 NVMe SSD。当前仓库中 pkg/apis/ceph.rook.io/v1/spec_test.go 展示了该字段的 CRD 用法storage: nodes: - name: node1 metadataDevice: nvme01当一个metadataDevice上承载了多个 OSD例如多个数据盘共享一块元数据盘时某个 OSD 故障后的替换流程会变得复杂——因为元数据盘是共享的不能简单地整盘替换。该规划条目旨在让 Rook 的 OSD 替换流程相关设计见 design/ceph/osd-replacement.md能够精确到单个 OSD粒度而不影响共享同一元数据盘的其他 OSD。2. raw 模式下使用 Ceph seastore 创建 OSDissue #16678seastore 是 Ceph 新一代的对象存储后端对标 BlueStore 的演进方向。当前仓库的 OSD 存储类型枚举pkg/apis/ceph.rook.io/v1/storage.go仍只有bluestore与bluestore-rdr两种且GetOSDStoreFlag()默认回退到--bluestore——这说明 seastore 目前在 Rook 中尚未具备正式配置入口属于规划中的能力。从实现路径推断该特性落地后storage.store.type很可能扩展出seastore值并在 raw 模式非 PVC 模式下由 OSD 编排逻辑透传给ceph-osd的--seastore启动参数。在此之前OSD 后端仍以 BlueStore 系列为唯一正式选项。网络协议默认禁用 msgr1issue #17081Ceph 的消息协议经历了从 msgr1默认端口 6789到 msgr2默认端口 3300的演进。msgr2 提供加密、压缩等更现代的传输能力。Rook v1.21 规划默认禁用 msgr1 协议仅使用 msgr2以简化网络配置并提升安全基线。当前仓库已经为 msgr2 提供了完整的配置支撑CRD 层面ClusterSpec.Network.Connections.RequireMsgr2字段见 pkg/apis/ceph.rook.io/v1/types.go注释明确说明即使未启用压缩或加密也要求 msgr2端口 3300需要内核支持 msgr2内核 5.11 或 CentOS 8.4 及以上Monitor 编排层面pkg/operator/ceph/cluster/mon/spec.go 定义了DefaultMsgr2Port/DefaultMsgr2PortName的端口与命名并根据端口类型构造不同的绑定地址IPv4/IPv6 格式差异浮动 Monitorfloating mon场景下ROOK_MSGR2环境变量由floatingMonMsgr2Value()pkg/operator/ceph/cluster/mon/spec.go生成格式为msgr2_required_encryption_bool_compression_bool将 msgr2 要求与加密、压缩开关一并传递给启动逻辑。可以推断默认禁用 msgr1落地后RequireMsgr2的默认行为将反转由可选变为强制Monitor、OSD、MDS、RGW 等所有 Ceph 守护进程将只监听 msgr2 端口。NVMe-oF宣布 GAissue #18053NVMe-oFNVMe over Fabrics是 Rook 提供高性能块存储接入的重要方式通过 Ceph 的 NVMe-oF 网关将 RBD 池暴露为 NVMe 子系统。v1.21 规划将其宣布为 GA正式可用。仓库中该功能的支撑已经相当完整CRD 定义CephNVMeOFGateway及其 Spec 定义位于 pkg/apis/ceph.rook.io/v1/types.go支持自定义镜像默认参考quay.io/ceph/nvmeof、nvmeof.conf配置通过ConfigMapRef或NVMeOFConfig键值对注入、端口配置IO 端口默认 4420等示例清单deploy/examples/nvmeof.yaml、deploy/examples/nvmeof-test.yaml文档Documentation/Storage-Configuration/Block-Storage-RBD/nvme-of.md控制器实现位于 pkg/operator/ceph/nvmeof其中 connectionconfig.sh 通过ceph nvme-gw create创建网关。从 GA 的角度看该声明意味着 Rook 团队对 NVMe-oF 网关的稳定性、升级路径与运维体验已建立信心用户可以将其纳入生产负载的块存储方案评估范围。Ceph Dashboard可配置 TLS 证书issue #17984该规划条目允许用户为 Ceph Dashboard 配置 TLS 证书而不是只能使用 Rook 自生成的自签名证书。当前仓库已经具备这一能力的基础实现。CRD 层面DashboardSpec提供了两个关键字段pkg/apis/ceph.rook.io/v1/types.gossl是否启用 SSLsslCertificateRef引用CephCluster命名空间下类型为kubernetes.io/tls的 Secret。如果设置了该字段Rook 将使用此证书配置 Dashboard而非生成自签名证书。对应的控制器实现位于 pkg/operator/ceph/cluster/mgr/dashboard.go它通过 mon 配置存储设置mgr/dashboard/ssl、mgr/dashboard/ssl_server_port等配置dashboard.go并在设置sslCertificateRef时校验证书/密钥的tls.X509KeyPair合法性validateDashboardTLSKey随后将 Secret 中的证书写入mgr/dashboard/crt与mgr/dashboard/key。若后续移除该引用Rook 会恢复为自签名证书dashboard.go。用户落地方式在 CephCluster 的dashboard段配置ssl: true与sslCertificateRef: secret-name并将合规的 TLS 证书以kubernetes.io/tls类型 Secret 预先创建在集群命名空间中。Kubectl 插件CSI 驱动排障能力规划Roadmap 的最后一部分涉及 Rook 官方的 kubectl-rook-ceph 插件无承诺时间线。规划条目是收集用于排查 CSI 驱动的详细信息。这意味着插件未来可能增加子命令一键汇总 CSI 驱动的部署状态、Pod 日志、配置映射、节点注册信息等排障上下文降低 CSI 相关问题的定位成本。插件在 Rook 生态中的定位与用法可参考 Documentation/Troubleshooting/kubectl-plugin.md该文档讲解了插件的安装与常用排查命令。总结如何跟进 v1.21 规划Roadmap 是理解 Rook 发展方向的第一手材料但正如文档开篇所言其中的时间与内容都可能调整。建议的跟进方式以官方 project board 为准v1.21 的详细项目追踪在官方的 v1.21 board 上issue/PR 状态是最新事实来源关注仓库演进本文引用的 ROADMAP.md、CRD 定义pkg/apis/ceph.rook.io/v1、控制器实现如 pkg/operator/ceph/object/user/controller.go、pkg/operator/ceph/cluster/mgr/dashboard.go会随版本迭代持续变化届时可对照本文的解读校验每个条目的落地形态提前验证依赖如 cgroup v2 QoS 需要 Kubernetes ≥ v1.34 与内核 ≥ 5.8、msgr2 需要内核 5.11这些前置条件应纳入集群升级规划。一句话概括 v1.21 的主题围绕 Ceph Umbrella v21 完成全链路适配将 CSI QoS、msgr2-only、NVMe-oF、Dashboard TLS 等能力推向生产就绪。赞分享云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载相关推荐Rook Ceph NVMe-oF 网关指南用 NVMe/TCP 将 RBD 卷暴露到 Kubernetes 集群外Rook Ceph NVMe oF 网关指南用 NVMe/TCP 将 RBD 卷暴露到 Kubernetes 集群外 Rook 通过 CephNVMeOFGa云原生存储容器编排运维Rook Ceph 集群配置实战从 PG/PGP 规划到 ceph.conf 高级覆盖Rook Ceph 集群配置实战从 PG/PGP 规划到 ceph.conf 高级覆盖 导读 本文基于 Rook 官方文档 Documentation/Sto云原生存储容器编排运维Rook Ceph NVMe-oF 块存储实战指南通过 NVMe/TCP 对外提供 RBD 卷Rook Ceph NVMe oF 块存储实战指南通过 NVMe/TCP 对外提供 RBD 卷 NVMe oFNVMe over Fabrics允许 Ro云原生存储容器编排运维创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考