Manage worker node pools

Flex cluster plans introduces the concept of worker node pools.

The "Worker Node Pools" tab in the cluster creation/edit form allows you to manage the compute instances of your cluster.

You are allowed to customize the number of vCPUs, amount of Memory, amount of Persistent Storage and number of nodes for a worker node pool.

The button "Add Worker Node Pool" opens the following form:

The following restrictions apply:

You could specify between 1 and 9 worker node pools.
You could specify the node pools name only during creation. It could not be changed after that. For this you could add a new pool and remove the old one.
Allowed values for "Node vCPU" are: 1, 2, 4, 8, 16, 32, 64.
Allowed values for "Node Memory" are: 4, 8, 16, 32, 64, 128, 256, 512.
Allowed values for "Node Storage" are: between 25 and 500.
For non-upgraded clusters, only the number of nodes for existing node pools could be modified. Adding pools, deleting pools and modifying CPU/Memory/Storage/Node-taints/Node-labels is not allowed.
Clusters created before 1st of June were migrated to flex cluster plans. During the migration, they were assigned one node pool with the name of the T-shirt size plan they used during creation. You are not allowed to edit the properties of this pool. Please create a new one.

Vertical Scaling

Vertical scaling can be triggered by editing the "Worker Node Pools" tab.

Here are few important conditions that need to be met to trigger a vertical scaling operation:

Only existing pools must be modified.
The creation of a new pool or the deletion of a pool, in the same edit operation, will lead to the standard update process which will not trigger the creation of additional nodes.
Only a combination of the following parameters must be present in the update operation: (cpu, memory, storage, node-taints and node-labels)
Any modification of the worker node count in a pool, in the same edit operation, will lead to the standard update process which will not trigger the creation of additional nodes. In other words, in order to have a vertical scaling scenario, the number of worker nodes must remain the same.
Any other modification such as insecure-registries or email owner, in the same edit operation, will lead to the standard update process which will not trigger the creation of additional nodes.
During a vertical scaling operation, all the nodes will be drained one time.

Update scenario	Vertical scaling ?	Horizontal scaling ?
Changing node-labels	✅	🚫
Changing node-taints	✅	🚫
Changing storage	✅	🚫
Changing memory	✅	🚫
Changing cpu	✅	🚫
Increasing count AND edit of (cpu/memory/storage/taints/labels)	🚫	✅
Decreasing count AND edit of (cpu/memory/storage/taints/labels)	🚫	✅
Adding new pool AND existing pools remain unchanged	🚫	✅
Change of worker count (only)	🚫	✅
Adding new node pool AND edit of (cpu/memory/storage/taints/labels)	🚫	✅
Removing 1 node pool	🚫	✅
Removing 1 node pool AND edit of (cpu/memory/storage/taints/labels)	🚫	✅

Notes:

Horizontal scaling operation (also called standard operation) will trigger the drain of all the worker nodes (one at a time) except in one condition. If only the worker node count is changed or a new pool is added, existing nodes won't be drained.