select一个GKE kubernetes集群的节点大小
我们正在讨论生产GKE集群的最佳节点大小。
总体上有更多的小节点还是更小的节点会更好吗？
例如，我们在以下两个选项之间进行select
- 3 x n1-standard-2（7.5GB 2vCPU）
- 2 x n1-standard-4（15GB 4vCPU）
我们在这些节点上运行：
- 弹性search群集
- Redis集群
- PHP API微服务
- 节点API微服务
- 3个独立的Node / React网站
我认为有两点需要考虑：
- 复制 ：
像Elasticsearch或Redis集群/ sentinel这样的服务只有在有足够的Pod运行服务的情况下才能提供可靠的冗余：如果有2个节点，5个elasticsearch Pod，那么很可能是3个Pod将在一个节点上，而在另一个节点上则为2个：您最大的复制将是2.如果碰巧在同一个节点上有两个副本Pod，并且它下降，则会丢失整个索引。
[编辑]：如果你使用持久块存储（这最好的持久性，但设置很复杂，因为每个节点需要自己的块，使得缩放比较棘手），你不会失去整个索引，但如果你依靠在本地存储。
出于这个原因，更多的节点更好。
- 性能 ：
显然，你需要足够的资源。 较小的节点具有较低的资源，所以如果Pod开始获得大量stream量，则将更容易达到其极限，并且Pod将被popup。
Elasticsearch是一个相当大的记忆猪。 你必须确定运行所有这些Pod是否需要更大的节点。
最后，随着您的需求的增长，您可能希望使用不同容量节点的混合，这些节点在GKE中将具有容量标签，可用于设置内存和CPU的资源配额和限制。 您还可以添加自己的标签，以确保某些Pod最终位于特定types的节点上。