我们正在为我们的 Web 服务设计一个新的集群架构，并计划使用 Ceph 对象存储和 kubernetes 来为我们的服务提供服务。为了优化我们的服务器，我们有不同的选择：
使用相同的服务器并在所有服务器上运行 Ceph 和我们的服务，并使用 kubernetes 进行管理
像上面一样使用相同的服务器，但将其中一些标记为 Ceph，并且不在其上运行服务
使用两种类型的服务器：一种针对 io 进行了优化，一种针对 cpu 进行了优化。然后在 io 服务器上运行 Ceph，在 cpu 服务器上运行服务。并使用 kubernetes 管理所有这些服务器
像上面一样拥有两个独立的服务器，但不要将 kubernetes 用于 io 服务器，而是让 ceph 处理所有事情（对于我们的 Ceph 集群不使用 kubernetes 不是更简单吗？）
我知道相同的服务器具有更好的扩展性。另一方面，拥有两种类型的服务器让我们可以优化它们。最好的解决方案是什么？
答案1
需要考虑的一些事项：
如果您使用的是旋转磁盘，那么您可能希望为 Ceph 和随机 Kubernetes 任务使用单独的磁盘。这样，来自 kubernetes 任务的随机 I/O 就不会破坏 Ceph 访问的顺序（尤其是写入和大量读取）。显然，您可以使用 (2)、(3) 或 (4) 来实现这一点。但是，如果您的服务器 (JBOD) 中有多个磁盘，并且将每个磁盘分配给 Ceph 或 Kubernetes（但不能同时分配给两者），您也可以使用选项 (1) 来实现这一点（或者如果您为 Kubernetes 使用单独的启动闪存驱动器等）。
如果您的 CPU 优化服务器恰好配备了大型启动盘，您最终可能会觉得存储被搁置了，因为服务作业不会全部使用它，并且后来希望您也可以在这些节点上运行 Ceph，以解除该存储的搁置。但如果它是一个小磁盘/固态硬盘，那么您可能不在乎。
您需要多少台服务器存在一些不确定性。（例如增长、故障、不精确的负载估计）。由于这种不确定性，您必须超额购买。2 个 SKU 比 1 个 SKU 的超额购买更糟糕。而且，随着需求的变化，以后重新利用服务器会更加困难。这有点有利于 (1) 或 (2)。
从安全角度来看，如果服务作业与存储不在同一台机器上，您可能会更放心。如果您有各种不同的服务作业，并且这些作业的信任程度不同，那么这一点就更为重要。
我不确定您想对服务器 SKU 进行哪种“优化”。选择完全适合一个 Pod 的 SKU 并不是一个好做法。您应该使用较小的 Pod 并信任调度程序进行装箱。
答案2
你应该在 Kubernetes 中运行 Ceph 吗？
如果你希望使用 Ceph 来提供容器的 PV你应该在 Kubernetes 之外运行它。
如果你希望使用 DaemonSet 和 StatefulSet 运行 Ceph，你应该考虑这。有一些建议可以帮助您决定这是否适合您的组织。
您应该购买哪些类型的 SKU？
如果您的首要任务是优化 Ceph 部署以实现最大吞吐量，则需要一个或多个 SSD 用于 Ceph 日志，多个 SSD/HDD 用于块存储。您不会想与其他工作负载共享这些设备。如果您使用 Kubernetes 来管理此配置中的 Ceph，并将所有其他工作负载静态分区到其他服务器，那么使用 Kubernetes 的好处就很小。
如果您要优化以实现最大成本/密度，则正确的选择取决于工作负载的组合。如果 Ceph 是唯一的存储工作负载，您仍然可以通过在单独的占用空间中在存储密度优化的 SKU 上运行它来节省资金。