Skip to content

Commit

Permalink
fix header
Browse files Browse the repository at this point in the history
  • Loading branch information
edibble21 committed Dec 4, 2024
1 parent 93da95a commit 8984bf8
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion website/content/en/v1.0/upgrading/v1-migration.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ Use the [compatibility matrix]({{<ref "compatibility#compatibility-matrix">}}) t
Karpenter `v1.0` is a major release and contains a number of breaking changes.
The following section will highlight some of the major breaking changes, but you should review the full [changelog]({{<ref "#changelog">}}) before proceeding with the upgrade.

### Forceful Expiration
#### Forceful Expiration

Previously, Karpenter would only begin draining an expired node after ensuring graceful disruption was possible and replacement capacity was provisioned. Now, NodeClaim expiration is forceful. Once a NodeClaim expires, Karpenter will immediately begin draining the corresponding Node without first provisioning a replacement Node. This forceful approach means that all expired NodeClaims that were previously blocked from disruption (due to Pod Disruption Budgets (PDBs), do-not-disrupt pods, or other constraints) will be expired. The scheduler will then attempt to provision new Nodes for the disrupted workloads as they are draining. This behavior may lead to an increased number of pods in the "Pending" state while replacement capacity is being provisioned. Before upgrading, users should check for expired NodeClaims and resolve any disruption blockers to ensure a smooth upgrade process.

Expand Down

0 comments on commit 8984bf8

Please sign in to comment.