Skip to content

Commit 1d80f73

Browse files
Update concepts-cluster-upgrade-overview.md
1 parent 6673cb3 commit 1d80f73

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

articles/operator-nexus/concepts-cluster-upgrade-overview.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -34,7 +34,7 @@ Patch runtime release is produced monthly in between the minor releases. These r
3434

3535
Starting a runtime upgrade is defined under [Upgrading cluster runtime via Azure CLI](./howto-cluster-runtime-upgrade.md).
3636

37-
The runtime upgrade starts by upgrading the three management servers designated as the control plane nodes. The spare control plane server is the first server to upgrade. The last control plane server deprovisions and transitions to `Available` state. These servers are updated serially and proceed only when each completes. The remaining management servers are seggregated into two groups. The runtime upgrade will now leverage two management groups, instead of a single group where each group is upgraded in two stages and sequentially. Introducing this capability allows for components running on the management servers to ensure resiliency during the runtime upgrade by applying affinity rules. For this release, each CSN will leverage this functionality by placing one instance in each management group. No customer interaction with this functionality. There may be additional labels seen on management nodes to identify the groups.
37+
The runtime upgrade starts by upgrading the three management servers designated as the control plane nodes. The spare control plane server is the first server to upgrade. The last control plane server deprovisions and transitions to `Available` state. These servers are updated serially and proceed only when each completes. The remaining management servers are segregated into two groups. The runtime upgrade will now leverage two management groups, instead of a single group where each group is upgraded in two stages and sequentially. Introducing this capability allows for components running on the management servers to ensure resiliency during the runtime upgrade by applying affinity rules. For this release, each CSN will leverage this functionality by placing one instance in each management group. No customer interaction with this functionality. There may be additional labels seen on management nodes to identify the groups.
3838

3939
> [!Note]
4040
> Customers may observe the spare server with a different runtime version. This is expected.

0 commit comments

Comments
 (0)