Closed levshvarts closed 3 months ago
Should we be tainting with both in case it's an old cluster? Or this only happens for new cluster creates and we're definitely using v20 there? Maybe we should be checking the kubernetes version and then using the correct taint?
You are right, we should be checking the version - old clusters were created with node-role.kubernetes.io/master:NoSchedule
, so if we are updating a cluster and need to move workload onto a master tainting should be use the old annotations.
My concern is how to handle these issues going forward, since we'll be hitting changes like this periodically.
@gainsley - what do you think?
I think we need to track the cluster k8s version anyway, to allow for upgrade (triggered by users), and to be able to notify users that the cluster version is old/deprecated and needs to be upgraded. If we are tracking the k8s version, then we can determine the correct taint to use.
It looks like we must use the old taint before 1.20, and we must use the new taint from 1.24. Sources: https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint https://kubernetes.io/blog/2022/04/07/upcoming-changes-in-kubernetes-1-24/#api-removals-deprecations-and-other-changes-for-kubernetes-1-24
Updated code to check for older k8s cluster version we had. I made it explicit, since that was the only version we had as far as I recall.
Description
node-role.kubernetes.io/master:NoSchedule
taint has been replaced withnode-role.kubernetes.io/control-plane:NoSchedule
from k8s 1.20.