Eviction and Placement Disruption Budget
This document explains the concept of Eviction and Placement Disruption Budget in the context of the fleet.
Overview
Eviction provides a way to force remove resources from a target cluster once the resources have already been propagated from the hub cluster by a Placement object.
Eviction is considered as an voluntary disruption triggered by the user. Eviction alone doesn’t guarantee that resources won’t be propagated to target cluster again by the scheduler.
The users need to use taints in conjunction with Eviction to prevent the scheduler from picking the target cluster again.
The Placement Disruption Budget object protects against voluntary disruptions.
The only voluntary disruption that can occur in the fleet is the eviction of resources from a target cluster which can be achieved by creating the ClusterResourcePlacementEviction object.
Some cases of involuntary disruptions in the context of fleet,
- The removal of resources from a member cluster by the scheduler due to scheduling policy changes.
- Users manually deleting workload resources running on a member cluster.
- Users manually deleting the ClusterResourceBindingobject which is an internal resource the represents the placement of resources on a member cluster.
- Workloads failing to run properly on a member cluster due to misconfiguration or cluster related issues.
For all the cases of involuntary disruptions described above, the Placement Disruption Budget object does not protect against them.
ClusterResourcePlacementEviction
An eviction object is used to remove resources from a member cluster once the resources have already been propagated from the hub cluster.
The eviction object is only reconciled once after which it reaches a terminal state. Below is the list of terminal states for ClusterResourcePlacementEviction,
- ClusterResourcePlacementEvictionis valid and it’s executed successfully.
- ClusterResourcePlacementEvictionis invalid.
- ClusterResourcePlacementEvictionis valid but it’s not executed.
To successfully evict resources from a cluster, the user needs to specify:
- The name of the ClusterResourcePlacementobject which propagated resources to the target cluster.
- The name of the target cluster from which we need to evict resources.
When specifying the ClusterResourcePlacement object in the eviction’s spec, the user needs to consider the following cases:
- For PickFixedCRP, eviction is not allowed; it is recommended that one directly edit the list of target clusters on the CRP object.
- For PickAll&PickNCRPs, eviction is allowed because the users cannot deterministically pick or unpick a cluster based on the placement strategy; it’s up to the scheduler.
Note: After an eviction is executed, there is no guarantee that the cluster won’t be picked again by the scheduler to propagate resources for a
ClusterResourcePlacementresource. The user needs to specify a taint on the cluster to prevent the scheduler from picking the cluster again. This is especially true forPickAll ClusterResourcePlacementbecause the scheduler will try to propagate resources to all the clusters in the fleet.
ClusterResourcePlacementDisruptionBudget
The ClusterResourcePlacementDisruptionBudget is used to protect resources propagated by a ClusterResourcePlacement to a target cluster from voluntary disruption, i.e., ClusterResourcePlacementEviction.
Note: When specifying a
ClusterResourcePlacementDisruptionBudget, the name should be the same as theClusterResourcePlacementthat it’s trying to protect.
Users are allowed to specify one of two fields in the ClusterResourcePlacementDisruptionBudget spec since they are mutually exclusive:
- MaxUnavailable - specifies the maximum number of clusters in which a placement can be unavailable due to any form of disruptions.
- MinAvailable - specifies the minimum number of clusters in which placements are available despite any form of disruptions.
for both MaxUnavailable and MinAvailable, the user can specify the number of clusters as an integer or as a percentage of the total number of clusters in the fleet.
Note: For both MaxUnavailable and MinAvailable, involuntary disruptions are not subject to the disruption budget but will still count against it.
When specifying a disruption budget for a particular ClusterResourcePlacement, the user needs to consider the following cases:
| CRP type | MinAvailableDB with an integer | MinAvailableDB with a percentage | MaxUnavailableDB with an integer | MaxUnavailableDB with a percentage | 
|---|---|---|---|---|
| PickFixed | ❌ | ❌ | ❌ | ❌ | 
| PickAll | ✅ | ❌ | ❌ | ❌ | 
| PickN | ✅ | ✅ | ✅ | ✅ | 
Note: We don’t allow eviction for
PickFixedCRP and hence specifying aClusterResourcePlacementDisruptionBudgetforPickFixedCRP does nothing. And forPickAllCRP, the user can only specifyMinAvailablebecause total number of clusters selected by aPickAllCRP is non-deterministic. If the user creates an invalidClusterResourcePlacementDisruptionBudgetobject, when an eviction is created, the eviction won’t be successfully executed.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can further improve.
Sorry to hear that. Please tell us how we can fix the experience for you.