MKE descheduler lifecycle

If the policy ConfigMap does not exist when the descheduler is enabled, MKE creates it with an empty policy (no profiles). Cluster administrators can then edit the policy.yaml file to enable upstream descheduler plugins.

MKE preserves the policy.yaml file and does not overwrite it during image updates, MKE upgrades, or changes to extra_flags. It does, however, reapply the deployment and RBAC resources as needed.

When the policy changes, MKE updates a hash annotation on the deployment Pod template, which triggers Kubernetes to roll the descheduler Pods so that they use the updated policy.