Repository: gardener/gardener
Pull request #12005: [GEP-31] Add usage doc for in-place update
Author: login: ary1992
Labels: name: kind/enhancement
description: Enhancement, improvement, extension
name: area/documentation
description: Documentation related
name: size/L
description: Denotes a PR that changes 100-499 lines, ignoring generated files.
name: cla: yes
description: Indicates the PR's author has signed the cla-assistant.io CLA.
name: lgtm
description: Indicates that a PR is ready to be merged.
name: approved
description: Indicates a PR has been approved by an approver from all required OWNERS files.
Created: 2025-05-05T13:04:49Z | Merged: 2025-05-28T07:45:42Z

**How to categorize this PR?**
<!--
Please select area, kind, and priority for this pull request. This helps the community categorizing it.
Replace below TODOs or exchange the existing identifiers with those that fit best in your opinion.
If multiple identifiers make sense you can also state the commands multiple times, e.g.
  /area control-plane
  /area auto-scaling
  ...

"/area" identifiers:     audit-logging|auto-scaling|backup|compliance|control-plane-migration|control-plane|cost|delivery|dev-productivity|disaster-recovery|documentation|high-availability|logging|metering|monitoring|networking|open-source|ops-productivity|os|performance|quality|robustness|scalability|security|storage|testing|usability|user-management
"/kind" identifiers:     api-change|bug|cleanup|discussion|enhancement|epic|flake|impediment|poc|post-mortem|question|regression|task|technical-debt|test

For Gardener Enhancement Proposals (GEPs), please check the following [documentation](https://github.com/gardener/gardener/tree/master/docs/proposals/README.md) before submitting this pull request.
-->
/area documentation
/kind enhancement

**What this PR does / why we need it**:
Adds usage doc for in-place update under shoot_updates.md file.

**Which issue(s) this PR fixes**:
Part of https://github.com/gardener/gardener/issues/10219

**Special notes for your reviewer**:

**Release note**:
<!--
Write your release note:
1. Enter your release note in the below block.
2. If no release note is required, just write "NONE" within the block.

Format of block header: <category> <target_group>
Possible values:
- category:       breaking|noteworthy|feature|bugfix|doc|other
- target_group:   user|operator|developer|dependency
-->
```other operator
NONE
```



Diff:
diff --git a/docs/api-reference/core.md b/docs/api-reference/core.md
index 72257ec3489..c4501e65430 100644
--- a/docs/api-reference/core.md
+++ b/docs/api-reference/core.md
@@ -9733,7 +9733,7 @@ string
 </td>
 <td>
 <em>(Optional)</em>
-<p>ManualInPlaceUpdate contains the names of the pending worker pools with strategy ManualInPlaceUpdate..</p>
+<p>ManualInPlaceUpdate contains the names of the pending worker pools with strategy ManualInPlaceUpdate.</p>
 </td>
 </tr>
 </tbody>
diff --git a/docs/usage/shoot-operations/shoot_credentials_rotation.md b/docs/usage/shoot-operations/shoot_credentials_rotation.md
index 6fcfc42b6fe..ab759771bf2 100644
--- a/docs/usage/shoot-operations/shoot_credentials_rotation.md
+++ b/docs/usage/shoot-operations/shoot_credentials_rotation.md
@@ -142,6 +142,14 @@ You can check which worker pools still need to be rolled by reading `.status.cre
 Once this list is empty, the `phase` transitions to `Prepared`.
 Now you can just complete the rotation as usual (see above).
 
+#### Worker Node with ManualInPlaceUpdate Update Strategy
+
+In case of manual in-place update, shoot CA rotation phase will be at `Preparing` until all the worker pools are successfully in-place updated and there are no pending worker pools with strategy ManualInPlaceUpdate.
+
+You can check which worker pools still need to be updated by reading `.status.inPlaceUpdates.pendingWorkerUpdates.manualInPlaceUpdate`.
+Once this list is empty, the `phase` transitions to `Prepared`.
+After this rotation will be completed as usual (see above).
+
 ### Observability Password(s) For Plutono and Prometheus
 
 For `Shoot`s with `.spec.purpose!=testing`, Gardener deploys an observability stack with Prometheus for monitoring, Alertmanager for alerting (optional), Vali for logging, and Plutono for visualization.
@@ -272,6 +280,11 @@ Similar to the rotation of the certificate authorities, you can control the work
 Please read [this section](#triggering-worker-node-rollout-individually) to get more information.
 It works the same way for the `ServiceAccount` token signing key (using `rotate-serviceaccount-key-start-without-workers-rollout`).
 
+#### Worker Node with ManualInPlaceUpdate Update Strategy
+
+Similar to the rotation of the certificate authorities, in case of manual in-place update, `ServiceAccount` token signing key rotation phase will be at `Preparing` until all the worker pools are successfully in-place updated and there are no pending worker pools with strategy ManualInPlaceUpdate.
+Please read [this section](#worker-node-with-manualinplaceupdate-update-strategy) for more information.
+
 ### OpenVPN TLS Auth Keys
 
 This key is used to ensure encrypted communication for the VPN connection between the control plane in the seed cluster and the shoot cluster.
diff --git a/docs/usage/shoot-operations/shoot_updates.md b/docs/usage/shoot-operations/shoot_updates.md
index 077448db6bb..f45732a34ec 100644
--- a/docs/usage/shoot-operations/shoot_updates.md
+++ b/docs/usage/shoot-operations/shoot_updates.md
@@ -53,23 +53,44 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+The `UpdateStrategy` field in the Shoot specification (`.spec.provider.workers[].updateStrategy`) gives users the flexibility to define how the `machine-controller-manager` handles worker pool updates during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+> ⚠️ The above strategies generally require draining the node when changes are made to the `Shoot` specification. The specific changes that trigger this behavior will be discussed in later sections.
+For all other spec changes like Kubernetes patch version update, the upgrade is executed without draining the node and the shoot worker nodes remain unchanged. In case of Kubernetes patch version, only the `kubelet` process is restarted with the updated Kubernetes version binary.
 
-If the Kubernetes minor version is changed, then the upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).
-The worker nodes will be terminated one after another and replaced by new machines.
+### Rolling Updates
+
+The upgrade is performed in a "rolling update" manner, during which nodes in the worker pool are replaced. Similar to how pods in Kubernetes are updated when backed by a `Deployment`.
+Worker nodes are terminated one after another and replaced by new nodes.
 The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
 
+#### Automatic Rolling Updates
+
+When the auto rolling update strategy is selected, the update process is fully orchestrated by the Gardener and the `machine-controller-manager`. The `machine-controller-manager` sequentially terminates the worker nodes and replaces them with new nodes.
+>ℹ️  This is the `default` update strategy.
+
+To create workers with `AutoRollingUpdate`, either omit the `Shoot'`s `.spec.provider.workers[].updateStrategy` field (it will default to `AutoRollingUpdate`) or explicitly set the field to `AutoRollingUpdate`.
+
+```yaml
+spec:
+  provider:
+    workers:
+    - name: cpu-worker
+      maxSurge: 0
+      maxUnavailable: 2
+      updateStrategy: AutoRollingUpdate
+```
+
 #### Customize Rolling Update Behaviour of Shoot Worker Nodes
 
 The `.spec.provider.workers[]` list exposes two fields that you might configure based on your workload's needs: `maxSurge` and `maxUnavailable`.
 The same concepts [like in Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment) apply.
-Additionally, you might customize how the machine-controller-manager (abbrev.: MCM; the component instrumenting this rolling update) is behaving. You can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+Additionally, you might customize how the `machine-controller-manager` is behaving. You can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
 
-* `machineDrainTimeout`: Timeout (in duration) used while draining of machine before deletion, beyond which MCM forcefully deletes the machine (default: `2h`).
+* `machineDrainTimeout`: Timeout (in duration) used while draining of machine before deletion, beyond which `machine-controller-manager` forcefully deletes the machine (default: `2h`).
 * `machineHealthTimeout`: Timeout (in duration) used while re-joining (in case of temporary health issues) of a machine before it is declared as failed (default: `10m`).
 * `machineCreationTimeout`: Timeout (in duration) used while joining (during creation) of a machine before it is declared as failed (default: `10m`).
 * `maxEvictRetries`: Maximum number of times evicts would be attempted on a pod before it is forcibly deleted during the draining of a machine (default: `10`).
@@ -77,7 +98,7 @@ Additionally, you might customize how the machine-controller-manager (abbrev.: M
 
 #### Rolling Update Triggers
 
-Apart from the above mentioned triggers, a rolling update of the shoot worker nodes is also triggered for some changes to your worker pool specification (`.spec.provider.workers[]`, even if you don't change the Kubernetes or machine image version).
+A rolling update of the shoot worker nodes is triggered for some changes to your worker pool specification (`.spec.provider.workers[]`, even if you don't change the Kubernetes or machine image version).
 The complete list of fields that trigger a rolling update:
 
 * `.spec.kubernetes.version` (except for patch version changes)
@@ -109,6 +130,97 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### In-Place Updates
+
+For scenarios where users want to retain the current nodes and avoid deletion during updates, Gardener provides the option of `in-place` updates. The upgrade is performed without replacing the underlying machines. Although there is an exception where new nodes are created with the updated configuration and old ones are terminated. One such exception is discussed in [Automatic inplace update](#automatic-in-place-updates) section.
+
+The existing workload is gracefully drained and evicted from the worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+
+> ℹ️ Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate in the `gardener-apiserver`.
+
+For in-place updates, the first requirement is that the operating system must support them. For a specific machine image version, the configuration for in-place updates must be defined in the `CloudProfile` under `spec.machineImages[].versions[].inPlaceUpdates`:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  versions:
+  - version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### Customize In-Place Update Behaviour of Shoot Worker Nodes
+
+In addition to customisable fields mentioned in [](#customize-rolling-update-behaviour-of-shoot-worker-nodes) section, you can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+
+* `MachineInPlaceUpdateTimeout`:  Timeout (in duration) after which an in-place update is declared as failed.
+* `DisableHealthTimeout`: A boolean value that, when set to `true`, ignores the health timeout. As a result, machines are never marked as failed, and unhealthy machines are not deleted. The default value is `true` for in-place updates.
+
+#### In-Place Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except for the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+> There are validations which restricts changing the above mentioned exception fields when `in-place` updates strategy is configured.
+
+When a worker pool is undergoing an in-place update, applying subsequent updates to the same worker pool is restricted.
+If an in-place update fails and nodes are left in a problematic state, user intervention is required to manually fix the nodes. In cases where a subsequent update is necessary to resolve the issue, users can update the worker pool after adding the force update annotation `gardener.cloud/operation=force-in-place-update` on the Shoot. Refer to [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) for more details.
+
+> ⚠️ Changing the update strategy from `AutoRollingUpdate` to `AutoInPlaceUpdate`/`ManualInPlaceUpdate` (and vice versa) is not allowed. However, switching between `AutoInPlaceUpdate` and `ManualInPlaceUpdate` is permitted.
+
+#### Automatic In-Place Updates
+
+In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by Gardener and the `machine-controller-manager`. No user intervention is required.
+Set `.spec.provider.workers[].updateStrategy` field in the `Shoot` spec to `AutoInPlaceUpdate`.
+
+```yaml
+spec:
+  provider:
+    workers:
+    - name: cpu-worker
+      maxSurge: 0
+      maxUnavailable: 2
+      updateStrategy: AutoInPlaceUpdate
+```
+
+During automatic in-place updates, if the `maxSurge` value is set to greater than 0, the `machine-controller-manager` creates new nodes equal to the `maxSurge` value. All old nodes, except for those equal to the `maxSurge` value, are updated in place, and the old nodes corresponding to the `maxSurge` value are terminated. If `maxSurge` is set to `0`, no new nodes are created and all old nodes are updated in-place.
+
+The `inPlaceUpdates.pendingWorkerUpdates.autoInPlaceUpdate` field in the Shoot status lists the names of worker pools that are pending updates with this strategy.
+
+#### Manual In-Place Updates
+
+The `ManualInPlaceUpdate` strategy allows users to control and orchestrate the update process manually.
+Set `.spec.provider.workers[].updateStrategy` field in the `Shoot` spec to `ManualInPlaceUpdate`.
+
+```yaml
+spec:
+  provider:
+    workers:
+    - name: cpu-worker
+      maxSurge: 0
+      maxUnavailable: 2
+      updateStrategy: ManualInPlaceUpdate
+```
+
+Once `machine-controller-manager` labels nodes with `node.machine.sapcloud.io/candidate-for-update`, user can select the candidate nodes for update by labeling them with `node.machine.sapcloud.io/selected-for-update=true`:
+```
+kubectl label node <node-name> node.machine.sapcloud.io/selected-for-update=true
+```
+
+The `ManualInPlaceWorkersUpdated` [constraint](../shoot/shoot_status.md/#constraints) in the shoot status indicates that at least one worker pool with the `ManualInPlaceUpdate` strategy is pending an update. Shoot reconciliation will still succeed even if there are worker pools pending updates.
+
+The `inPlaceUpdates.pendingWorkerUpdates.manualInPlaceUpdate` field in the `Shoot` status lists the names of worker pools that are pending updates with this strategy.
+
 ## Related Documentation
 
 * [Shoot Operations](shoot_operations.md)
diff --git a/pkg/apis/core/v1beta1/generated.proto b/pkg/apis/core/v1beta1/generated.proto
index 3c7cd68b122..8dfbd61d48d 100644
--- a/pkg/apis/core/v1beta1/generated.proto
+++ b/pkg/apis/core/v1beta1/generated.proto
@@ -2269,7 +2269,7 @@ message PendingWorkerUpdates {
   // +optional
   repeated string autoInPlaceUpdate = 1;
 
-  // ManualInPlaceUpdate contains the names of the pending worker pools with strategy ManualInPlaceUpdate..
+  // ManualInPlaceUpdate contains the names of the pending worker pools with strategy ManualInPlaceUpdate.
   // +optional
   repeated string manualInPlaceUpdate = 2;
 }
diff --git a/pkg/apis/core/v1beta1/types_shoot.go b/pkg/apis/core/v1beta1/types_shoot.go
index 69d6d76fa21..eb3b8eb5978 100644
--- a/pkg/apis/core/v1beta1/types_shoot.go
+++ b/pkg/apis/core/v1beta1/types_shoot.go
@@ -261,7 +261,7 @@ type PendingWorkerUpdates struct {
 	// AutoInPlaceUpdate contains the names of the pending worker pools with strategy AutoInPlaceUpdate.
 	// +optional
 	AutoInPlaceUpdate []string `json:"autoInPlaceUpdate,omitempty" protobuf:"bytes,1,rep,name=autoInPlaceUpdate"`
-	// ManualInPlaceUpdate contains the names of the pending worker pools with strategy ManualInPlaceUpdate..
+	// ManualInPlaceUpdate contains the names of the pending worker pools with strategy ManualInPlaceUpdate.
 	// +optional
 	ManualInPlaceUpdate []string `json:"manualInPlaceUpdate,omitempty" protobuf:"bytes,2,rep,name=manualInPlaceUpdate"`
 }
diff --git a/pkg/apiserver/openapi/openapi_generated.go b/pkg/apiserver/openapi/openapi_generated.go
index 65aca028b62..11aafdf4876 100644
--- a/pkg/apiserver/openapi/openapi_generated.go
+++ b/pkg/apiserver/openapi/openapi_generated.go
@@ -6743,7 +6743,7 @@ func schema_pkg_apis_core_v1beta1_PendingWorkerUpdates(ref common.ReferenceCallb
 					},
 					"manualInPlaceUpdate": {
 						SchemaProps: spec.SchemaProps{
-							Description: "ManualInPlaceUpdate contains the names of the pending worker pools with strategy ManualInPlaceUpdate..",
+							Description: "ManualInPlaceUpdate contains the names of the pending worker pools with strategy ManualInPlaceUpdate.",
 							Type:        []string{"array"},
 							Items: &spec.SchemaOrArray{
 								Schema: &spec.Schema{


Reviews:
user: login: LucaBernstein
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-13T11:05:35Z
user: login: shafeeqes
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-13T11:12:08Z
user: login: acumino
state: CHANGES_REQUESTED
author_association: MEMBER
submitted_at: 2025-05-16T16:21:18Z
user: login: rfranzke
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-22T05:28:55Z
user: login: shafeeqes
state: CHANGES_REQUESTED
author_association: MEMBER
submitted_at: 2025-05-22T05:50:05Z
user: login: shafeeqes
body: Thanks!
/lgtm
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-23T09:54:56Z
user: login: acumino
state: CHANGES_REQUESTED
author_association: MEMBER
submitted_at: 2025-05-28T05:01:25Z
user: login: acumino
body: /lgtm
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-28T06:15:33Z

Review comments:
diff_hunk: @@ -142,6 +142,13 @@ You can check which worker pools still need to be rolled by reading `.status.cre
 Once this list is empty, the `phase` transitions to `Prepared`.
 Now you can just complete the rotation as usual (see above).
 
+#### Worker Node with ManualInPlaceUpdate Update Strategy
+
+In case of manual in-place update, shoot CA rotation phase will be at `Preparing` until all the worker pools are successfully in-place updated and there are no pending worker pools with strategy ManualInPlaceUpdate.
path: docs/usage/shoot-operations/shoot_credentials_rotation.md
user: login: shafeeqes
body: ```suggestion
If the `Shoot` contains workers with strategy `ManualInPlaceUpdate`, the CA rotation phase will be at `Preparing` until all those worker pools are selected for update (See docs/usage/shoot-operations/shoot_updates.md#ManualInPlaceUpdate) and the update is completed. 
```
created_at: 2025-05-13T10:56:35Z
author_association: MEMBER
diff_hunk: @@ -142,6 +142,13 @@ You can check which worker pools still need to be rolled by reading `.status.cre
 Once this list is empty, the `phase` transitions to `Prepared`.
 Now you can just complete the rotation as usual (see above).
 
+#### Worker Node with ManualInPlaceUpdate Update Strategy
+
+In case of manual in-place update, shoot CA rotation phase will be at `Preparing` until all the worker pools are successfully in-place updated and there are no pending worker pools with strategy ManualInPlaceUpdate.
path: docs/usage/shoot-operations/shoot_credentials_rotation.md
user: login: shafeeqes
body: Add a section in the `ServiceAccount` signing key rotation below as well.
created_at: 2025-05-13T10:57:19Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,45 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+`UpdateStrategy` field under shoot worker enables the end user to choose between different behaviour of machine-controller-manager (abbrev.: MCM; the component instrumenting this rolling update) during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+### In-Place vs. Rolling Updates
 
-If the Kubernetes minor version is changed, then the upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).
-The worker nodes will be terminated one after another and replaced by new machines.
-The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+In case of in-place update worker nodes are updated without the need for replacing the VMs with the new ones. This means that the shoot worker nodes remain untouched. There is some downtime expected as the node needs to be drained and then workload will be scheduled again once the node is updated. If the Kubernetes patch version is changed, then the upgrade happens in-place. This means that the shoot worker nodes remain untouched and only the kubelet process restarts with the new Kubernetes version binary. The same applies for configuration changes of the kubelet.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: > If the Kubernetes patch version is changed, then the upgrade happens in-place.

This clashes with the newly introduced `In-Place` update. Maybe call it something else.
created_at: 2025-05-13T10:58:56Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,45 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+`UpdateStrategy` field under shoot worker enables the end user to choose between different behaviour of machine-controller-manager (abbrev.: MCM; the component instrumenting this rolling update) during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+### In-Place vs. Rolling Updates
 
-If the Kubernetes minor version is changed, then the upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).
-The worker nodes will be terminated one after another and replaced by new machines.
-The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+In case of in-place update worker nodes are updated without the need for replacing the VMs with the new ones. This means that the shoot worker nodes remain untouched. There is some downtime expected as the node needs to be drained and then workload will be scheduled again once the node is updated. If the Kubernetes patch version is changed, then the upgrade happens in-place. This means that the shoot worker nodes remain untouched and only the kubelet process restarts with the new Kubernetes version binary. The same applies for configuration changes of the kubelet.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: > In case of in-place update worker nodes are updated without the need for replacing the VMs with the new ones.

Call them machines instead of VMs.
created_at: 2025-05-13T10:59:27Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,45 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+`UpdateStrategy` field under shoot worker enables the end user to choose between different behaviour of machine-controller-manager (abbrev.: MCM; the component instrumenting this rolling update) during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+### In-Place vs. Rolling Updates
 
-If the Kubernetes minor version is changed, then the upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).
-The worker nodes will be terminated one after another and replaced by new machines.
-The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+In case of in-place update worker nodes are updated without the need for replacing the VMs with the new ones. This means that the shoot worker nodes remain untouched. There is some downtime expected as the node needs to be drained and then workload will be scheduled again once the node is updated. If the Kubernetes patch version is changed, then the upgrade happens in-place. This means that the shoot worker nodes remain untouched and only the kubelet process restarts with the new Kubernetes version binary. The same applies for configuration changes of the kubelet.
+
+In case of rolling update, upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).The worker nodes will be terminated one after another and replaced by new machines.The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+
+### AutoRollingUpdate
+
+When auto rollling update strategy is selected, upgrade is done in a "rolling update" fashion. Machine controller manager terminates the worker nodes one after the other and replaces it with new machines. This is the default update strategy. In order to create workers with `AutoRollingUpdate` either skip setting the `workers.updateStrategy` field (in this case the field will be defualted to `AutoInPlaceUpdate`) or set the field explicitly to `AutoInPlaceUpdate` for each workers.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: ```suggestion
When auto rolling update strategy is selected, upgrade is done in a "rolling update" fashion. `machine-controller-manager` terminates the worker nodes one after the other and replaces them with new machines. This is the default update strategy. In order to create workers with `AutoRollingUpdate`, either skip setting the `workers.updateStrategy` field (in this case, the field will be defaulted to `AutoRollingUpdate`) or set the field explicitly for each worker.
```
The machines are not always replaced one after the other. It depends on the `MaxSurge` and `MaxUnavailable` fields
created_at: 2025-05-13T11:01:18Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,45 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+`UpdateStrategy` field under shoot worker enables the end user to choose between different behaviour of machine-controller-manager (abbrev.: MCM; the component instrumenting this rolling update) during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+### In-Place vs. Rolling Updates
 
-If the Kubernetes minor version is changed, then the upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).
-The worker nodes will be terminated one after another and replaced by new machines.
-The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+In case of in-place update worker nodes are updated without the need for replacing the VMs with the new ones. This means that the shoot worker nodes remain untouched. There is some downtime expected as the node needs to be drained and then workload will be scheduled again once the node is updated. If the Kubernetes patch version is changed, then the upgrade happens in-place. This means that the shoot worker nodes remain untouched and only the kubelet process restarts with the new Kubernetes version binary. The same applies for configuration changes of the kubelet.
+
+In case of rolling update, upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).The worker nodes will be terminated one after another and replaced by new machines.The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
path: docs/usage/shoot-operations/shoot_updates.md
user: login: LucaBernstein
body: ```suggestion
In case of rolling update, upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`). The worker nodes will be terminated one after another and replaced by new machines. The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
```
created_at: 2025-05-13T11:03:30Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,45 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+`UpdateStrategy` field under shoot worker enables the end user to choose between different behaviour of machine-controller-manager (abbrev.: MCM; the component instrumenting this rolling update) during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+### In-Place vs. Rolling Updates
 
-If the Kubernetes minor version is changed, then the upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).
-The worker nodes will be terminated one after another and replaced by new machines.
-The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+In case of in-place update worker nodes are updated without the need for replacing the VMs with the new ones. This means that the shoot worker nodes remain untouched. There is some downtime expected as the node needs to be drained and then workload will be scheduled again once the node is updated. If the Kubernetes patch version is changed, then the upgrade happens in-place. This means that the shoot worker nodes remain untouched and only the kubelet process restarts with the new Kubernetes version binary. The same applies for configuration changes of the kubelet.
+
+In case of rolling update, upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).The worker nodes will be terminated one after another and replaced by new machines.The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+
+### AutoRollingUpdate
+
+When auto rollling update strategy is selected, upgrade is done in a "rolling update" fashion. Machine controller manager terminates the worker nodes one after the other and replaces it with new machines. This is the default update strategy. In order to create workers with `AutoRollingUpdate` either skip setting the `workers.updateStrategy` field (in this case the field will be defualted to `AutoInPlaceUpdate`) or set the field explicitly to `AutoInPlaceUpdate` for each workers.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: LucaBernstein
body: ```suggestion
When auto rolling update strategy is selected, upgrade is done in a "rolling update" fashion. Machine controller manager terminates the worker nodes one after the other and replaces it with new machines. This is the default update strategy. In order to create workers with `AutoRollingUpdate` either skip setting the `workers.updateStrategy` field (in this case the field will be defaulted to `AutoInPlaceUpdate`) or set the field explicitly to `AutoInPlaceUpdate` for each workers.
```
created_at: 2025-05-13T11:04:07Z
author_association: MEMBER
diff_hunk: @@ -109,6 +133,113 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For the scenarios where user would like to keep the current node and avoid deletion of such nodes even after the updates, Gardener comes with the option of `in-place` update. Currently `in-place` update is kept behind `InPlaceNodeUpdates` feature gate.
+
+Machine image version in the cloudprofile has the `inPlaceUpdates` field which contains the configuration for in-place updates. For an OS to support in-place update `inPlaceUpdates.supported` field should be set to true. Moreoever `inPlaceUpdates.minVersionForUpdate` specifies the minimum supported version from which an in-place update to this machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  updateStrategy: minor
+  versions:
+  - architectures:
+    - amd64
+    - arm64
+    classification: preview
+    cri:
+    - containerRuntimes:
+      - type: gvisor
+      name: containerd
+    version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+Validations are in place to restrict any further updates when the current update is going on.
+For the cases where in-place update fails and the nodes are in problematic state, it requires user intervention to fix the node manually . After the fix user should be able to restart the update by the force update annotation `gardener.cloud/operation=force-in-place-update`. Without this annotation, any subsequent updates to the same worker pool are denied, refer [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) on how to force an update for worker pools.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: ```suggestion
When a worker pool is undergoing an in-place update, applying subsequent updates to the same worker pool is restricted.
For the cases where in-place update fails and the nodes are in the failed state, it might require an operator intervention to fix the node. To update a failed worker pool to a new version, let's say, a new machine image patch version,  they can use the force in-place update annotation, refer [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) on how to force an update for worker pools.
```
created_at: 2025-05-13T11:07:48Z
author_association: MEMBER
diff_hunk: @@ -109,6 +133,113 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For the scenarios where user would like to keep the current node and avoid deletion of such nodes even after the updates, Gardener comes with the option of `in-place` update. Currently `in-place` update is kept behind `InPlaceNodeUpdates` feature gate.
+
+Machine image version in the cloudprofile has the `inPlaceUpdates` field which contains the configuration for in-place updates. For an OS to support in-place update `inPlaceUpdates.supported` field should be set to true. Moreoever `inPlaceUpdates.minVersionForUpdate` specifies the minimum supported version from which an in-place update to this machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  updateStrategy: minor
+  versions:
+  - architectures:
+    - amd64
+    - arm64
+    classification: preview
+    cri:
+    - containerRuntimes:
+      - type: gvisor
+      name: containerd
+    version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+Validations are in place to restrict any further updates when the current update is going on.
+For the cases where in-place update fails and the nodes are in problematic state, it requires user intervention to fix the node manually . After the fix user should be able to restart the update by the force update annotation `gardener.cloud/operation=force-in-place-update`. Without this annotation, any subsequent updates to the same worker pool are denied, refer [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) on how to force an update for worker pools.
+
+At present it is not allowed to change the update strategy of a worker from AutoRollingUpdate to Auto/Manual in-place update. Same applies for the other way round as well that is once the update strategy is selected as Auto/Manual in-place update , it cannot be changed to AutoRolling update. Though switching between Auto and Manual auto in-place update is allowed. 
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: ```suggestion
It is currently not allowed to change the update strategy of a worker from `AutoRollingUpdate` to `AutoInPlaceUpdate/ManualInPlaceUpdate` and vice versa. Switching between `AutoInPlaceUpdate` and `ManualInPlaceUpdate` is allowed. 
```
created_at: 2025-05-13T11:09:19Z
author_association: MEMBER
diff_hunk: @@ -109,6 +133,113 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For the scenarios where user would like to keep the current node and avoid deletion of such nodes even after the updates, Gardener comes with the option of `in-place` update. Currently `in-place` update is kept behind `InPlaceNodeUpdates` feature gate.
+
+Machine image version in the cloudprofile has the `inPlaceUpdates` field which contains the configuration for in-place updates. For an OS to support in-place update `inPlaceUpdates.supported` field should be set to true. Moreoever `inPlaceUpdates.minVersionForUpdate` specifies the minimum supported version from which an in-place update to this machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  updateStrategy: minor
+  versions:
+  - architectures:
+    - amd64
+    - arm64
+    classification: preview
+    cri:
+    - containerRuntimes:
+      - type: gvisor
+      name: containerd
+    version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+Validations are in place to restrict any further updates when the current update is going on.
+For the cases where in-place update fails and the nodes are in problematic state, it requires user intervention to fix the node manually . After the fix user should be able to restart the update by the force update annotation `gardener.cloud/operation=force-in-place-update`. Without this annotation, any subsequent updates to the same worker pool are denied, refer [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) on how to force an update for worker pools.
+
+At present it is not allowed to change the update strategy of a worker from AutoRollingUpdate to Auto/Manual in-place update. Same applies for the other way round as well that is once the update strategy is selected as Auto/Manual in-place update , it cannot be changed to AutoRolling update. Though switching between Auto and Manual auto in-place update is allowed. 
+
+#### AutoInPlaceUpdate
+
+In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by the MCM and gardener without user intervention. Use `updateStrategy` as `AutoInPlaceUpdate` in worker for auto in-place update.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: use `machine-controller-manager` everywhere instead of MCM
created_at: 2025-05-13T11:09:46Z
author_association: MEMBER
diff_hunk: @@ -109,6 +133,113 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For the scenarios where user would like to keep the current node and avoid deletion of such nodes even after the updates, Gardener comes with the option of `in-place` update. Currently `in-place` update is kept behind `InPlaceNodeUpdates` feature gate.
+
+Machine image version in the cloudprofile has the `inPlaceUpdates` field which contains the configuration for in-place updates. For an OS to support in-place update `inPlaceUpdates.supported` field should be set to true. Moreoever `inPlaceUpdates.minVersionForUpdate` specifies the minimum supported version from which an in-place update to this machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  updateStrategy: minor
+  versions:
+  - architectures:
+    - amd64
+    - arm64
+    classification: preview
+    cri:
+    - containerRuntimes:
+      - type: gvisor
+      name: containerd
+    version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+Validations are in place to restrict any further updates when the current update is going on.
+For the cases where in-place update fails and the nodes are in problematic state, it requires user intervention to fix the node manually . After the fix user should be able to restart the update by the force update annotation `gardener.cloud/operation=force-in-place-update`. Without this annotation, any subsequent updates to the same worker pool are denied, refer [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) on how to force an update for worker pools.
+
+At present it is not allowed to change the update strategy of a worker from AutoRollingUpdate to Auto/Manual in-place update. Same applies for the other way round as well that is once the update strategy is selected as Auto/Manual in-place update , it cannot be changed to AutoRolling update. Though switching between Auto and Manual auto in-place update is allowed. 
+
+#### AutoInPlaceUpdate
+
+In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by the MCM and gardener without user intervention. Use `updateStrategy` as `AutoInPlaceUpdate` in worker for auto in-place update.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: > Use `updateStrategy` as `AutoInPlaceUpdate` in worker for auto in-place update.

The update strategy should be set to `AutoInPlaceUpdate` in the worker spec.
created_at: 2025-05-13T11:10:19Z
author_association: MEMBER
diff_hunk: @@ -109,6 +133,113 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For the scenarios where user would like to keep the current node and avoid deletion of such nodes even after the updates, Gardener comes with the option of `in-place` update. Currently `in-place` update is kept behind `InPlaceNodeUpdates` feature gate.
+
+Machine image version in the cloudprofile has the `inPlaceUpdates` field which contains the configuration for in-place updates. For an OS to support in-place update `inPlaceUpdates.supported` field should be set to true. Moreoever `inPlaceUpdates.minVersionForUpdate` specifies the minimum supported version from which an in-place update to this machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  updateStrategy: minor
+  versions:
+  - architectures:
+    - amd64
+    - arm64
+    classification: preview
+    cri:
+    - containerRuntimes:
+      - type: gvisor
+      name: containerd
+    version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+Validations are in place to restrict any further updates when the current update is going on.
+For the cases where in-place update fails and the nodes are in problematic state, it requires user intervention to fix the node manually . After the fix user should be able to restart the update by the force update annotation `gardener.cloud/operation=force-in-place-update`. Without this annotation, any subsequent updates to the same worker pool are denied, refer [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) on how to force an update for worker pools.
+
+At present it is not allowed to change the update strategy of a worker from AutoRollingUpdate to Auto/Manual in-place update. Same applies for the other way round as well that is once the update strategy is selected as Auto/Manual in-place update , it cannot be changed to AutoRolling update. Though switching between Auto and Manual auto in-place update is allowed. 
+
+#### AutoInPlaceUpdate
+
+In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by the MCM and gardener without user intervention. Use `updateStrategy` as `AutoInPlaceUpdate` in worker for auto in-place update.
+
+```yaml
+spec:
+  provider:
+    type: <some-provider-name> # {aws,azure,gcp,...}
+    workers:
+      - name: cpu-worker
+        minimum: 5
+        maximum: 5
+        maxSurge: 0
+        maxUnavailable: 2
+        updateStrategy: AutoInPlaceUpdate
+        machine:
+          type: m5.large
+          image:
+            name: <some-image-name>
+            version: <some-image-version>
+          architecture: <some-cpu-architecture>
+        providerConfig: <some-machine-image-specific-configuration>
+```
+
+#### Customize Auto In-Place Update Behaviour of Shoot Worker Nodes
+
+The `.spec.provider.workers[]` list exposes two fields that you might configure based on your workload's needs: `maxSurge` and `maxUnavailable`.
+The same concepts [like in Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment) apply.
+Additionally, you might customize how the MCM is behaving. You can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+
+* `MachineInPlaceUpdateTimeout`:  Timeout (in duration) after which an in-place update is declared as failed.
+* `DisableHealthTimeout`: Boolean value if set to true, health timeout will be ignored, leading to machine never being declared as failed (default: `true` for in-place updates). 
+
+#### ManualInPlaceUpdate
+
+ManualInPlaceUpdate update strategy is useful in scenarios where user wants to control and orchestrate the update process. Here user has the option to select the particular node which needs to be updated at a time. In order to update a node, label the node with `node.machine.sapcloud.io/selected-for-update=true`. Once the node is labeled  with `node.machine.sapcloud.io/selected-for-update=true`, MCM will carry out the update process of the selected node.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: ```suggestion
`ManualInPlaceUpdate` update strategy is useful in scenarios where the user wants to control and orchestrate the update process. Here user has the option to select the particular node that needs to be updated at a time. To update a node, they should label the node with `node.machine.sapcloud.io/selected-for-update=true`.
```
created_at: 2025-05-13T11:11:38Z
author_association: MEMBER
diff_hunk: @@ -109,6 +133,113 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For the scenarios where user would like to keep the current node and avoid deletion of such nodes even after the updates, Gardener comes with the option of `in-place` update. Currently `in-place` update is kept behind `InPlaceNodeUpdates` feature gate.
+
+Machine image version in the cloudprofile has the `inPlaceUpdates` field which contains the configuration for in-place updates. For an OS to support in-place update `inPlaceUpdates.supported` field should be set to true. Moreoever `inPlaceUpdates.minVersionForUpdate` specifies the minimum supported version from which an in-place update to this machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  updateStrategy: minor
+  versions:
+  - architectures:
+    - amd64
+    - arm64
+    classification: preview
+    cri:
+    - containerRuntimes:
+      - type: gvisor
+      name: containerd
+    version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+Validations are in place to restrict any further updates when the current update is going on.
+For the cases where in-place update fails and the nodes are in problematic state, it requires user intervention to fix the node manually . After the fix user should be able to restart the update by the force update annotation `gardener.cloud/operation=force-in-place-update`. Without this annotation, any subsequent updates to the same worker pool are denied, refer [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) on how to force an update for worker pools.
+
+At present it is not allowed to change the update strategy of a worker from AutoRollingUpdate to Auto/Manual in-place update. Same applies for the other way round as well that is once the update strategy is selected as Auto/Manual in-place update , it cannot be changed to AutoRolling update. Though switching between Auto and Manual auto in-place update is allowed. 
+
+#### AutoInPlaceUpdate
+
+In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by the MCM and gardener without user intervention. Use `updateStrategy` as `AutoInPlaceUpdate` in worker for auto in-place update.
+
+```yaml
+spec:
+  provider:
+    type: <some-provider-name> # {aws,azure,gcp,...}
+    workers:
+      - name: cpu-worker
+        minimum: 5
+        maximum: 5
+        maxSurge: 0
+        maxUnavailable: 2
+        updateStrategy: AutoInPlaceUpdate
+        machine:
+          type: m5.large
+          image:
+            name: <some-image-name>
+            version: <some-image-version>
+          architecture: <some-cpu-architecture>
+        providerConfig: <some-machine-image-specific-configuration>
+```
+
+#### Customize Auto In-Place Update Behaviour of Shoot Worker Nodes
+
+The `.spec.provider.workers[]` list exposes two fields that you might configure based on your workload's needs: `maxSurge` and `maxUnavailable`.
+The same concepts [like in Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment) apply.
+Additionally, you might customize how the MCM is behaving. You can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+
+* `MachineInPlaceUpdateTimeout`:  Timeout (in duration) after which an in-place update is declared as failed.
+* `DisableHealthTimeout`: Boolean value if set to true, health timeout will be ignored, leading to machine never being declared as failed (default: `true` for in-place updates). 
+
+#### ManualInPlaceUpdate
+
+ManualInPlaceUpdate update strategy is useful in scenarios where user wants to control and orchestrate the update process. Here user has the option to select the particular node which needs to be updated at a time. In order to update a node, label the node with `node.machine.sapcloud.io/selected-for-update=true`. Once the node is labeled  with `node.machine.sapcloud.io/selected-for-update=true`, MCM will carry out the update process of the selected node.
+
+`ManualInPlaceWorkersUpdated` [constraint](../shoot/shoot_status.md/#constraints) in shoot status indicates that at least one worker pool with the update strategy `ManualInPlaceUpdate` is pending an update. Shoot reconciliation succeeds even with worker pools pending for an update.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: Talk about the shoot status field as well
created_at: 2025-05-13T11:11:58Z
author_association: MEMBER
diff_hunk: @@ -142,6 +142,13 @@ You can check which worker pools still need to be rolled by reading `.status.cre
 Once this list is empty, the `phase` transitions to `Prepared`.
 Now you can just complete the rotation as usual (see above).
 
+#### Worker Node with ManualInPlaceUpdate Update Strategy
+
+In case of manual in-place update, shoot CA rotation phase will be at `Preparing` until all the worker pools are successfully in-place updated and there are no pending worker pools with strategy ManualInPlaceUpdate.
+
+You can check which worker pools still need to be updated by reading `.status.inPlaceUpdates.PendingWorkerUpdates.ManualInPlaceUpdate`.
+Once this list is empty, the `phase` transitions to `Prepared`.After this rotation will be completed as usual (see above).
path: docs/usage/shoot-operations/shoot_credentials_rotation.md
user: login: acumino
body: ```suggestion
Once this list is empty, the `phase` transitions to `Prepared`. After this rotation will be completed as usual (see above).
```
```suggestion
Once this list is empty, the `phase` transitions to `Prepared`. After this rotation will be completed as usual (see above).
```
created_at: 2025-05-16T10:55:59Z
author_association: MEMBER
diff_hunk: @@ -272,6 +279,11 @@ Similar to the rotation of the certificate authorities, you can control the work
 Please read [this section](#triggering-worker-node-rollout-individually) to get more information.
 It works the same way for the `ServiceAccount` token signing key (using `rotate-serviceaccount-key-start-without-workers-rollout`).
 
+#### Worker Node with ManualInPlaceUpdate Update Strategy
+
+Similar to the rotation of the certificate authorities, in case of manual in-place update, `ServiceAccount` token signing key rotation phase will be at `Preparing` until all the worker pools are successfully in-place updated and there are no pending worker pools with strategy ManualInPlaceUpdate.
+Please read [this section](#worker-node-with-manualinplaceupdate-update-strategy) to get more information.
path: docs/usage/shoot-operations/shoot_credentials_rotation.md
user: login: acumino
body: ```suggestion
Please read [this section](#worker-node-with-manualinplaceupdate-update-strategy) for more information.
```
created_at: 2025-05-16T10:58:05Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,52 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+`UpdateStrategy` field under shoot worker enables the end user to choose between different behaviour of machine-controller-manager (abbrev.: MCM; the component instrumenting this rolling update) during the upgrade process. Currently gardener support three update strategies:
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: Put the correct path here.
```suggestion
`UpdateStrategy` field under shoot worker `.spec.provider.workers[].updateStrategy` enables the end user to choose between different behaviour of machine-controller-manager (abbrev.: MCM; the component instrumenting this rolling update) during the upgrade process. Currently gardener support three update strategies:
```
created_at: 2025-05-16T11:01:48Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,52 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+`UpdateStrategy` field under shoot worker enables the end user to choose between different behaviour of machine-controller-manager (abbrev.: MCM; the component instrumenting this rolling update) during the upgrade process. Currently gardener support three update strategies:
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: ```suggestion
`UpdateStrategy` field under shoot worker enables the end user to choose between different behaviour of machine-controller-manager (abbrev.: MCM; the component instrumenting this update) during the upgrade process. Currently gardener support three update strategies:
```
created_at: 2025-05-16T11:04:17Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,52 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+`UpdateStrategy` field under shoot worker enables the end user to choose between different behaviour of machine-controller-manager (abbrev.: MCM; the component instrumenting this rolling update) during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+### In-Place vs. Rolling Updates
 
-If the Kubernetes minor version is changed, then the upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).
-The worker nodes will be terminated one after another and replaced by new machines.
-The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+- During an in-place update, worker nodes are updated without replacing the underlying machines.
+- The shoot worker nodes remain intact and are not recreated.
+- Some downtime is expected as the node needs to be drained, and workloads are rescheduled once the update is complete.
+- In certain scenarios, updates can be performed without draining the node:
+  - When the Kubernetes patch version is updated, the upgrade is executed without draining the node. In this case, the shoot worker nodes remain unchanged, and only the `kubelet` process is restarted with the updated Kubernetes version binary.
+  - Similarly, configuration changes to the `kubelet` are applied without draining the node.
+
+- In case of rolling update, upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).
+- The worker nodes will be terminated one after another and replaced by new machines.
+- The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+
+### AutoRollingUpdate
+
+When the auto rolling update strategy is selected, the upgrade is performed in a "rolling update" manner. The machine-controller-manager sequentially terminates the worker nodes and replaces them with new machines. This is the default update strategy. To create workers with `AutoRollingUpdate`, either omit the `workers.updateStrategy` field (it will default to `AutoInPlaceUpdate`) or explicitly set the field to `AutoInPlaceUpdate` for each worker.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: ```suggestion
When the auto rolling update strategy is selected, the upgrade is performed in a "rolling update" manner. The machine-controller-manager sequentially terminates the worker nodes and replaces them with new nodes. This is the default update strategy. To create workers with `AutoRollingUpdate`, either omit the `workers.updateStrategy` field (it will default to `AutoRollingUpdate `) or explicitly set the field to `AutoRollingUpdate ` for each worker.
```
created_at: 2025-05-16T15:04:48Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,52 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+`UpdateStrategy` field under shoot worker enables the end user to choose between different behaviour of machine-controller-manager (abbrev.: MCM; the component instrumenting this rolling update) during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+### In-Place vs. Rolling Updates
 
-If the Kubernetes minor version is changed, then the upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).
-The worker nodes will be terminated one after another and replaced by new machines.
-The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+- During an in-place update, worker nodes are updated without replacing the underlying machines.
+- The shoot worker nodes remain intact and are not recreated.
+- Some downtime is expected as the node needs to be drained, and workloads are rescheduled once the update is complete.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: Write the drain part here also same as  rolling update.
created_at: 2025-05-16T15:10:43Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,52 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+`UpdateStrategy` field under shoot worker enables the end user to choose between different behaviour of machine-controller-manager (abbrev.: MCM; the component instrumenting this rolling update) during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+### In-Place vs. Rolling Updates
 
-If the Kubernetes minor version is changed, then the upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).
-The worker nodes will be terminated one after another and replaced by new machines.
-The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+- During an in-place update, worker nodes are updated without replacing the underlying machines.
+- The shoot worker nodes remain intact and are not recreated.
+- Some downtime is expected as the node needs to be drained, and workloads are rescheduled once the update is complete.
+- In certain scenarios, updates can be performed without draining the node:
+  - When the Kubernetes patch version is updated, the upgrade is executed without draining the node. In this case, the shoot worker nodes remain unchanged, and only the `kubelet` process is restarted with the updated Kubernetes version binary.
+  - Similarly, configuration changes to the `kubelet` are applied without draining the node.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: I don't think this line is true - see [here](https://github.com/gardener/gardener/blob/a7d4bc2bde28e5ccc69ca5bc1af01e75c2d04ea2/extensions/pkg/controller/worker/machines.go#L173-L206).
created_at: 2025-05-16T15:16:56Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,52 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+`UpdateStrategy` field under shoot worker enables the end user to choose between different behaviour of machine-controller-manager (abbrev.: MCM; the component instrumenting this rolling update) during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+### In-Place vs. Rolling Updates
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: The flow look hard to read, may be put sub heading or something else.
created_at: 2025-05-16T15:18:10Z
author_association: MEMBER
diff_hunk: @@ -109,6 +140,127 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For scenarios where users want to retain the current nodes and avoid their deletion during updates, Gardener provides the option of `in-place` updates. Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate.
+
+The machine image version in the `cloudprofile` includes the `inPlaceUpdates` field, which defines the configuration for in-place updates. For an operating system to support in-place updates:
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: Something like
```suggestion
For in-place updates, the first requirement is that the operating system must support them. For a specific machine image version, the configuration for in-place updates must be defined in the `CloudProfile` under spec.machineImages[].inPlaceUpdates:
```
created_at: 2025-05-16T15:50:31Z
author_association: MEMBER
diff_hunk: @@ -109,6 +140,127 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For scenarios where users want to retain the current nodes and avoid their deletion during updates, Gardener provides the option of `in-place` updates. Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate.
+
+The machine image version in the `cloudprofile` includes the `inPlaceUpdates` field, which defines the configuration for in-place updates. For an operating system to support in-place updates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  updateStrategy: minor
+  versions:
+  - architectures:
+    - amd64
+    - arm64
+    classification: preview
+    cri:
+    - containerRuntimes:
+      - type: gvisor
+      name: containerd
+    version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+When a worker pool is undergoing an in-place update, applying subsequent updates to the same worker pool is restricted.
+If an in-place update fails and nodes are left in a problematic state, user intervention is required to manually fix the nodes. After resolving the issue, users can restart the update by adding the force update annotation `gardener.cloud/operation=force-in-place-update`.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: ```suggestion
If an in-place update fails and nodes are left in a problematic state, user intervention is required to manually fix the nodes. In cases where a subsequent update is necessary to resolve the issue, users can update the worker pool after adding the force update annotation `gardener.cloud/operation=force-in-place-update` on the Shoot.
```
created_at: 2025-05-16T16:00:58Z
author_association: MEMBER
diff_hunk: @@ -109,6 +140,127 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For scenarios where users want to retain the current nodes and avoid their deletion during updates, Gardener provides the option of `in-place` updates. Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate.
+
+The machine image version in the `cloudprofile` includes the `inPlaceUpdates` field, which defines the configuration for in-place updates. For an operating system to support in-place updates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  updateStrategy: minor
+  versions:
+  - architectures:
+    - amd64
+    - arm64
+    classification: preview
+    cri:
+    - containerRuntimes:
+      - type: gvisor
+      name: containerd
+    version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+When a worker pool is undergoing an in-place update, applying subsequent updates to the same worker pool is restricted.
+If an in-place update fails and nodes are left in a problematic state, user intervention is required to manually fix the nodes. After resolving the issue, users can restart the update by adding the force update annotation `gardener.cloud/operation=force-in-place-update`.
+
+Without this annotation, subsequent updates to the same worker pool are denied. Refer to [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) for more details.
+
+> ⚠️ Changing the update strategy from `AutoRollingUpdate` to `AutoInPlaceUpdate` or `ManualInPlaceUpdate` (and vice versa) is not allowed. However, switching between `AutoInPlaceUpdate` and `ManualInPlaceUpdate` is permitted.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: ```suggestion
> ⚠️ Changing the update strategy from `AutoRollingUpdate` to `AutoInPlaceUpdate`/`ManualInPlaceUpdate` (and vice versa) is not allowed. However, switching between `AutoInPlaceUpdate` and `ManualInPlaceUpdate` is permitted.
```
created_at: 2025-05-16T16:04:18Z
author_association: MEMBER
diff_hunk: @@ -109,6 +140,127 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For scenarios where users want to retain the current nodes and avoid their deletion during updates, Gardener provides the option of `in-place` updates. Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate.
+
+The machine image version in the `cloudprofile` includes the `inPlaceUpdates` field, which defines the configuration for in-place updates. For an operating system to support in-place updates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  updateStrategy: minor
+  versions:
+  - architectures:
+    - amd64
+    - arm64
+    classification: preview
+    cri:
+    - containerRuntimes:
+      - type: gvisor
+      name: containerd
+    version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+When a worker pool is undergoing an in-place update, applying subsequent updates to the same worker pool is restricted.
+If an in-place update fails and nodes are left in a problematic state, user intervention is required to manually fix the nodes. After resolving the issue, users can restart the update by adding the force update annotation `gardener.cloud/operation=force-in-place-update`.
+
+Without this annotation, subsequent updates to the same worker pool are denied. Refer to [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) for more details.
+
+> ⚠️ Changing the update strategy from `AutoRollingUpdate` to `AutoInPlaceUpdate` or `ManualInPlaceUpdate` (and vice versa) is not allowed. However, switching between `AutoInPlaceUpdate` and `ManualInPlaceUpdate` is permitted.
+
+#### AutoInPlaceUpdate
+
+In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by Gardener and the machine-controller-manager. No user intervention is required.The update strategy should be set to `AutoInPlaceUpdate` in the worker spec.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: ```suggestion
In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by Gardener and the machine-controller-manager. No user intervention is required. The update strategy should be set to `AutoInPlaceUpdate` in the Shoot spec under `.spec.provider.workers[].updateStrategy.
```
created_at: 2025-05-16T16:06:37Z
author_association: MEMBER
diff_hunk: @@ -109,6 +140,127 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For scenarios where users want to retain the current nodes and avoid their deletion during updates, Gardener provides the option of `in-place` updates. Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate.
+
+The machine image version in the `cloudprofile` includes the `inPlaceUpdates` field, which defines the configuration for in-place updates. For an operating system to support in-place updates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  updateStrategy: minor
+  versions:
+  - architectures:
+    - amd64
+    - arm64
+    classification: preview
+    cri:
+    - containerRuntimes:
+      - type: gvisor
+      name: containerd
+    version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+When a worker pool is undergoing an in-place update, applying subsequent updates to the same worker pool is restricted.
+If an in-place update fails and nodes are left in a problematic state, user intervention is required to manually fix the nodes. After resolving the issue, users can restart the update by adding the force update annotation `gardener.cloud/operation=force-in-place-update`.
+
+Without this annotation, subsequent updates to the same worker pool are denied. Refer to [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) for more details.
+
+> ⚠️ Changing the update strategy from `AutoRollingUpdate` to `AutoInPlaceUpdate` or `ManualInPlaceUpdate` (and vice versa) is not allowed. However, switching between `AutoInPlaceUpdate` and `ManualInPlaceUpdate` is permitted.
+
+#### AutoInPlaceUpdate
+
+In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by Gardener and the machine-controller-manager. No user intervention is required.The update strategy should be set to `AutoInPlaceUpdate` in the worker spec.
+
+The `inPlaceUpdates.pendingWorkerUpdates.autoInPlaceUpdate` field in the Shoot status lists the names of worker pools that are pending updates with the `AutoInPlaceUpdate` strategy.
+
+```yaml
+spec:
+  provider:
+    type: <some-provider-name>
+    workers:
+      - name: cpu-worker
+        minimum: 5
+        maximum: 5
+        maxSurge: 0
+        maxUnavailable: 2
+        updateStrategy: AutoInPlaceUpdate
+        machine:
+          type: m5.large
+          image:
+            name: <some-image-name>
+            version: <some-image-version>
+          architecture: <some-cpu-architecture>
+        providerConfig: <some-machine-image-specific-configuration>
+```
+
+#### Customize Auto In-Place Update Behaviour of Shoot Worker Nodes
+
+The `.spec.provider.workers[]` list exposes two fields that you might configure based on your workload's needs: `maxSurge` and `maxUnavailable`.
+The same concepts [like in Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment) apply.
+Additionally, you might customize how the machine-controller-manager is behaving. You can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: Refer here the list of other MCM configuration which is listed for AutoRollingUpdate.
created_at: 2025-05-16T16:09:48Z
author_association: MEMBER
diff_hunk: @@ -109,6 +140,127 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For scenarios where users want to retain the current nodes and avoid their deletion during updates, Gardener provides the option of `in-place` updates. Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate.
+
+The machine image version in the `cloudprofile` includes the `inPlaceUpdates` field, which defines the configuration for in-place updates. For an operating system to support in-place updates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  updateStrategy: minor
+  versions:
+  - architectures:
+    - amd64
+    - arm64
+    classification: preview
+    cri:
+    - containerRuntimes:
+      - type: gvisor
+      name: containerd
+    version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+When a worker pool is undergoing an in-place update, applying subsequent updates to the same worker pool is restricted.
+If an in-place update fails and nodes are left in a problematic state, user intervention is required to manually fix the nodes. After resolving the issue, users can restart the update by adding the force update annotation `gardener.cloud/operation=force-in-place-update`.
+
+Without this annotation, subsequent updates to the same worker pool are denied. Refer to [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) for more details.
+
+> ⚠️ Changing the update strategy from `AutoRollingUpdate` to `AutoInPlaceUpdate` or `ManualInPlaceUpdate` (and vice versa) is not allowed. However, switching between `AutoInPlaceUpdate` and `ManualInPlaceUpdate` is permitted.
+
+#### AutoInPlaceUpdate
+
+In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by Gardener and the machine-controller-manager. No user intervention is required.The update strategy should be set to `AutoInPlaceUpdate` in the worker spec.
+
+The `inPlaceUpdates.pendingWorkerUpdates.autoInPlaceUpdate` field in the Shoot status lists the names of worker pools that are pending updates with the `AutoInPlaceUpdate` strategy.
+
+```yaml
+spec:
+  provider:
+    type: <some-provider-name>
+    workers:
+      - name: cpu-worker
+        minimum: 5
+        maximum: 5
+        maxSurge: 0
+        maxUnavailable: 2
+        updateStrategy: AutoInPlaceUpdate
+        machine:
+          type: m5.large
+          image:
+            name: <some-image-name>
+            version: <some-image-version>
+          architecture: <some-cpu-architecture>
+        providerConfig: <some-machine-image-specific-configuration>
+```
+
+#### Customize Auto In-Place Update Behaviour of Shoot Worker Nodes
+
+The `.spec.provider.workers[]` list exposes two fields that you might configure based on your workload's needs: `maxSurge` and `maxUnavailable`.
+The same concepts [like in Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment) apply.
+Additionally, you might customize how the machine-controller-manager is behaving. You can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+
+* `MachineInPlaceUpdateTimeout`:  Timeout (in duration) after which an in-place update is declared as failed.
+* `DisableHealthTimeout`: Boolean value if set to true, health timeout will be ignored, leading to machine never being declared as failed (default: `true` for in-place updates). 
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: ```suggestion
* `DisableHealthTimeout`: Boolean value if set to true, health timeout will be ignored. As a result, the machine is never marked as failed, and unhealthy machines are not deleted (default: `true` for in-place updates). 
```
created_at: 2025-05-16T16:15:26Z
author_association: MEMBER
diff_hunk: @@ -109,6 +140,127 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For scenarios where users want to retain the current nodes and avoid their deletion during updates, Gardener provides the option of `in-place` updates. Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate.
+
+The machine image version in the `cloudprofile` includes the `inPlaceUpdates` field, which defines the configuration for in-place updates. For an operating system to support in-place updates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  updateStrategy: minor
+  versions:
+  - architectures:
+    - amd64
+    - arm64
+    classification: preview
+    cri:
+    - containerRuntimes:
+      - type: gvisor
+      name: containerd
+    version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+When a worker pool is undergoing an in-place update, applying subsequent updates to the same worker pool is restricted.
+If an in-place update fails and nodes are left in a problematic state, user intervention is required to manually fix the nodes. After resolving the issue, users can restart the update by adding the force update annotation `gardener.cloud/operation=force-in-place-update`.
+
+Without this annotation, subsequent updates to the same worker pool are denied. Refer to [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) for more details.
+
+> ⚠️ Changing the update strategy from `AutoRollingUpdate` to `AutoInPlaceUpdate` or `ManualInPlaceUpdate` (and vice versa) is not allowed. However, switching between `AutoInPlaceUpdate` and `ManualInPlaceUpdate` is permitted.
+
+#### AutoInPlaceUpdate
+
+In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by Gardener and the machine-controller-manager. No user intervention is required.The update strategy should be set to `AutoInPlaceUpdate` in the worker spec.
+
+The `inPlaceUpdates.pendingWorkerUpdates.autoInPlaceUpdate` field in the Shoot status lists the names of worker pools that are pending updates with the `AutoInPlaceUpdate` strategy.
+
+```yaml
+spec:
+  provider:
+    type: <some-provider-name>
+    workers:
+      - name: cpu-worker
+        minimum: 5
+        maximum: 5
+        maxSurge: 0
+        maxUnavailable: 2
+        updateStrategy: AutoInPlaceUpdate
+        machine:
+          type: m5.large
+          image:
+            name: <some-image-name>
+            version: <some-image-version>
+          architecture: <some-cpu-architecture>
+        providerConfig: <some-machine-image-specific-configuration>
+```
+
+#### Customize Auto In-Place Update Behaviour of Shoot Worker Nodes
+
+The `.spec.provider.workers[]` list exposes two fields that you might configure based on your workload's needs: `maxSurge` and `maxUnavailable`.
+The same concepts [like in Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment) apply.
+Additionally, you might customize how the machine-controller-manager is behaving. You can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+
+* `MachineInPlaceUpdateTimeout`:  Timeout (in duration) after which an in-place update is declared as failed.
+* `DisableHealthTimeout`: Boolean value if set to true, health timeout will be ignored, leading to machine never being declared as failed (default: `true` for in-place updates). 
+
+#### ManualInPlaceUpdate
+
+The `ManualInPlaceUpdate` strategy allows users to control and orchestrate the update process manually. Users can select specific nodes for updates by labeling them with:
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: Mention user should only select nodes which have candidate for update lable.
created_at: 2025-05-16T16:16:41Z
author_association: MEMBER
diff_hunk: @@ -109,6 +140,127 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For scenarios where users want to retain the current nodes and avoid their deletion during updates, Gardener provides the option of `in-place` updates. Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate.
+
+The machine image version in the `cloudprofile` includes the `inPlaceUpdates` field, which defines the configuration for in-place updates. For an operating system to support in-place updates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  updateStrategy: minor
+  versions:
+  - architectures:
+    - amd64
+    - arm64
+    classification: preview
+    cri:
+    - containerRuntimes:
+      - type: gvisor
+      name: containerd
+    version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+When a worker pool is undergoing an in-place update, applying subsequent updates to the same worker pool is restricted.
+If an in-place update fails and nodes are left in a problematic state, user intervention is required to manually fix the nodes. After resolving the issue, users can restart the update by adding the force update annotation `gardener.cloud/operation=force-in-place-update`.
+
+Without this annotation, subsequent updates to the same worker pool are denied. Refer to [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) for more details.
+
+> ⚠️ Changing the update strategy from `AutoRollingUpdate` to `AutoInPlaceUpdate` or `ManualInPlaceUpdate` (and vice versa) is not allowed. However, switching between `AutoInPlaceUpdate` and `ManualInPlaceUpdate` is permitted.
+
+#### AutoInPlaceUpdate
+
+In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by Gardener and the machine-controller-manager. No user intervention is required.The update strategy should be set to `AutoInPlaceUpdate` in the worker spec.
+
+The `inPlaceUpdates.pendingWorkerUpdates.autoInPlaceUpdate` field in the Shoot status lists the names of worker pools that are pending updates with the `AutoInPlaceUpdate` strategy.
+
+```yaml
+spec:
+  provider:
+    type: <some-provider-name>
+    workers:
+      - name: cpu-worker
+        minimum: 5
+        maximum: 5
+        maxSurge: 0
+        maxUnavailable: 2
+        updateStrategy: AutoInPlaceUpdate
+        machine:
+          type: m5.large
+          image:
+            name: <some-image-name>
+            version: <some-image-version>
+          architecture: <some-cpu-architecture>
+        providerConfig: <some-machine-image-specific-configuration>
+```
+
+#### Customize Auto In-Place Update Behaviour of Shoot Worker Nodes
+
+The `.spec.provider.workers[]` list exposes two fields that you might configure based on your workload's needs: `maxSurge` and `maxUnavailable`.
+The same concepts [like in Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment) apply.
+Additionally, you might customize how the machine-controller-manager is behaving. You can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+
+* `MachineInPlaceUpdateTimeout`:  Timeout (in duration) after which an in-place update is declared as failed.
+* `DisableHealthTimeout`: Boolean value if set to true, health timeout will be ignored, leading to machine never being declared as failed (default: `true` for in-place updates). 
+
+#### ManualInPlaceUpdate
+
+The `ManualInPlaceUpdate` strategy allows users to control and orchestrate the update process manually. Users can select specific nodes for updates by labeling them with:
+`node.machine.sapcloud.io/selected-for-update=true.` Once labeled, the machine-controller-manager updates the selected node.
+The update strategy should be set to `ManualInPlaceUpdate` in the worker spec.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: ```suggestion
The update strategy should be set to `ManualInPlaceUpdate` in the Shoot spec.
```
created_at: 2025-05-16T16:17:07Z
author_association: MEMBER
diff_hunk: @@ -142,6 +142,13 @@ You can check which worker pools still need to be rolled by reading `.status.cre
 Once this list is empty, the `phase` transitions to `Prepared`.
 Now you can just complete the rotation as usual (see above).
 
+#### Worker Node with ManualInPlaceUpdate Update Strategy
+
+In case of manual in-place update, shoot CA rotation phase will be at `Preparing` until all the worker pools are successfully in-place updated and there are no pending worker pools with strategy ManualInPlaceUpdate.
+
+You can check which worker pools still need to be updated by reading `.status.inPlaceUpdates.PendingWorkerUpdates.ManualInPlaceUpdate`.
path: docs/usage/shoot-operations/shoot_credentials_rotation.md
user: login: rfranzke
body: ```suggestion
You can check which worker pools still need to be updated by reading `.status.inPlaceUpdates.pendingWorkerUpdates.manualInPlaceUpdate`.
```
created_at: 2025-05-22T05:27:17Z
author_association: MEMBER
diff_hunk: @@ -142,6 +142,13 @@ You can check which worker pools still need to be rolled by reading `.status.cre
 Once this list is empty, the `phase` transitions to `Prepared`.
 Now you can just complete the rotation as usual (see above).
 
+#### Worker Node with ManualInPlaceUpdate Update Strategy
+
+In case of manual in-place update, shoot CA rotation phase will be at `Preparing` until all the worker pools are successfully in-place updated and there are no pending worker pools with strategy ManualInPlaceUpdate.
+
+You can check which worker pools still need to be updated by reading `.status.inPlaceUpdates.PendingWorkerUpdates.ManualInPlaceUpdate`.
+Once this list is empty, the `phase` transitions to `Prepared`. After this rotation will be completed as usual (see above).
path: docs/usage/shoot-operations/shoot_credentials_rotation.md
user: login: rfranzke
body: ```suggestion
Once this list is empty, the `phase` transitions to `Prepared`.
After this, rotation will be completed as usual (see above).
```

generally: one line per sentence
created_at: 2025-05-22T05:27:31Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,44 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
+The `UpdateStrategy` field in the Shoot specification (`.spec.provider.workers[].updateStrategy`) gives users the flexibility to define how the `machine-controller-manager`(MCM) handles worker pool updates during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
+
 ### In-Place vs. Rolling Updates
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+#### In-Place Updates
path: docs/usage/shoot-operations/shoot_updates.md
user: login: rfranzke
body: newline after headers
```suggestion
#### In-Place Updates

```
created_at: 2025-05-22T05:27:55Z
author_association: MEMBER
diff_hunk: @@ -109,6 +132,91 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
path: docs/usage/shoot-operations/shoot_updates.md
user: login: rfranzke
body: ```suggestion
### In-Place Updates
```
created_at: 2025-05-22T05:28:15Z
author_association: MEMBER
diff_hunk: @@ -109,6 +132,91 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For scenarios where users want to retain the current nodes and avoid their deletion during updates, Gardener provides the option of `in-place` updates. Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate.
+
+For in-place updates, the first requirement is that the operating system must support them. For a specific machine image version, the configuration for in-place updates must be defined in the `CloudProfile` under spec.machineImages[].inPlaceUpdates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  versions:
+  - version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### Customize In-Place Update Behaviour of Shoot Worker Nodes
+
+In addition to customisable fields mentioned in [](#customize-rolling-update-behaviour-of-shoot-worker-nodes) section, you can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+
+* `MachineInPlaceUpdateTimeout`:  Timeout (in duration) after which an in-place update is declared as failed.
+* `DisableHealthTimeout`: A boolean value that, when set to `true`, ignores the health timeout. As a result, machines are never marked as failed, and unhealthy machines are not deleted. The default value is `true` for in-place updates.
+
+#### InPlace Update Triggers
path: docs/usage/shoot-operations/shoot_updates.md
user: login: rfranzke
body: ```suggestion
#### In-Place Update Triggers
```
created_at: 2025-05-22T05:28:29Z
author_association: MEMBER
diff_hunk: @@ -109,6 +132,91 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For scenarios where users want to retain the current nodes and avoid their deletion during updates, Gardener provides the option of `in-place` updates. Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate.
+
+For in-place updates, the first requirement is that the operating system must support them. For a specific machine image version, the configuration for in-place updates must be defined in the `CloudProfile` under spec.machineImages[].inPlaceUpdates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  versions:
+  - version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### Customize In-Place Update Behaviour of Shoot Worker Nodes
+
+In addition to customisable fields mentioned in [](#customize-rolling-update-behaviour-of-shoot-worker-nodes) section, you can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+
+* `MachineInPlaceUpdateTimeout`:  Timeout (in duration) after which an in-place update is declared as failed.
+* `DisableHealthTimeout`: A boolean value that, when set to `true`, ignores the health timeout. As a result, machines are never marked as failed, and unhealthy machines are not deleted. The default value is `true` for in-place updates.
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+When a worker pool is undergoing an in-place update, applying subsequent updates to the same worker pool is restricted.
+If an in-place update fails and nodes are left in a problematic state, user intervention is required to manually fix the nodes. In cases where a subsequent update is necessary to resolve the issue, users can update the worker pool after adding the force update annotation `gardener.cloud/operation=force-in-place-update` on the Shoot.
+
+Without this annotation, subsequent updates to the same worker pool are denied. Refer to [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) for more details.
+
+> ⚠️ Changing the update strategy from `AutoRollingUpdate` to `AutoInPlaceUpdate`/`ManualInPlaceUpdate` (and vice versa) is not allowed. However, switching between `AutoInPlaceUpdate` and `ManualInPlaceUpdate` is permitted.
+
+#### AutoInPlaceUpdate
path: docs/usage/shoot-operations/shoot_updates.md
user: login: rfranzke
body: ```suggestion
#### Automatic In-Place Updates
```
created_at: 2025-05-22T05:28:41Z
author_association: MEMBER
diff_hunk: @@ -109,6 +132,91 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For scenarios where users want to retain the current nodes and avoid their deletion during updates, Gardener provides the option of `in-place` updates. Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate.
+
+For in-place updates, the first requirement is that the operating system must support them. For a specific machine image version, the configuration for in-place updates must be defined in the `CloudProfile` under spec.machineImages[].inPlaceUpdates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  versions:
+  - version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### Customize In-Place Update Behaviour of Shoot Worker Nodes
+
+In addition to customisable fields mentioned in [](#customize-rolling-update-behaviour-of-shoot-worker-nodes) section, you can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+
+* `MachineInPlaceUpdateTimeout`:  Timeout (in duration) after which an in-place update is declared as failed.
+* `DisableHealthTimeout`: A boolean value that, when set to `true`, ignores the health timeout. As a result, machines are never marked as failed, and unhealthy machines are not deleted. The default value is `true` for in-place updates.
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+When a worker pool is undergoing an in-place update, applying subsequent updates to the same worker pool is restricted.
+If an in-place update fails and nodes are left in a problematic state, user intervention is required to manually fix the nodes. In cases where a subsequent update is necessary to resolve the issue, users can update the worker pool after adding the force update annotation `gardener.cloud/operation=force-in-place-update` on the Shoot.
+
+Without this annotation, subsequent updates to the same worker pool are denied. Refer to [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) for more details.
+
+> ⚠️ Changing the update strategy from `AutoRollingUpdate` to `AutoInPlaceUpdate`/`ManualInPlaceUpdate` (and vice versa) is not allowed. However, switching between `AutoInPlaceUpdate` and `ManualInPlaceUpdate` is permitted.
+
+#### AutoInPlaceUpdate
+
+In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by Gardener and the machine-controller-manager. No user intervention is required.  Set `.spec.provider.workers[].updateStrategy` field in the `Shoot` spec to `AutoInPlaceUpdate`.
+
+The `inPlaceUpdates.pendingWorkerUpdates.autoInPlaceUpdate` field in the Shoot status lists the names of worker pools that are pending updates with the `AutoInPlaceUpdate` strategy.
+
+```yaml
+spec:
+  provider:
+    workers:
+      - name: cpu-worker
+        maxSurge: 0
+        maxUnavailable: 2
+        updateStrategy: AutoInPlaceUpdate
+```
+
+#### ManualInPlaceUpdate
path: docs/usage/shoot-operations/shoot_updates.md
user: login: rfranzke
body: ```suggestion
#### Manual In-Place Updates
```
created_at: 2025-05-22T05:28:50Z
author_association: MEMBER
diff_hunk: @@ -109,6 +132,91 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For scenarios where users want to retain the current nodes and avoid their deletion during updates, Gardener provides the option of `in-place` updates. Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate.
+
+For in-place updates, the first requirement is that the operating system must support them. For a specific machine image version, the configuration for in-place updates must be defined in the `CloudProfile` under spec.machineImages[].inPlaceUpdates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  versions:
+  - version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### Customize In-Place Update Behaviour of Shoot Worker Nodes
+
+In addition to customisable fields mentioned in [](#customize-rolling-update-behaviour-of-shoot-worker-nodes) section, you can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+
+* `MachineInPlaceUpdateTimeout`:  Timeout (in duration) after which an in-place update is declared as failed.
+* `DisableHealthTimeout`: A boolean value that, when set to `true`, ignores the health timeout. As a result, machines are never marked as failed, and unhealthy machines are not deleted. The default value is `true` for in-place updates.
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: Also mention that changing these fields while the in-place update strategies are configured is not allowed.
created_at: 2025-05-22T05:44:59Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,44 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
+The `UpdateStrategy` field in the Shoot specification (`.spec.provider.workers[].updateStrategy`) gives users the flexibility to define how the `machine-controller-manager`(MCM) handles worker pool updates during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
+
 ### In-Place vs. Rolling Updates
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+#### In-Place Updates
+- The upgrade is performed in a "rolling update" manner, without replacing the underlying machines.
+- The shoot worker nodes remain intact and are not recreated.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: Not true if `MaxSurge` is configured
created_at: 2025-05-22T05:45:45Z
author_association: MEMBER
diff_hunk: @@ -109,6 +132,91 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For scenarios where users want to retain the current nodes and avoid their deletion during updates, Gardener provides the option of `in-place` updates. Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate.
+
+For in-place updates, the first requirement is that the operating system must support them. For a specific machine image version, the configuration for in-place updates must be defined in the `CloudProfile` under spec.machineImages[].inPlaceUpdates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  versions:
+  - version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### Customize In-Place Update Behaviour of Shoot Worker Nodes
+
+In addition to customisable fields mentioned in [](#customize-rolling-update-behaviour-of-shoot-worker-nodes) section, you can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+
+* `MachineInPlaceUpdateTimeout`:  Timeout (in duration) after which an in-place update is declared as failed.
+* `DisableHealthTimeout`: A boolean value that, when set to `true`, ignores the health timeout. As a result, machines are never marked as failed, and unhealthy machines are not deleted. The default value is `true` for in-place updates.
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+When a worker pool is undergoing an in-place update, applying subsequent updates to the same worker pool is restricted.
+If an in-place update fails and nodes are left in a problematic state, user intervention is required to manually fix the nodes. In cases where a subsequent update is necessary to resolve the issue, users can update the worker pool after adding the force update annotation `gardener.cloud/operation=force-in-place-update` on the Shoot.
+
+Without this annotation, subsequent updates to the same worker pool are denied. Refer to [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) for more details.
+
+> ⚠️ Changing the update strategy from `AutoRollingUpdate` to `AutoInPlaceUpdate`/`ManualInPlaceUpdate` (and vice versa) is not allowed. However, switching between `AutoInPlaceUpdate` and `ManualInPlaceUpdate` is permitted.
+
+#### AutoInPlaceUpdate
+
+In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by Gardener and the machine-controller-manager. No user intervention is required.  Set `.spec.provider.workers[].updateStrategy` field in the `Shoot` spec to `AutoInPlaceUpdate`.
+
+The `inPlaceUpdates.pendingWorkerUpdates.autoInPlaceUpdate` field in the Shoot status lists the names of worker pools that are pending updates with the `AutoInPlaceUpdate` strategy.
+
+```yaml
+spec:
+  provider:
+    workers:
+      - name: cpu-worker
+        maxSurge: 0
+        maxUnavailable: 2
+        updateStrategy: AutoInPlaceUpdate
+```
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: Move this near to the part where you mention setting the shoot spec
created_at: 2025-05-22T05:47:59Z
author_association: MEMBER
diff_hunk: @@ -109,6 +132,91 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### InPlace updates
+
+For scenarios where users want to retain the current nodes and avoid their deletion during updates, Gardener provides the option of `in-place` updates. Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate.
+
+For in-place updates, the first requirement is that the operating system must support them. For a specific machine image version, the configuration for in-place updates must be defined in the `CloudProfile` under spec.machineImages[].inPlaceUpdates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  versions:
+  - version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### Customize In-Place Update Behaviour of Shoot Worker Nodes
+
+In addition to customisable fields mentioned in [](#customize-rolling-update-behaviour-of-shoot-worker-nodes) section, you can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+
+* `MachineInPlaceUpdateTimeout`:  Timeout (in duration) after which an in-place update is declared as failed.
+* `DisableHealthTimeout`: A boolean value that, when set to `true`, ignores the health timeout. As a result, machines are never marked as failed, and unhealthy machines are not deleted. The default value is `true` for in-place updates.
+
+#### InPlace Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+#### Validations for In-Place update
+
+When a worker pool is undergoing an in-place update, applying subsequent updates to the same worker pool is restricted.
+If an in-place update fails and nodes are left in a problematic state, user intervention is required to manually fix the nodes. In cases where a subsequent update is necessary to resolve the issue, users can update the worker pool after adding the force update annotation `gardener.cloud/operation=force-in-place-update` on the Shoot.
+
+Without this annotation, subsequent updates to the same worker pool are denied. Refer to [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) for more details.
+
+> ⚠️ Changing the update strategy from `AutoRollingUpdate` to `AutoInPlaceUpdate`/`ManualInPlaceUpdate` (and vice versa) is not allowed. However, switching between `AutoInPlaceUpdate` and `ManualInPlaceUpdate` is permitted.
+
+#### AutoInPlaceUpdate
+
+In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by Gardener and the machine-controller-manager. No user intervention is required.  Set `.spec.provider.workers[].updateStrategy` field in the `Shoot` spec to `AutoInPlaceUpdate`.
+
+The `inPlaceUpdates.pendingWorkerUpdates.autoInPlaceUpdate` field in the Shoot status lists the names of worker pools that are pending updates with the `AutoInPlaceUpdate` strategy.
+
+```yaml
+spec:
+  provider:
+    workers:
+      - name: cpu-worker
+        maxSurge: 0
+        maxUnavailable: 2
+        updateStrategy: AutoInPlaceUpdate
+```
+
+#### ManualInPlaceUpdate
+
+The `ManualInPlaceUpdate` strategy allows users to control and orchestrate the update process manually. Set `.spec.provider.workers[].updateStrategy` field in the `Shoot` spec to `ManualInPlaceUpdate`.
+
+Once machine-controller-manager labels nodes with `node.machine.sapcloud.io/candidate-for-update`, user can select the candidate nodes for update by labeling them with `node.machine.sapcloud.io/selected-for-update=true`: 
+```
+kubectl label node <node-name> node.machine.sapcloud.io/selected-for-update=true
+```
+
+The `ManualInPlaceWorkersUpdated` [constraint](../shoot/shoot_status.md/#constraints) in the shoot status indicates that at least one worker pool with the `ManualInPlaceUpdate` strategy is pending an update. Shoot reconciliation will still succeed even if there are worker pools pending updates.
+
+The `inPlaceUpdates.pendingWorkerUpdates.manualInPlaceUpdate` field in the `Shoot` status lists the names of worker pools that are pending updates with the this strategy.
+
+```yaml
+spec:
+  provider:
+    workers:
+      - name: cpu-worker
+        maxSurge: 0
+        maxUnavailable: 2
+        updateStrategy: ManualInPlaceUpdate
+```
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: same here
created_at: 2025-05-22T05:48:06Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,44 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
+The `UpdateStrategy` field in the Shoot specification (`.spec.provider.workers[].updateStrategy`) gives users the flexibility to define how the `machine-controller-manager`(MCM) handles worker pool updates during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
+
 ### In-Place vs. Rolling Updates
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+#### In-Place Updates
+- The upgrade is performed in a "rolling update" manner, without replacing the underlying machines.
+- The shoot worker nodes remain intact and are not recreated.
+- The existing workload is gracefully drained and evicted from the worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+- **No Draining Scenarios**:
+  - When the Kubernetes patch version is updated, the upgrade is executed without draining the node. The shoot worker nodes remain unchanged, and only the `kubelet` process is restarted with the updated Kubernetes version binary.
+
+#### Rolling Updates
+- The upgrade is performed in a "rolling update" manner, during which nodes in the worker pool are replaced. Similar to how pods in Kubernetes are updated when backed by a `Deployment`.
+- Worker nodes are terminated one after another and replaced by new machines.
+- The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+
+### AutoRollingUpdate
 
-If the Kubernetes minor version is changed, then the upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).
-The worker nodes will be terminated one after another and replaced by new machines.
-The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+When the auto rolling update strategy is selected, the upgrade is performed in a "rolling update" manner. The machine-controller-manager sequentially terminates the worker nodes and replaces them with new nodes. This is the default update strategy. To create workers with `AutoRollingUpdate`, either omit the `workers.updateStrategy` field (it will default to `AutoRollingUpdate`) or explicitly set the field to `AutoRollingUpdate` for each worker.
+
+```yaml
+spec:
+  provider:
+    workers:
+      - name: cpu-worker
+        maxSurge: 0
+        maxUnavailable: 2
+        updateStrategy: AutoRollingUpdate
+```
 
 #### Customize Rolling Update Behaviour of Shoot Worker Nodes
 
 The `.spec.provider.workers[]` list exposes two fields that you might configure based on your workload's needs: `maxSurge` and `maxUnavailable`.
 The same concepts [like in Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment) apply.
-Additionally, you might customize how the machine-controller-manager (abbrev.: MCM; the component instrumenting this rolling update) is behaving. You can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+Additionally, you might customize how the MCM is behaving. You can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: Nit: You could call it `machine-controller-manager`, no benefit in abbreviating
created_at: 2025-05-22T05:48:52Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,44 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
+The `UpdateStrategy` field in the Shoot specification (`.spec.provider.workers[].updateStrategy`) gives users the flexibility to define how the `machine-controller-manager`(MCM) handles worker pool updates during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
+
 ### In-Place vs. Rolling Updates
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+#### In-Place Updates
+- The upgrade is performed in a "rolling update" manner, without replacing the underlying machines.
+- The shoot worker nodes remain intact and are not recreated.
+- The existing workload is gracefully drained and evicted from the worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+- **No Draining Scenarios**:
+  - When the Kubernetes patch version is updated, the upgrade is executed without draining the node. The shoot worker nodes remain unchanged, and only the `kubelet` process is restarted with the updated Kubernetes version binary.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: This is also the case for Rolling update strategies, putting it under this heading might be confusing
created_at: 2025-05-22T05:49:34Z
author_association: MEMBER
diff_hunk: @@ -53,21 +53,44 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
+The `UpdateStrategy` field in the Shoot specification (`.spec.provider.workers[].updateStrategy`) gives users the flexibility to define how the `machine-controller-manager`(MCM) handles worker pool updates during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
+
 ### In-Place vs. Rolling Updates
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+#### In-Place Updates
path: docs/usage/shoot-operations/shoot_updates.md
user: login: shafeeqes
body: This heading is repeated again later, can we improve this?
created_at: 2025-05-22T05:50:01Z
author_association: MEMBER
diff_hunk: @@ -53,31 +53,52 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+The `UpdateStrategy` field in the Shoot specification (`.spec.provider.workers[].updateStrategy`) gives users the flexibility to define how the `machine-controller-manager` handles worker pool updates during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+> ⚠️ The above strategies generally require draining the node when changes are made to the `Shoot` specification. The specific changes that trigger this behavior will be discussed in later sections.
+For all other spec changes like Kubernetes patch version update, the upgrade is executed without draining the node and the shoot worker nodes remain unchanged. In case of Kubernetes patch version, only the `kubelet` process is restarted with the updated Kubernetes version binary.
 
-If the Kubernetes minor version is changed, then the upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).
-The worker nodes will be terminated one after another and replaced by new machines.
+### Rolling Updates
+
+The upgrade is performed in a "rolling update" manner, during which nodes in the worker pool are replaced. Similar to how pods in Kubernetes are updated when backed by a `Deployment`.
+Worker nodes are terminated one after another and replaced by new machines.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: ```suggestion
Worker nodes are terminated one after another and replaced by new nodes.
```
created_at: 2025-05-28T03:23:55Z
author_association: MEMBER
diff_hunk: @@ -53,31 +53,52 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+The `UpdateStrategy` field in the Shoot specification (`.spec.provider.workers[].updateStrategy`) gives users the flexibility to define how the `machine-controller-manager` handles worker pool updates during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+> ⚠️ The above strategies generally require draining the node when changes are made to the `Shoot` specification. The specific changes that trigger this behavior will be discussed in later sections.
+For all other spec changes like Kubernetes patch version update, the upgrade is executed without draining the node and the shoot worker nodes remain unchanged. In case of Kubernetes patch version, only the `kubelet` process is restarted with the updated Kubernetes version binary.
 
-If the Kubernetes minor version is changed, then the upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).
-The worker nodes will be terminated one after another and replaced by new machines.
+### Rolling Updates
+
+The upgrade is performed in a "rolling update" manner, during which nodes in the worker pool are replaced. Similar to how pods in Kubernetes are updated when backed by a `Deployment`.
+Worker nodes are terminated one after another and replaced by new machines.
 The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
 
+#### Automatic Rolling Updates
+
+When the auto rolling update strategy is selected, the update process is fully orchestrated by the Gardener and the machine-controller-manager. The machine-controller-manager sequentially terminates the worker nodes and replaces them with new nodes.
+>ℹ️  This is the `default` update strategy.
+
+To create workers with `AutoRollingUpdate`, either omit the `workers.updateStrategy` field (it will default to `AutoRollingUpdate`) or explicitly set the field to `AutoRollingUpdate` for each worker.
+
+```yaml
+spec:
+  provider:
+    workers:
+      - name: cpu-worker
+        maxSurge: 0
+        maxUnavailable: 2
+        updateStrategy: AutoRollingUpdate
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: Similar changes for missing alignment in other examples.
```suggestion
spec:
  provider:
    workers:
    - name: cpu-worker
      maxSurge: 0
      maxUnavailable: 2
      updateStrategy: AutoRollingUpdate
```
created_at: 2025-05-28T03:34:56Z
author_association: MEMBER
diff_hunk: @@ -53,31 +53,52 @@ We consider shoot upgrades to change either the:
 Generally, an upgrade is also performed through a reconciliation of the `Shoot` resource, i.e., the same concepts as for [shoot updates](#updates) apply.
 If an end-user triggers an upgrade (e.g., by changing the Kubernetes version) after a new Gardener version was deployed but before the shoot was reconciled again, then this upgrade might incorporate the changes delivered with this new Gardener version.
 
-### In-Place vs. Rolling Updates
+The `UpdateStrategy` field in the Shoot specification (`.spec.provider.workers[].updateStrategy`) gives users the flexibility to define how the `machine-controller-manager` handles worker pool updates during the upgrade process. Currently gardener support three update strategies:
+* `AutoRollingUpdate`
+* `AutoInPlaceUpdate`
+* `ManualInPlaceUpdate`
 
-If the Kubernetes patch version is changed, then the upgrade happens in-place.
-This means that the shoot worker nodes remain untouched and only the `kubelet` process restarts with the new Kubernetes version binary.
-The same applies for configuration changes of the kubelet.
+> ⚠️ The above strategies generally require draining the node when changes are made to the `Shoot` specification. The specific changes that trigger this behavior will be discussed in later sections.
+For all other spec changes like Kubernetes patch version update, the upgrade is executed without draining the node and the shoot worker nodes remain unchanged. In case of Kubernetes patch version, only the `kubelet` process is restarted with the updated Kubernetes version binary.
 
-If the Kubernetes minor version is changed, then the upgrade is done in a "rolling update" fashion, similar to how pods in Kubernetes are updated (when backed by a `Deployment`).
-The worker nodes will be terminated one after another and replaced by new machines.
+### Rolling Updates
+
+The upgrade is performed in a "rolling update" manner, during which nodes in the worker pool are replaced. Similar to how pods in Kubernetes are updated when backed by a `Deployment`.
+Worker nodes are terminated one after another and replaced by new machines.
 The existing workload is gracefully drained and evicted from the old worker nodes to new worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
 
+#### Automatic Rolling Updates
+
+When the auto rolling update strategy is selected, the update process is fully orchestrated by the Gardener and the machine-controller-manager. The machine-controller-manager sequentially terminates the worker nodes and replaces them with new nodes.
+>ℹ️  This is the `default` update strategy.
+
+To create workers with `AutoRollingUpdate`, either omit the `workers.updateStrategy` field (it will default to `AutoRollingUpdate`) or explicitly set the field to `AutoRollingUpdate` for each worker.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: `workers.updateStrategy` is not a correct field.
created_at: 2025-05-28T03:35:58Z
author_association: MEMBER
diff_hunk: @@ -109,6 +130,97 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### In-Place Updates
+
+For scenarios where users want to retain the current nodes and avoid deletion during updates, Gardener provides the option of `in-place` updates. The upgrade is performed without replacing the underlying machines. Although there is an exception where new nodes are created with the updated configuration and old ones are terminated. One such exception is discussed in [Automatic inplace update](#automatic-in-place-updates) section.
+
+The existing workload is gracefully drained and evicted from the worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+
+> ℹ️ Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate in the `gardener-apiserver`.
+
+For in-place updates, the first requirement is that the operating system must support them. For a specific machine image version, the configuration for in-place updates must be defined in the `CloudProfile` under spec.machineImages[].inPlaceUpdates:
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: ```suggestion
For in-place updates, the first requirement is that the operating system must support them. For a specific machine image version, the configuration for in-place updates must be defined in the `CloudProfile` under `spec.machineImages[].versions[].inPlaceUpdates`:
```
created_at: 2025-05-28T03:43:51Z
author_association: MEMBER
diff_hunk: @@ -109,6 +130,97 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### In-Place Updates
+
+For scenarios where users want to retain the current nodes and avoid deletion during updates, Gardener provides the option of `in-place` updates. The upgrade is performed without replacing the underlying machines. Although there is an exception where new nodes are created with the updated configuration and old ones are terminated. One such exception is discussed in [Automatic inplace update](#automatic-in-place-updates) section.
+
+The existing workload is gracefully drained and evicted from the worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+
+> ℹ️ Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate in the `gardener-apiserver`.
+
+For in-place updates, the first requirement is that the operating system must support them. For a specific machine image version, the configuration for in-place updates must be defined in the `CloudProfile` under spec.machineImages[].inPlaceUpdates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  versions:
+  - version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### Customize In-Place Update Behaviour of Shoot Worker Nodes
+
+In addition to customisable fields mentioned in [](#customize-rolling-update-behaviour-of-shoot-worker-nodes) section, you can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: ```suggestion
In addition to customisable fields mentioned in the [above](#customize-rolling-update-behaviour-of-shoot-worker-nodes) section, you can also configure the following fields in `.spec.provider.worker[].machineControllerManager`:
```
created_at: 2025-05-28T04:13:30Z
author_association: MEMBER
diff_hunk: @@ -109,6 +130,97 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### In-Place Updates
+
+For scenarios where users want to retain the current nodes and avoid deletion during updates, Gardener provides the option of `in-place` updates. The upgrade is performed without replacing the underlying machines. Although there is an exception where new nodes are created with the updated configuration and old ones are terminated. One such exception is discussed in [Automatic inplace update](#automatic-in-place-updates) section.
+
+The existing workload is gracefully drained and evicted from the worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+
+> ℹ️ Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate in the `gardener-apiserver`.
+
+For in-place updates, the first requirement is that the operating system must support them. For a specific machine image version, the configuration for in-place updates must be defined in the `CloudProfile` under spec.machineImages[].inPlaceUpdates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  versions:
+  - version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### Customize In-Place Update Behaviour of Shoot Worker Nodes
+
+In addition to customisable fields mentioned in [](#customize-rolling-update-behaviour-of-shoot-worker-nodes) section, you can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+
+* `MachineInPlaceUpdateTimeout`:  Timeout (in duration) after which an in-place update is declared as failed.
+* `DisableHealthTimeout`: A boolean value that, when set to `true`, ignores the health timeout. As a result, machines are never marked as failed, and unhealthy machines are not deleted. The default value is `true` for in-place updates.
+
+#### In-Place Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: ```suggestion
An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except for the following:
```
created_at: 2025-05-28T04:15:20Z
author_association: MEMBER
diff_hunk: @@ -109,6 +130,97 @@ Changes to `kubeReserved` or `systemReserved` do not trigger a node roll if thei
 Generally, the provider extension controllers might have additional constraints for changes leading to rolling updates, so please consult the respective documentation as well.
 In particular, if the feature gate `NewWorkerPoolHash` is enabled and a worker pool uses the new hash, then the `providerConfig` as a whole is not included. Instead only fields selected by the provider extension are considered.
 
+### In-Place Updates
+
+For scenarios where users want to retain the current nodes and avoid deletion during updates, Gardener provides the option of `in-place` updates. The upgrade is performed without replacing the underlying machines. Although there is an exception where new nodes are created with the updated configuration and old ones are terminated. One such exception is discussed in [Automatic inplace update](#automatic-in-place-updates) section.
+
+The existing workload is gracefully drained and evicted from the worker nodes, respecting the configured `PodDisruptionBudget`s (see [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)).
+
+> ℹ️ Currently, `in-place` updates are controlled by the `InPlaceNodeUpdates` feature gate in the `gardener-apiserver`.
+
+For in-place updates, the first requirement is that the operating system must support them. For a specific machine image version, the configuration for in-place updates must be defined in the `CloudProfile` under spec.machineImages[].inPlaceUpdates:
+- The `inPlaceUpdates.supported` field must be set to `true`.
+- The `inPlaceUpdates.minVersionForUpdate` field specifies the minimum version from which an in-place update to the target machine image version can be performed.
+
+```yaml
+machineImages:
+- name: gardenlinux
+  versions:
+  - version: 1632.0.0
+    inPlaceUpdates:
+      supported: true
+      minVersionForUpdate: 1630.0.0
+```
+
+The `inPlaceUpdates` field in the Shoot status provides details about in-place updates for the Shoot workers. It includes the `pendingWorkerUpdates` field, which lists the worker pools that are awaiting in-place updates.
+
+#### Customize In-Place Update Behaviour of Shoot Worker Nodes
+
+In addition to customisable fields mentioned in [](#customize-rolling-update-behaviour-of-shoot-worker-nodes) section, you can configure the following fields in `.spec.provider.worker[].machineControllerManager`:
+
+* `MachineInPlaceUpdateTimeout`:  Timeout (in duration) after which an in-place update is declared as failed.
+* `DisableHealthTimeout`: A boolean value that, when set to `true`, ignores the health timeout. As a result, machines are never marked as failed, and unhealthy machines are not deleted. The default value is `true` for in-place updates.
+
+#### In-Place Update Triggers
+
+An in-place update of the shoot worker nodes is triggered for rolling update triggers listed under [Rolling Update Triggers](#rolling-update-triggers) except the following:
+* `.spec.provider.workers[].machine.image.name`
+* `.spec.provider.workers[].machine.type`
+* `.spec.provider.workers[].volume.type`
+* `.spec.provider.workers[].volume.size`
+* `.spec.provider.workers[].cri.name`
+* `.spec.systemComponents.nodeLocalDNS.enabled`
+
+> There are validations which restricts changing the above mentioned exception fields when `in-place` updates strategy is configured.
+
+When a worker pool is undergoing an in-place update, applying subsequent updates to the same worker pool is restricted.
+If an in-place update fails and nodes are left in a problematic state, user intervention is required to manually fix the nodes. In cases where a subsequent update is necessary to resolve the issue, users can update the worker pool after adding the force update annotation `gardener.cloud/operation=force-in-place-update` on the Shoot. Refer to [Force-update a worker pool with InPlace update strategy](shoot_operations.md#force-update-a-worker-pool-with-inplace-update-strategy) for more details.
+
+> ⚠️ Changing the update strategy from `AutoRollingUpdate` to `AutoInPlaceUpdate`/`ManualInPlaceUpdate` (and vice versa) is not allowed. However, switching between `AutoInPlaceUpdate` and `ManualInPlaceUpdate` is permitted.
+
+#### Automatic In-Place Updates
+
+In case of AutoInPlaceUpdate update strategy, the update process is fully orchestrated by Gardener and the machine-controller-manager. No user intervention is required.
+Set `.spec.provider.workers[].updateStrategy` field in the `Shoot` spec to `AutoInPlaceUpdate`.
+
+```yaml
+spec:
+  provider:
+    workers:
+      - name: cpu-worker
+        maxSurge: 0
+        maxUnavailable: 2
+        updateStrategy: AutoInPlaceUpdate
+```
+
+During the automatic in-place updates, `machine-controller-manager` can create new nodes when `max-surge` value is set to value `>0`. In such cases new nodes are created with the updated configuration and the old ones are terminated.
path: docs/usage/shoot-operations/shoot_updates.md
user: login: acumino
body: please put more details here that only n number of new nodes will get created, which is maxSurge and then all other nodes get inplace updated.
created_at: 2025-05-28T04:51:49Z
author_association: MEMBER

PR comments:
user: login: gardener-prow[bot]
created_at: 2025-05-05T13:04:53Z
body: Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with `/test all`
author_association: CONTRIBUTOR
user: login: ary1992
created_at: 2025-05-16T10:25:22Z
body: /retest
author_association: CONTRIBUTOR
user: login: ary1992
created_at: 2025-05-27T07:53:47Z
body: /retest
author_association: CONTRIBUTOR
user: login: shafeeqes
created_at: 2025-05-27T07:58:39Z
body: @rfranzke, Can we continue with this PR?
author_association: MEMBER
user: login: gardener-prow[bot]
created_at: 2025-05-28T06:15:38Z
body: LGTM label has been added.  <details>Git tree hash: 7ab72f64cbd3afbd86add01a91e5b0c70daf2eae</details>
author_association: CONTRIBUTOR
user: login: ary1992
created_at: 2025-05-28T07:31:13Z
body: /retest
author_association: CONTRIBUTOR
user: login: rfranzke
created_at: 2025-05-28T07:40:11Z
body: /approve
/retest
author_association: MEMBER
user: login: gardener-prow[bot]
created_at: 2025-05-28T07:40:20Z
body: [APPROVALNOTIFIER] This PR is **APPROVED**

This pull-request has been approved by: *<a href="https://github.com/gardener/gardener/pull/12005#issuecomment-2915300742" title="Approved">rfranzke</a>*

The full list of commands accepted by this bot can be found [here](https://prow.gardener.cloud/command-help?repo=gardener%2Fgardener).

The pull request process is described [here](https://gardener.cloud/docs/contribute/#pull-request-checklist)

<details >
Needs approval from an approver in each of these files:

- ~~[OWNERS](https://github.com/gardener/gardener/blob/master/OWNERS)~~ [rfranzke]

Approvers can indicate their approval by writing `/approve` in a comment
Approvers can cancel approval by writing `/approve cancel` in a comment
</details>
<!-- META={"approvers":[]} -->
author_association: CONTRIBUTOR