I recently migrated a production environment to a new Kubernetes cluster running version 1.36. I want to install Cluster Autoscaler, but the newest version I can find is 1.35. Is it safe to run Cluster Autoscaler 1.35 with a 1.36 control plane, or should I use a different scaling solution?
3 Answers
This version mismatch should ideally be checked before upgrading a production cluster. If there is no compatible 1.36 release yet, consider delaying the upgrade, confirming the compatibility matrix with the provider, or using Karpenter instead. If you change autoscaling solutions, scale the old autoscaler down first, then safely drain and remove the node groups it managed so you do not leave orphaned nodes or have competing controllers make scaling decisions.
For a managed Kubernetes environment, Karpenter may be a better option than Cluster Autoscaler because it provisions capacity more dynamically and is less tightly coupled to a specific Kubernetes minor version. Managed auto mode is another possibility, but verify its requirements and migration process before switching in production.
It can manage new capacity, but enabling it does not automatically take over existing managed node groups. Those nodes usually remain under the old setup, so you need a planned migration with cordoning, draining, and new node pools. Avoid running two scaling systems against the same capacity at the same time.
Cluster Autoscaler generally follows the Kubernetes minor version, so a 1.36 cluster should use a 1.36.x release when available. A 1.35 version might appear to work because Kubernetes supports some version skew, but that combination is not guaranteed or fully supported and could lead to difficult-to-diagnose scaling problems. Check the available image and release tags before deploying it.
If I use auto mode, will it manage the worker nodes automatically? Can I enable it on my existing cluster?