Pod Placement
Understanding Un-Evictable Pods
In Kubernetes clusters, “un-evictable” pods is a term we use to describe critical workloads that cannot be evicted from the nodes they are running on by the cluster autoscaler. These workloads are typically critical applications, including databases, messaging systems, or other stateful applications crucial for data consistency and reliability. Ensuring the uninterrupted operation of these pods is essential to maintain data integrity, meet performance expectations, and adhere to service level agreements (SLAs).
Un-evictable pods are often safeguarded using mechanisms such as Pod Disruption Budgets (PDBs) and annotations like cluster-autoscaler.kubernetes.io/safe-to-evict: "false", karpenter.sh/do-not-evict: "true" and more.
Impact on Cluster Scaling and Costs
The Cluster Autoscaler avoids scaling down nodes with un-evictable pods, even if those nodes are significantly underutilized. This restriction can result in suboptimal resource utilization and higher operational costs, as nodes must remain active solely to accommodate these pods, limiting overall cluster efficiency.
How ScaleOps Helps
ScaleOps addresses un-evictable pods with the Pod placement feature, which bin-packs these pods onto fewer nodes. This optimized placement unblocks nodes from scaling down, cuts operational costs, and enhances cluster efficiency.
Technically, ScaleOps leverages Kubernetes preferred pod and node affinity to maintain optimal placement of identified un-evictable pods. This approach ensures that predefined constraints, such as node selectors, pod and node affinity, anti-affinity, taints, and other scheduling rules, are respected.
To achieve this, ScaleOps applies the labels scaleops.sh/node-packing and scaleops.sh/managed-unevictable to nodes and pods, to enforce the desired placement of un-evictable pods.
Key Features
On the Pod Placement Page, you can explore potential savings from automating these workloads, view how many nodes are blocked from scale-down and explore effective action items.
Automatic Bin-Packing: ScaleOps identifies unevictable pods and optimizes their placement to maximize resource utilization, minimizing the number of nodes blocked from scaling down.
Types of Unevictable Workloads
-
Unevictable workloads: Pods with a PodDisruptionBudget or any annotation that prevents node scale-down.
-
Pods without owner: Pods lacking an owner reference (e.g., a ReplicaSet).
-
Un-ready workloads: Pods that remain in a unready state for extended periods (due to availability issues).
-
Kube-system workloads: Pods which run critical cluster services, often have high-priority classes, and may be deployed as static pods.
-
Workloads with local storage: Pods that use node local storage resources (meaning their data is stored directly on the node where they are scheduled).
Click the Automate Now button to optimize all unevictable workload types upon pod creation.
Alternatively, enable automation for specific workload types.
Note: The pods will be bin-packed upon pod creation. You can click the “Optimize Now” buttons to immediately apply a rollout.
Policy-Based Feature: Bin-packing for un-evictable pods is enabled by default in ScaleOps policies, ensuring cost reduction to relevant workloads without manual intervention or disruptions.
Simple Workload Detection and Automation: ScaleOps provides a straightforward way to identify un-evictable workloads using its built-in filter called “unevictable.” Upon automation these workloads will be optimized and bin-packed by ScaleOps.
By leveraging ScaleOps, users can efficiently manage un-evictable pods in their Kubernetes clusters, improve resource utilization, and lower operational costs.