Tracking issue for In-place Updates implementation

[alexander-demicev]

This is a tracking issue for the implementation of in-place updates. At the moment, it only covers the work required for the initial phase of the project to reach the experimental (alpha) stage.

The design and approach are described in the in-place updates proposal.

• Initial refactorings / prereqs:

  • ✨ Ensure ExtensionConfig controller can be used outside of the core provider #12754
  • 🌱 Remove unused CleanUpManagedFieldsForSSAAdoption code #12788
  • 🌱 Refactor BootstrapConfig/InfraMachine creation in MachineSet controller #12881
  • ✨ KCP/MS: Refactor BootstrapConfig/InfraMachine managedFields for in-place #12890

• Add InPlaceUpdates feature gate: ✨Add inplace updates featuregate #12755

• Introduce Runtime Hook API changes, see examples section of the proposal for details.

  • Introduce CanUpdateMachine/CanUpdateMachineSet hooks and corresponding Request/Response types @alexander-demicev
  • Introduce UpdateMachine hook and corresponding Request/Response types @alexander-demicev

• Modify core controllers

  • KubeadmControlPlane controller updates
    • ✨ KCP: compare ClusterConfiguration via KubeadmConfig instead of annotation on Machine #12758
    • 🌱 Simplify cleanupConfigFields in KCP #12776
    • 🌱 Cleanup KCP code: variable/func renames, func order #12793
    • 🌱 Simplify KCP matchesKubeadmConfig #12813
    • 🌱 KCP: Add current/desired objects to NotUpToDateResult & refactor object creation #12817
    • ✨ KCP: Extend rollout logic for in-place updates #12840
    • ✨ KCP: Implement CanUpdateMachine #12857
    • ✨ KCP: implement trigger in-place update #12897
      • Consider: EligibleForInPlaceUpdate computation ✨ KCP: Extend rollout logic for in-place updates #12840 (comment)
    • UpToDate condition should now consider Updating condition
    • See these parts of the proposal for details:
      • High-level flow
      • Deciding the update strategy
      • KCP updates
  • MachineDeployment controller updates
    • [Fabrizio] Add rollout planner part1
      • RolloutUpdate strategy 🌱 Add rollout planner #12804
      • OnDelete strategy 🐛 Fix race conditions ScaleDownOldMS OnDelete #12830
      • Create newMS, apply changes 🌱 Move compute and create ms to rollout planner #12841
        • Preliminary refactor 🌱 Refactor MachineTemplateUpToDate #12811
    • [Fabrizio] Fix issues in scale down old MS
      • RolloutUpdate strategy 🐛 Fix race conditions ScaleDownOldMS #12812
      • OnDelete strategy 🐛 Fix race conditions ScaleDownOldMS OnDelete #12830
    • [Fabrizio] Add support for in-place in rollout planner: ✨ Add in-place to rollout planner #12865
    • Implement CanUpdateMachineSet
    • Change MS controller to handle move
      • Consider how to handle pending machines e.g. for deletion ✨ Add in-place to rollout planner #12865 (comment)
      • Consider how to handle when new MS reaches desired number of machines ✨ Add in-place to rollout planner #12865 (comment)
      • Align fake machine controller to the implementation in prod code, see e.g. ✨ Add in-place to rollout planner #12865 (comment)
    • UpToDate condition should now consider Updating condition
    • See these parts of the proposal for details:
      • High-level flow
      • Deciding the update strategy
      • MachineDeployment updates
  • Machine controller modifications (@alexander-demicev)
    • ✨ Add in-place updates support for machine controller #12831
    • See these parts of the proposal for details:
      • High-level flow
      • Deciding the update strategy
      • Machine updates
  • MHC
    • ✨ Add support for checking Machine conditions in MachineHealthCheck #12827 (@furkatgofurov7)

• Follow-ups

  • Implement a wait for cache option in ssa.Patch (@sbueringer: details TBD, probably want to solve the problem in a different way)
  • Consider if to improve SSA helper to add items to the cache immediately after apply (currently they are added only after a no-op patch, so we are performing two apply for each change) (@lentzi90)
    • Note: We have to recompute the request identifier before adding to the cache based on modifiedUnstructured resourceVersion
  • Runtime Client: Use GetAllExtensions in CallAllExtensions to deduplicate code: ✨ KCP: Implement CanUpdateMachine #12857 (comment)
  • 🌱 Add defensive response status checking in runtime client #12898
  • 🌱 Cleanup getMachinesSucceeded flag from MD controller #12882
  • [Later] Consider if to improve the MS definition of Unhealthy when picking machines for deletion, see 🐛 Fix race conditions ScaleDownOldMS #12812 (comment)
  • [Later] KCP: Optimize preflightCheck calls: ✨ KCP: Implement CanUpdateMachine #12857 (comment)
  • [Later] Improve InfraMachine controller to only add finalizer after InfraMachine has owner (avoids retries on conflict in RemoveManagedFieldsForLabelsAndAnnotations) (ask @sbueringer for more details, same in CAPV)

• Set up E2E testing

  • See: Tracking issue for In-place Updates implementation #12291 (comment)

• Misc

  • Finalize all TODO(in-place)

• Create documentation

  • Feature flag configuration
  • New runtime hook and its API contracts
  • Extend the ControlPlane contract with a (optional) rule about in-place
  • Updater structure and logic
  • Guide to implementing extensions
  • Explanation of the CAPD Kubeadm Updater
  • Tutorials for usage

• Update proposal

  • Consider adding PR description of ✨ KCP/MS: Refactor BootstrapConfig/InfraMachine managedFields for in-place #12890
  • Consider adding parts of the implementation design doc: https://docs.google.com/document/d/1MuhwSL-1ZMsiMoEHE9fVRha9Wkb5ORUFCLSMVNK_mTA/edit?tab=t.0#heading=h.lr4ie3qnitfn

Follow-up (after everything else is done, possibly in the next relase cyle)

• Improve ExtensionConfig pause behavior: updating the registry is also paused, warmup runnable ignores pause today

Docs

• Implementation design: https://docs.google.com/document/d/1MuhwSL-1ZMsiMoEHE9fVRha9Wkb5ORUFCLSMVNK_mTA/edit?tab=t.0

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-ci-robot]

@alexander-demicev: The label(s) /label kind/design cannot be applied. These labels are supported: api-review, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, team/katacoda, refactor, ci-short, ci-extended, ci-full. Is this label configured under labels -> additional_labels or labels -> restricted_labels in plugin.yaml?

In response to this:

/label kind/design

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[alexander-demicev]

/kind design