/assign

/assign

/assign

/assign

Thanks for the detailed proposal!

I have some in-line comments and some general questions

1. Will the nodes of an autonomous cluster be managed by MCM at some point and how the manually created one will be handled (ignored/deleted)?

This depends heavily on the scenario (see https://github.com/gardener/gardener/blob/68ccf134a903568bb724f0926d5c3dfa2e470379/docs/proposals/28-autonomous-shoot-clusters.md#scenarios).

• In medium touch scenarios, i.e. with virtual machines as nodes, the initial control plane nodes are assumed to be created
  by an externally running MCM (see
  https://github.com/gardener/gardener/blob/68ccf134a903568bb724f0926d5c3dfa2e470379/docs/proposals/28-
  autonomous-shoot-clusters.md#gardenadm-bootstrap). Worker nodes should be completely managed by an in-cluster
  MCM. The initial control plane nodes should eventually be adopted by the in-cluster MCM.
• The high touch scenario is a bit more difficult as we assume bare metal nodes there. Unless the infrastructure is
  programmable, e.g. via https://github.com/ironcore-dev, there might be simply no MCM available for that platform.
  Therefore, this depends on having a corresponding MCM, which might not be able to manage the nodes as it does with
  virtual machines. There might be some overlap with ☂️ [GEP-31] Support for In-Place Node Updates #10219 in this regard.

2. While k8s minor version update is expected to be in-place, is it planned to support OS version update?

It is assumed that this will be tackled as part of #10219 (see https://github.com/gardener/gardener/blob/68ccf134a903568bb724f0926d5c3dfa2e470379/docs/proposals/28-autonomous-shoot-clusters.md#high-touch), but yes, the plan is to be able to do as much as possible also in-place, potentially with a restart of the node if required.

3. How will be agents (gardenadm, garden-node-agent, gardener-resource-manager, etc.) on the node updated?

gardenadm is currently not envisioned to be run as an agent, but rather as a command line program. The user brings it to the node via any viable option ranging from download to a USB stick. After the initial setup, gardenadm should no longer be necessary. Day-2 operations are assumed to be handled by a gardenlet variant in conjunction with a garden.

That being said, the update of the gardener-node-agent as well as the static pods of the control plane is handled via existing means, i.e. OperatingSystemConfig and gardener-node-agent. The gardenlet eventually managing the autonomous cluster will create an OperatingSystemConfig including changes to the gardener-node-agent. In addition to that, the in-cluster dummy resources for the static pods (see https://github.com/gardener/gardener/blob/68ccf134a903568bb724f0926d5c3dfa2e470379/docs/proposals/28-autonomous-shoot-clusters.md#dealing-with-webhooks-for-control-plane-components) will be updated accordingly triggering changed files to be added to the OperatingSystemConfig, which in turn will then be rolled out via gardener-node-agent.

It is assumed that this will be tackled as part of #10219 (see https://github.com/gardener/gardener/blob/68ccf134a903568bb724f0926d5c3dfa2e470379/docs/proposals/28-autonomous-shoot-clusters.md#high-touch), but yes, the plan is to be able to do as much as possible also in-place, potentially with a restart of the node if required.

Actually, we would still go (at least for now) with regular rolling updates of the worker or control plane nodes in case they are managed by machine-controller-manager. In-place updates are only needed on bare metal machines, i.e., in the high-touch scenario.

LGTM label has been added.

LGTM label has been added.

Thanks for answering my questions. Looking forward to seeing the implementation :)
/lgtm

/lgtm

/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ScheererJ

The full list of commands accepted by this bot can be found here.

The pull request process is described here

/retest

/test all