kubernetes-sigs / kubernetes-sigs/cluster-api

Allow granular control on how in-place updates affects availability

Open
#14,160 1 comment 1 reaction 2 assignees View on GitHub

@fabriziopandini is already working on this.

Since Aug 31, 2026.

area/control-plane area/machinedeployment kind/feature priority/important-soon triage/accepted
Dominant language
Go
Stars
4.3k
Forks
1.6k
Avg merge
1d 3h
Merged PRs (30d)
113

Description

What would you like to be added (User Story)?

As a In-place RuntimeExtension author I want to be able to declare when an in-place update change affects availability or not

Detailed Description

As of today all in-place updates are considered as potentially disruptive, so it is considered as an operation that will affect availability.

As a consequence, in case of MaxUnavailability=0, an additional machine is added to ensure there is enough “availability budget” to perform in-place changes safely

However not all the in-place changes are the same and in some case there is a good confidence that the change won’t impact availability

So the idea is to introduce an enhancement to allow the RT to report when an in-place change does not impact availability and act accordingly (do not create the additional machine)

More specifically.

The CanUpdate/CanUpdateMachineSet hook response will be extended by adding the following new field

// +optional
AffectsAvailability *bool `json:"affectsAvailability,omitempty"`

If the field is not set, the system will assume AffectsAvailability==true, ensuring compatibility with the current behaviour.

If the field is set to False, the system will act accordingly, and:

  • Do not create an additional machine in case of MaxUnavailability=0 (because the in-place update operation is not impacting availability)
  • Avoid setting Available condition to false for machines in-place updating when the operation is not affecting availability
Anything else you would like to add?

Please note that:

  • In KCP, in-place update will only happen if the control plane is healthy (as of today)
  • The system will ensure that the in-place update is performed in an incremental fashion, with maxUnavailability acting as the "speed limit" (as of today)
  • Implementers of In-place runtime extensions should use this feature with great caution, especially for control plane machines, because when they are declaring affectsAvailability == false the in-place update sequence will start without the safety net provided by the additional machine
Tasks

/kind feature
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.