node.js - 为 GKE kubernetes 集群选择 Node 大小

Question

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

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

例如我们在以下两个选项中进行选择

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

我们在这些 Node 上运行:

• Elasticsearch 集群
• Redis 集群
• PHP API 微服务
• Node API 微服务
• 3 个独立的 Node/React 网站

Answer 1

我认为有两点需要考虑:

• 复制:

像 Elasticsearch 或 Redis 集群/sentinel 这样的服务只有在有足够的 Pod 运行该服务时才能提供可靠的冗余:如果你有 2 个 Node ，5 个 elasticsearch Pod，很可能 3 个 Pod 在一个 Node 上，2 个在其他 Node 上另一个:你的最大复制将是 2。如果你碰巧在同一个 Node 上有 2 个副本 Pod 而它宕机了，你将失去整个索引。

[编辑]:如果您使用持久性 block 存储(这最适合持久性，但设置起来很复杂，因为每个 Node 都需要自己的 block ，使得缩放变得棘手)，您不会“丢失整个索引”，但这是事实如果您依赖本地存储。

因此， Node 越多越好。

• 表现:

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

Elasticsearch 非常耗费内存。您必须考虑运行所有这些 Pod 是否需要更大的 Node 。

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