When you enable Adaptive Pod placement on a cluster, the following steps are done:
1. Kompass classifies Pods:
Kompass begins to classify each Pod as either Evictable or Unevictable, based on the same logic used by the cluster’s autoscaler. Pods are classified when they are created and then reviewed periodically.
Kompass labels each Pod as either Kompass-evictable or Kompass-unevictable.
If a Pod’s classification changes throughout its lifecycle (for example, when there is a PDB configuration change), the label is updated.
2. Kompass mutates Pod scheduling using affinity rules:
Kompass adds the following rules to the Pod specification:
Soft affinity toward Pods with the same classification.
Group evictable Pods with other evictable Pods, and group unevictable Pods with unevictable Pods.Soft anti-affinity away from Pods with the other classification.
Keep evictable Pods and unevictable Pods away from each other.
The scheduler then schedules Pods onto nodes based on classification and affinity rules.
Kompass logs all actions related to Pod placement, including labeling, affinity rules, and eviction.
Pod eviction
Pod eviction is done according to Kompass-defined logic that optimizes eviction according to PDB and other restrictions. Application Pods are protected from downtime by limiting eviction per workload, as follows:
During each eviction cycle (--eviction-interval, default is 4 hours) the maximum Pods that can be evicted per workload is:
If there is a PDB, limited by the PDB.
If there is no PDB, limited by a user-defined limit (--eviction-max-pods-multiplier, default is 20% of Pods in a workload).
These types of Pods are not evicted:
Pods from Jobs/CronJobs workloads
Pods classified as unevictable
Limitations:
Supports only Karpenter and Cluster Autoscaler.
Runs only on clusters on which Pod rightsizing is enabled.
Does not run on workloads that point only to node pools / ASGs with no consolidation.
See also: