4

我们正在讨论生产 GKE 集群的最佳节点大小。

一般来说，拥有更多更小的节点还是更少更大的节点更好？

例如，我们在以下两个选项之间进行选择

  1. 3 x n1-standard-2 (7.5GB 2vCPU)
  2. 2 x n1-standard-4 (15GB 4vCPU)

我们在这些节点上运行：

  • 弹性搜索集群
  • Redis 集群
  • PHP API 微服务
  • 节点 API 微服务
  • 3 个独立的 Node / React 网站
4

1 回答 1

5

在我看来有两点需要考虑：

  • 复制：

像 Elasticsearch 或 Redis 集群/哨兵这样的服务只有在有足够多的 Pod 运行服务时才能提供可靠的冗余：如果你有 2 个节点，5 个 elasticsearch Pod，很可能 3 个 Pod 将在一个节点上，2 个在另一个节点上：您的最大复制将是 2。如果您碰巧在同一节点上有 2 个副本 Pod 并且它出现故障，您将丢失整个索引。

[编辑]：如果您使用持久块存储（这最适合持久性，但设置起来很复杂，因为每个节点都需要自己的块，这使得扩展变得棘手），您不会“丢失整个索引”，但如果您依赖这是真的在本地存储上。

因此，节点越多越好。

  • 性能：

显然，您需要足够的资源。较小的节点资源较少，因此如果 Pod 开始获得大量流量，它将更容易达到其限制并且 Pod 将被弹出。

Elasticsearch 非常消耗内存。您必须弄清楚运行所有这些 Pod 是否需要更大的节点。

最后，随着您的需求增长，您可能希望混合使用不同容量的节点，这些节点在 GKE 中将具有容量标签，可用于设置资源配额以及内存和 CPU 的限制。您还可以添加自己的标签以确保某些 Pod 最终位于某些类型的节点上。

于 2016-12-05T16:45:01.070 回答