NodePool contains the name and configuration for a cluster's node pool. Node pools are a set of nodes (i.e. VM's), with a common configuration and specification, under the control of the cluster master. They may have a set of Kubernetes labels applied to them, which may be used to reference them during pod scheduling. They may also be resized up or down, to accommodate the workload.
The name of the node pool.
The node configuration of the pool.
The initial node count for the pool. You must ensure that your Compute Engine `resource quota
The list of Google Compute Engine `zones
[Output only] Server-defined URL for the resource.
The version of the Kubernetes of this node.
[Output only] The resource URLs of the `managed instance groups
[Output only] The status of the nodes in this pool instance.
[Output only] Deprecated. Use conditions instead. Additional information about the current status of this node pool instance, if available.
Autoscaler configuration for this NodePool. Autoscaler is enabled only if a valid configuration is present.
NodeManagement configuration for this NodePool.
The constraint on the maximum number of pods that can be run simultaneously on a node in the node pool.
Which conditions caused the current node pool state.
[Output only] The pod CIDR block size per node in this node pool.
Upgrade settings control disruption and speed of the upgrade.
Inheritancebuiltins.object > proto.message.Message > NodePool
The current status of the node pool instance.
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.