To create a node pool in Anthos clusters on AWS, you must provide the following resources:
- The name of an existing AWS cluster to create the node pool in
- An IAM instance profile for node pool VMs
- A subnet where the node pool VMs will run
If you want SSH access to your nodes, you can Create an EC2 key pair.
Create a standard node pool
Once these resources are available, you can create a node pool with this command:
gcloud container aws node-pools create NODE_POOL_NAME \
--cluster CLUSTER_NAME \
--instance-type INSTANCE_TYPE \
--root-volume-size ROOT_VOLUME_SIZE \
--iam-instance-profile NODEPOOL_PROFILE \
--node-version NODE_VERSION \
--min-nodes MIN_NODES \
--max-nodes MAX_NODES \
--max-pods-per-node MAX_PODS_PER_NODE \
--location GOOGLE_CLOUD_LOCATION \
--subnet-id NODEPOOL_SUBNET \
--ssh-ec2-key-pair SSH_KEY_PAIR_NAME \
--config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN \
--tags "Name=CLUSTER_NAME-NODE_POOL_NAME"
Replace the following:
NODE_POOL_NAME
: a name you choose for your node poolCLUSTER_NAME
: the name of the cluster to attach the node pool toINSTANCE_TYPE
: the desired AWS machine instance type for this node pool— for example,m5.large
ROOT_VOLUME_SIZE
: the desired size for each node's root volume, in GbNODEPOOL_PROFILE
: the IAM instance profile for node pool VMsNODE_VERSION
: the Kubernetes version to install on each node in the node pool (e.g., "1.27.4-gke.1600")MIN_NODES
: the minimum number of nodes the node pool can containMAX_NODES
: the maximum number of nodes the node pool can containMAX_PODS_PER_NODE
: the maximum number of pods that can be created on any single node in the poolGOOGLE_CLOUD_LOCATION
: the name of the Google Cloud location from which this node pool will be managedNODEPOOL_SUBNET
: the ID of the subnet the node pool will run on.- There must not be any overlap between the cluster's Pod/Service IP ranges and the node pool subnet network. For more information on selecting Pod and Service IP ranges for your cluster, see Select CIDR ranges for your cluster
- If this subnet is outside of the VPC primary CIDR block, some additional steps are needed. For more information, see security groups.
SSH_KEY_PAIR_NAME
: the name of the AWS SSH key pair created for SSH access (optional)CONFIG_KMS_KEY_ARN
: the Amazon Resource Name (ARN) of the AWS KMS key that encrypts user data
If present, the --tags
parameter applies the given tag to all nodes in your
node pool. This example tags all nodes in the pool with the names of the cluster
and node pool the node belongs to.
Spot Instance node pools
Anthos clusters on AWS supports AWS spot instance node pools as a Preview feature. Spot instance node pools are pools of Amazon EC2 Spot Instances that are available on AWS at a lower cost.
Spot Instances can provide cost savings for stateless, fault-tolerant, and flexible applications. However, they aren't well-suited for workloads that are inflexible, stateful, fault-intolerant, or tightly coupled between instance nodes. Spot Instances can be interrupted by Amazon EC2 when EC2 needs the capacity back, and so they are subject to fluctuations in the Spot market. If your workloads require guaranteed capacity and can't tolerate occasional periods of unavailability, choose a standard node pool instead of a spot instance node pool.
The allocation strategy employed in Anthos clusters on AWS focuses on selecting
Spot Instance pools with the highest capacity availability, minimizing the risk
of interruptions. This approach is particularly beneficial for workloads with a
higher cost of interruption, such as image and media rendering or Deep Learning.
Specifically, the capacityOptimized
allocation strategy has been implemented,
as described in
Allocation strategies for Spot Instances.
Create a Spot node pool
To create a Spot Instance node pool, run the following command:
gcloud container aws node-pools create NODE_POOL_NAME \
--cluster CLUSTER_NAME \
--spot-instance-types INSTANCE_TYPE_LIST \
--root-volume-size ROOT_VOLUME_SIZE \
--iam-instance-profile NODEPOOL_PROFILE \
--node-version NODE_VERSION \
--min-nodes MIN_NODES \
--max-nodes MAX_NODES \
--max-pods-per-node MAX_PODS_PER_NODE \
--location GOOGLE_CLOUD_LOCATION \
--subnet-id NODEPOOL_SUBNET \
--ssh-ec2-key-pair SSH_KEY_PAIR_NAME \
--config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN \
--tags "Name=CLUSTER_NAME-NODE_POOL_NAME"
Replace the following:
- NODE_POOL_NAME: the name you want to assign to this node pool.
- CLUSTER_NAME: the name of the cluster you want to attach this node pool to.
- INSTANCE_TYPE_LIST: a comma-separated list of AWS EC2 instance types. The node pool provisions Spot instances with these instance types. The instance types must have the same CPU architecture, the same number of CPUs and the same amount of memory. For example: "c6g.large,c6gd.large,c6gn.large,c7g.large,t4g.medium". You can use the Amazon EC2 Instance Selector tool to find instance types that have identical CPU and memory configurations.
ROOT_VOLUME_SIZE
: the desired size for each node's root volume, in GbNODEPOOL_PROFILE
: the IAM instance profile for node pool VMsNODE_VERSION
: the Kubernetes version to install on each node in the node pool (e.g., "1.27.4-gke.1600")MIN_NODES
: the minimum number of nodes the node pool can containMAX_NODES
: the maximum number of nodes the node pool can containMAX_PODS_PER_NODE
: the maximum number of pods that can be created on any single node in the poolGOOGLE_CLOUD_LOCATION
: the name of the Google Cloud location from which this node pool will be managedNODEPOOL_SUBNET
: the ID of the subnet the node pool will run on.- There must not be any overlap between the cluster's Pod/Service IP ranges and the node pool subnet network. For more information on selecting Pod and Service IP ranges for your cluster, see Select CIDR ranges for your cluster
- If this subnet is outside of the VPC primary CIDR block, some additional steps are needed. For more information, see security groups.
SSH_KEY_PAIR_NAME
: the name of the AWS SSH key pair created for SSH access (optional)CONFIG_KMS_KEY_ARN
: the Amazon Resource Name (ARN) of the AWS KMS key that encrypts user data
The best practice is to list a number of instance types in the INSTANCE_TYPE_LIST field. This best practice is important because if a node pool is configured with only a single instance type, and that instance type isn't available in any of the desired Availability Zones, then the node pool can't provision any new nodes. This can affect the availability of your applications and can cause service disruptions.
Note that the spot-instance-types
field is mutually exclusive with the
instance-type
field. This means that you can provide only one of these fields
and not both.