Rook v1.1：Ceph CSI、Bucket Provisioning、外部集群以及更多！
我们很高兴地宣布 Kubernetes Ceph 运算符在 Rook v1.1 中推出了一系列重要的功能和改进。
主要主题 ¶
- CSI 驱动程序已准备好投入生产
- 对象存储的动态 Bucket Provisioning
- 连接到外部 Ceph 集群
- 在动态底层存储之上配置 Mons 和 OSDs
- 从集群 CR 启用 Ceph manager 模块
- 升级和维护改进
- OSD 配置改进
- Placement 改进
CSI 驱动程序 ¶
CSI 驱动程序 已经准备就绪！现在您可以充分利用 Ceph-CSI 驱动程序的动态 Provisioning，包括
- RBD（RWO 访问）的动态 Provisioning
- CephFS（RWX 访问）的动态 Provisioning
Rook 现在默认情况下为新集群和升级后的集群启用 CSI 驱动程序。我们鼓励您创建一个指向 CSI Provisioner 的新的 StorageClass，并基于 CSI 创建所有新的 Volume。
RBD Volume 的 Snapshot 也可用。CSI 接口定义的 Snapshot API 仍处于 Alpha 状态，因此您需要启用一个 Feature Gate 来测试此功能。
有关 CSI 功能及其状态的完整列表，请参阅 Ceph-CSI Github 仓库。
CSI 驱动程序与 Flex 驱动程序
FlexVolume 驱动程序正在让位于 CSI 驱动程序。所有未来的开发都集中在 CSI 驱动程序上。虽然 flex 驱动程序仍然完全受支持，但我们邀请您立即开始过渡。
升级到 v1.0 后，flex 驱动程序将继续运行以确保您的 Volume 持续运行。在未来的某个时候，FlexVolume 驱动程序将被弃用，我们将确保您的 Volume 有一个平滑的过渡路径。
您仍然需要使用 flex 驱动程序的一个原因是，如果您正在运行 K8s 1.12 或更早版本。CSI 接口直到 K8s 1.13 才被声明为稳定，因此，我们无法在旧版本的 Kubernetes 上支持 CSI 驱动程序。
如果您仍在使用的 flex 驱动程序，此版本中可以利用的一个新功能是 Volume 调整大小的功能。是的，您没听错！现在您可以调整 Volume 大小了。
Bucket Provisioning ¶
您是否想知道为什么对象存储不可用作为 PVC？对象存储一直由 Kubernetes 以不同的方式处理。现在我们解决了这个挑战，并将这种动态 Provisioning 的模式带到了 Ceph 对象存储中的 Bucket。
当管理员希望在其集群中公开对象存储时，他们首先定义一个指向配置了 RGW 的 Ceph 集群的 StorageClass。然后，用户可以在请求对象 Bucket 时 Provision Bucket。这遵循了 Kubernetes 用于 PVC 的标准模式，但现在也适用于对象存储了！
要开始使用，请参阅 Ceph 示例 页面上的“对象存储 Bucket”部分。
外部 Ceph 集群 ¶
您是否已经运行了一个 Ceph 集群，并希望您的 K8s 应用程序使用该存储？现在可以使用 Rook！当启用此模式时，Rook 不会管理外部集群，它只会使用它。为了连接，您只需要三条信息
- 外部集群 Ceph FSID
- 外部集群 Monitor IP 地址
- 外部 cluster-admin 密钥
创建带有此连接信息的 CephCluster 后，Rook 将立即连接到该集群。此功能假定已在外部 Ceph 集群和本地 Kubernetes 环境之间建立网络连接。为了实现这一点，使用 Host Networking 可以使连接变得简单。其他选项也是可能的，例如将您的外部集群置于与您的服务池 IP 相同的子网中，或自定义您的 IP 路由。
还有一点！Rook 仍然可以为您 Bootstrap 其他 CRD，例如 Object、Filesystem 和 NFS。在这种情况下，这些资源将在 Kubernetes 中运行和由 Rook 管理，即使持久性全部在外部 Ceph 集群中。集群中的客户端甚至不会意识到存储正在运行在其他地方。通过 CSI 驱动程序、RGW 端点或其他服务的连接信息都将如同存储在本地集群中一样可用。
立即尝试一下，按照 设置与外部集群的连接 教程，并告诉我们您的使用体验！
动态底层存储 ¶
Ceph Monitors 和 OSDs 需要一个地方来持久化您的数据。Monitors 需要访问一个目录来存储他们的数据库。直到现在，Rook 只能通过将主机上的目录绑定挂载到容器中来实现这一点。现在，如果 Rook 运行在云提供商上，我们可以利用 Kubernetes 持久存储支持来附加一个带有文件系统的 Persistent Volume Claim (PVC)。然后 Ceph monitor 存储将位于 PV 上，就像其他标准的 K8s 存储一样。
Ceph 对象存储守护程序 (OSDs) 需要原始块设备。它们使用 PVC 附加存储的实现方式与 Monitors 类似。区别在于 PVC 必须作为原始块设备呈现，而不是文件系统。
此新功能为在云提供商或甚至在您的本地集群中使用本地存储 Provisioner 中运行 Ceph 提供了更多的灵活性。要查看其用法并尝试一下，请查看文档中的 基于 PVC 的示例。mons 指定一个指向 StorageClass 的 volumeClaimTemplate，而 OSDs 指定一个 storageClassDeviceSet，其中包含要 Provision 的设备数量以及用于 Provision 它们的模板（和 StorageClass）。
从集群 CR 启用 Ceph manager 模块 ¶
Ceph Manager 具有一个可插拔接口，允许您为特定用例编写自定义模块。Rook 现在能够启用任何已知的 Ceph 模块。这可以通过 CephCluster 配置中的帮助来实现
mgr
modules
- name: pg_autoscaler
enabled: true
在此示例中，我们正在启用 PG autoscaler 模块。有关完整模块列表，请参阅 Ceph 官方文档。
升级和维护改进 ¶
升级方面进行了一些改进。首先，在 Rook 升级 Rook 或 Ceph 版本期间，Rook 将等待每个守护程序健康后再升级下一个守护程序。这使得整体 Ceph 升级更安全，并且更符合 Ceph 核心团队的建议。
下一个改进领域是在您需要服务或升级 K8s 集群时。我们已经为所有 Ceph 守护程序实施了 Pod Disruption Budgets，这些 Budgets 将在为维护排空节点时使用。在这种情况下，根据在选定的机器上运行的守护程序类型，Rook 将设置 Pod Disruption Budget 以考虑每个 Ceph 守护程序的可用性需求。
相关地，OpenShift 集群有机器中断预算。这适用于 machine-api 控制器，machine-api 控制器可能会对不健康的节点发送 fencing 请求。在这种情况下，机器中断预算强制一次只能 fencing 一个 Ceph 节点。一旦该机器被 fencing，Rook 将等待 Ceph PGs 稳定，然后解锁机器中断预算以允许 fencing 其他节点。
要启用这些功能以处理升级，请参阅集群 CR 文档中的 disruptionManagement 属性。
OSD 配置改进 ¶
对 OSD 的配置方式进行了一些改进，并公开了 ceph-volume 的更多功能。其中包括
- 可以根据单个设备指定元数据设备，而不仅仅是每个节点
- 可以在 CR 中指定每个设备的 deviceClass 属性，以指示要在 CRUSH 地图中配置的存储类
- 可以显式指定元数据设备，而不依赖于系统猜测要使用哪个设备（需要 Nautilus 14.2.1 或更高版本）
Placement 改进 ¶
对 K8s 集群的拓扑与 Ceph 拓扑更好地集成进行了一些改进。特别是，Rook 将查找 K8s 节点上的 zone 和 region 标签。如果找到它们
- Mons 将自动跨不同的 zone 传播
- OSDs 将 zone 添加到 CRUSH 层次结构中，以改善故障域传播。请参阅集群 CR 中的 topologyAware 设置。
在底层，另一个 Placement 改进是新的实现，用于将 mons 放置在集群中的节点上。以前 Rook 实现了自己的调度程序来决定基于集群 CR 中指定的期望节点亲和性和容忍度将 mons 放置在哪些节点上。现在我们删除了所有自定义调度代码，并使用 Kubernetes 调度程序为我们放置 mons。如果您在集群中看到 mon “canary” Pod，它们唯一的目的就是这样。在片刻之后，它们将被安排在相同节点上的 mon 守护程序 Pod 替换。更少的代码意味着更好的调度！
结论 ¶
非常感谢 Ceph 团队和许多其他社区成员在此版本中的所有改进。这绝对是 Rook 版本中交付的最好的 Ceph 功能集。让我们庆祝这一成就，并期待未来持续改进的光明前景！