Selecting a node size for a GKE kubernetes cluster

12/2/2016

We are debating the best node size for our production GKE cluster.

Is it better to have more smaller nodes or less larger nodes in general?

e.g. we are choosing between the following two options

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

We run on these nodes:

  • Elastic search cluster
  • Redis cluster
  • PHP API microservice
  • Node API microservice
  • 3 x seperate Node / React websites
-- AndrewMcLagan
docker
google-cloud-platform
kubernetes
node.js
rancher

1 Answer

12/5/2016

Two things to consider in my opinion:

  • Replication:

services like Elasticsearch or Redis cluster / sentinel are only able to provide reliable redundancy if there are enough Pods running the service: if you have 2 nodes, 5 elasticsearch Pods, well chances are 3 Pods will be on one node and 2 on the other: you maximum replication will be 2. If you happen to have 2 replica Pods on the same node and it goes down, you lose the whole index.

[EDIT]: if you use persistent block storage (this best for persistence but is complex to setup since each node needs its own block, making scaling tricky), you would not 'lose the whole index', but this is true if you rely on local storage.

For this reason, more nodes is better.

  • Performance:

Obviously, you need enough resources. Smaller nodes have lower resources, so if a Pod starts getting lots of traffic, it will be more easily reaching its limit and Pods will be ejected.

Elasticsearch is quite a memory hog. You'll have to figure if running all these Pods require bigger nodes.

In the end, as your need grow, you will probably want to use a mix of different capacity nodes, which in GKE will have labels for capacity which can be used to set resources quotas and limits for memory and CPU. You can also add your own labels to insure certain Pods end up on certain types of nodes.

-- MrE
Source: StackOverflow