Class UpgradeSettings (2.4.1)

Version 2.4.1

• 2.55.0 (latest)
• 2.54.0
• 2.53.0
• 2.52.0
• 2.50.0
• 2.49.0
• 2.48.0
• 2.47.1
• 2.46.0
• 2.45.0
• 2.44.0
• 2.43.0
• 2.42.0
• 2.41.0
• 2.40.0
• 2.39.0
• 2.38.0
• 2.37.0
• 2.36.0
• 2.35.0
• 2.34.0
• 2.33.0
• 2.32.0
• 2.31.0
• 2.30.0
• 2.29.0
• 2.28.0
• 2.27.0
• 2.26.0
• 2.25.0
• 2.24.0
• 2.23.0
• 2.22.0
• 2.21.0
• 2.20.0
• 2.19.0
• 2.18.0
• 2.17.4
• 2.16.0
• 2.15.0
• 2.14.0
• 2.13.0
• 2.12.2
• 2.11.2
• 2.10.8
• 2.9.0
• 2.8.1
• 2.7.1
• 2.6.1
• 2.5.0
• 2.4.1
• 2.3.1
• 2.2.0
• 2.1.0
• 2.0.1
• 1.0.3
• 0.5.0
• 0.4.0
• 0.3.0

UpgradeSettings(mapping=None, *, ignore_unknown_fields=False, **kwargs)

These upgrade settings control the level of parallelism and the level of disruption caused by an upgrade.

maxUnavailable controls the number of nodes that can be simultaneously unavailable.

maxSurge controls the number of additional nodes that can be added to the node pool temporarily for the time of the upgrade to increase the number of available nodes.

(maxUnavailable + maxSurge) determines the level of parallelism (how many nodes are being upgraded at the same time).

Note: upgrades inevitably introduce some disruption since workloads need to be moved from old nodes to new, upgraded ones. Even if maxUnavailable=0, this holds true. (Disruption stays within the limits of PodDisruptionBudget, if it is configured.)

Consider a hypothetical node pool with 5 nodes having maxSurge=2, maxUnavailable=1. This means the upgrade process upgrades 3 nodes simultaneously. It creates 2 additional (upgraded) nodes, then it brings down 3 old (not yet upgraded) nodes at the same time. This ensures that there are always at least 4 nodes available.

Attributes
Name	Description
max_surge	int The maximum number of nodes that can be created beyond the current size of the node pool during the upgrade process.
max_unavailable	int The maximum number of nodes that can be simultaneously unavailable during the upgrade process. A node is considered available if its status is Ready.