Rook v1.3：章鱼、OSD 增强功能等！

tnielsen

我们很高兴地宣布，Rook v1.3 为 Kubernetes 的 Ceph 运算符带来了一系列重要的功能和改进。

主要主题

  • 章鱼支持
  • 池压缩
  • OSD 配置
  • 旧版 OSD 移除
  • Ceph-CSI v2.0
  • 卸载时清理集群
  • 控制器运行时转换
  • 为 RGW 多站点设计

章鱼支持

随着 Ceph 的每个发布版本，我们努力支持新的功能、升级和其他配置更改。作为管理平面，Rook 自动化配置，因此您不必过多担心。随着 Ceph Octopus 的最新发布，受支持的 Ceph 版本现在包括

  • Nautilus v14.2.5 或更高版本
  • Octopus v15.2.0 或更高版本

与往常一样，Rook 将管理到这些版本的部署和升级。只需按照 升级指南，即可在准备好升级集群中运行的 Ceph 版本时进行升级。通常，它就像更改 CephCluster CR 一样简单。例如，要升级到 Octopus

spec: cephVersion: image: ceph/ceph:v15.2.0

已移除对 Mimic 的支持。使用 Mimic 的旧集群需要升级到 Nautilus 才能更新到 Rook v1.3。

池压缩

Ceph 中池数据压缩的选项已在 Ceph 中可用一段时间。现在，该选项作为 CephBlockPool CR 上的选项提供。可以通过将 compressionMode 属性设置为池来指示压缩级别。

spec: compressionMode

该模式可以是 Ceph 压缩主题 中看到的四种选项之一

  • none：永不压缩数据
  • passive：除非写入操作设置了 compressible 提示，否则不压缩数据
  • aggressive：除非写入操作设置了 incompressible 提示，否则压缩数据
  • force：无论如何尝试压缩数据

OSD 配置

在此版本中，核心 Ceph 存储守护程序 (OSD) 有许多改进。

  • PVC 上的 OSD：添加了支持，为 BlueStore 元数据 (DB/WAL) 创建单独的卷
  • 如果底层块大小发生更改（例如，EBS 卷已调整大小），则 PVC 上的 OSD 可以增大容量，下次重新启动 OSD 部署时，BlueStore 引擎将扩展，这将在整个集群容量中反映出来。
  • 移除了许多场景下对 LVM 的依赖。当在 PVC 上运行 OSD 时，采用共置场景（单个设备用于 OSD）时，将使用原始模式，并且不会配置 LVM 层。
  • 可以在 PVC 上运行 OSD 时指定 CRUSH 设备类。这在 Ceph 无法正确检测 OSD 正在运行的磁盘的环境中特别有用。例如，某些 Amazon 卷类型反映为 NVMe 作为传输层。但是，这只是总线实现，而不是您正在使用的实际 NVMe。Ceph 可能会感到困惑并调整自身以反映错误的类型。不幸的是，这种调整是不希望的。如果管理员事先知道正确的类型，则可以在卷 ClaimTemplates 元数据部分应用注释，并且 OSD 类将填充正确的价值。
  • 完整路径：可以通过完整路径而不是设备名称指定设备

旧版 OSD 移除

虽然我们尽一切努力避免破坏性更改，但我们不再能够维护两种类型的旧版 OSD 的支持。

  • 不能再指定目录来创建 OSD。只能使用原始设备或分区来创建 OSD。基于 Ceph FileStore 的目录不再建议用于新 OSD 的生产环境。
  • 使用 Rook 的分区方案创建的旧于 Rook v0.9 的 OSD 不再受支持。仅支持自 v0.9 以来使用 ceph-volume 创建的 OSD。

有关更多详细信息，请参阅 Rook 的 升级指南，了解在升级到 v1.3 之前迁移 OSD 的方法。

Ceph-CSI v2.0

Ceph-CSI v2.0 驱动程序已使用 v2.0 版本 中的许多改进进行更新。现在，这是 Rook-Ceph 运算符支持的 CSI 驱动程序的最低版本。其中一些关键功能，例如支持卷调整大小。

在 Rook v1.3 版本中，安装的 CSI 驱动程序的默认版本是 v2.1。当新的 CSI 驱动程序版本发布时，您可以通过修改 CSI 版本设置，在它成为 Rook 默认版本之前配置 Rook 运行较新的版本。

Multus 支持（实验性）

Rook 具有使用 Multus 的必要更改，以便可以在特定容器内公开专用网络。在将 Ceph 集群部署到三个网络时，通常并不罕见

  1. 监控网络：在传统的 SDN 上，在 API 网络上
  2. 公共网络：用于客户端与集群的通信，专用 NIC 和子网
  3. 集群网络：用于集群组件之间的内部通信，也称为复制网络，专用 NIC 和子网

借助 Multus，可以实现上述目标，Rook 将读取提供的网络附件定义。Rook 还允许您通过在 CR 的网络部分下添加以下内容来分离公共网络和集群网络

network: provider: multus selectors: publiccluster

如果只有一个网络可用，则可以将其用于公共网络和集群网络，并且只能指定“public”。

由于测试有限，并且考虑到 Multus 的复杂性，此功能在本版本中被声明为实验性的。请报告您可能有的任何反馈，以便我们声明此功能为稳定版！

控制器运行时转换

Rook 有几个 CRD（自定义资源定义），例如 CephCluster、CephBlockPool、CephFilesystem 和 CephObjectStore。实现这些 CRD 的控制器现在使用 Kubernetes controller-runtime 项目 构建，该项目代表了一组用于构建控制器的 Go 库。该项目由 Kubebuilder 和 Operator SDK 利用，并且是编写 CRD 控制器最常用的库。其中一些好处

  • 遵循行业标准和常用模式
  • 增强了期望状态的稳健性。通过监视资源，每个控制器将在资源发生更改时（例如，如果资源被意外删除，控制器将在几秒钟内重新创建它）进行调解 Kubernetes 对象。
  • 事件上的更快调解
  • 每个控制器都有自己的调解循环，该循环位于主 CephCluster 循环之外。因此，每个 CRD 都被视为更加独立，并且将快速响应更改。

卸载时清理

当 Rook 被卸载时，最大的痛点之一是在主机上清理数据。由于 Rook 希望确保您的数据不会被意外删除，我们一直不愿创建自动卸载。现在，我们已经确定了一种设计，我们希望这是一种安全的妥协。

要启用卸载期间的主机清理，请执行以下过程

首先，在卸载之前，请在 CephCluster CR 中设置清理策略

spec: cleanupPolicy: deleteDataDirOnHosts: yes-really-destroy-data

现在，当您删除 CephCluster CR 时，运算符将启动一个 Kubernetes Job，以清理每个运行 Ceph 守护程序的主机上的数据。

我们即将实施的第二个方面是擦除 OSD 使用的原始设备上的数据。目前，只有主机上的 mon 数据会被清理。

通过 ConfigMap 进行运算符设置

Ceph 运算符的设置长期以来仅通过环境变量应用于运算符部署。如果需要更新设置，则需要重新启动运算符。现在，许多设置已转换为 ConfigMap，运算符将监视更改。如果更新了设置，运算符将自动应用新设置，无需重新启动。特别是，如果需要，可以应用较新版本的 CSI 驱动程序。

为 RGW 多站点设计

除了在单个 Kubernetes 集群中配置 Ceph 之外，Rook 旨在简化跨多个 Ceph 集群复制数据。支持 RGW 多站点一直是计划中的，我们已经完成了 此功能的设计。在 Rook v1.4 版本中，我们期待第一个发布此功能的版本。如果您在下一个版本发布此功能之前对设计有任何反馈，我们很乐意听取您的意见。

结论

非常感谢 Ceph 团队和许多其他社区成员在此版本中的所有改进。让我们庆祝这一成就，并期待持续改进的未来！

联合作者：Sébastien Han