Fixed storage size to allow scale down

[maggie44]

When scaling up from cpx11 to cpx21 the storage goes up from 40GB to 80GB. If I then try to scale back down, the disk size is too large to go back to cpx11. In the Cloud, there is a check box for CPU and RAM only which allows me to then scale back down again at a later date. Is the same option available here?

[mysticaltech]

@maggie44 You cannot rescale this way with this project. What you have to do instead is create a new nodepool, apply and wait that it's running, you can check with kubectl get nodes, and then kubectl drain, and then kubectl delete, when this is done, you set the node count of the old nodepool to 0, and apply (never delete an old nodepool, only allowed to set the count to 0). That last step will remove it from Hetzner.

Basically, this will allow you to shift all workloads from your old node to your new one, that way you can do both rescaling and downscaling, but it does involve creating new nodepools, if you do not have one already that has the node type you want.

More on the draining a node on Kube:

Remove a Node from Kubernetes.

You:

How to remove a node from kubernetes

ChatGPT:

To remove a node from a Kubernetes cluster, you need to first drain the node to evict any running workloads, then delete the node from the cluster. Here's a step-by-step guide on how to do this:

1. Identify the node to be removed:
   Use the following command to list all nodes in the cluster:

   kubectl get nodes
   

   Identify the node you want to remove, and replace <node-name> with the actual name in the following steps.

2. Drain the node:
   This step will evict all running workloads and mark the node as unschedulable, preventing any new workloads from being scheduled on it:

   kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
   

   The --ignore-daemonsets flag ignores any DaemonSet-managed pods, and the --delete-emptydir-data flag deletes any emptyDir data. If you need to delete local data, use the --delete-local-data flag instead of --delete-emptydir-data.

3. Remove the node from the cluster:
   Use the following command to delete the node:

   kubectl delete node <node-name>
   

4. Verify the node has been removed:
   To confirm that the node has been removed from the cluster, run:

   kubectl get nodes
   

   The <node-name> should no longer appear in the list of nodes.

5. Clean up the node (optional):
   Depending on your setup, you might need to perform additional cleanup tasks on the node itself. This may involve uninstalling the Kubernetes components (kubelet, kubeadm, etc.), or even decommissioning the node if it's a virtual or physical machine.

Remember that removing a node from a Kubernetes cluster can impact the availability and performance of your workloads, so make sure to plan accordingly and adjust your deployments as needed.

[maggie44]

Thanks for this clarification.

Adding in my understanding here, not directly related to the question just as it helps to understand why things do other things.

As per the docs,

Also, before decreasing the count of any nodepools to 0, it's essential to drain and cordon the nodes in question. Otherwise, it will leave your cluster in a bad state.

This is effectively what you are describing here (minus the cordon):

kubectl get nodes, and then kubectl drain, and then kubectl delete

And setting to 0 I assume is so that there is an entry in the space that is left by the removed node due to something related to the way the subnets works?

The only nodepools that are safe to remove from the list are at the end. That is due to how subnets and IPs get allocated (FILO).

[mysticaltech]

@maggie44 100%, we have to leave the old unused nodepool, because of how the subnets are created and pre-allocated. Theorically, the only nodepools that can be removed completely after scaling down to 0 is the one at the end of the list, removing that one shouldn't hurt.