Enable using AWS spot instances#203
Enable using AWS spot instances#203yogananth-subramanian wants to merge 1 commit intocloud-bulldozer:masterfrom
Conversation
The patch enables the use of AWS spot instances for workers, infra, and workload nodes, except for the controller nodes, which will be deployed as normal instance types. To use this feature, a new environment variable SPOT_INSTANCE_ZONE must be set to the zone where the spot instances would be deployed. Example: export SPOT_INSTANCE_ZONE=us-east-2a The instance type for the nodes will use the existing environment variables OPENSHIFT_WORKER_INSTANCE_TYPE, OPENSHIFT_INFRA_NODE_INSTANCE_TYPE, and OPENSHIFT_NODE_INSTANCE_TYPE. The spot instance type available for use in a zone can be obtained from the AWS spot request console. Have created a script spotlst.sh(https://gist.github.com/yogananth-subramanian/1e69b11c4ce1564cbbc612f61ea05031), that can be used to pick the spot instance type and zone to use, it provides details about interrupt percentage per instance_type for each zone and their corresponding spot pricing and savings percentage over on-demand price. Example: ./spotlst.sh --mincpu 4 --maxcpu 4 --minmem 16 --maxmem 16 --intr 1 -region us-east-1,us-east-2 --inst m5.xlarge Using minimum price of the on-demand instance as maximum price for spot intance 0.1920000000 region,zone,instance_type,price,savings,iterrupt us-east-2,us-east-2a,m5.xlarge,0.041400,79,0
|
Hi @mohit-sheth @jtaleric @afcollins @rsevilla87 it would be wonderful if you could review and provide your valuable feedback for the patch(Enable using AWS spot instances #203 ) . |
| aws_install_architecture: "{{ lookup('env', 'AWS_INSTALL_ARCHITECTURE') | default('amd64', true) }}" | ||
| cluster_owner: "{{ lookup('env', 'CLUSTER_OWNER') | default('ci', true) }}" | ||
| workload_aws_az_suffix: "{{ lookup('env', 'WORKLOAD_AWS_AZ_SUFFIX') | default('d', true) }}" | ||
| spot_instance_zone : "{{ lookup('env', 'SPOT_INSTANCE_ZONE')|default('', true) }}" |
There was a problem hiding this comment.
This will limit availability zone to only what we specify, and in some cases even within a specific region 2 AZs have availability and one doesn't. Any thoughts on providing multiple values here?
There was a problem hiding this comment.
Hello @smalleni While investigating the availability of a particular spot machine type in an AWS region, most of the time a specific spot machine type was available only in one zone in that region, so was able to test and hence base this patch on a single availability zone.
I'm considering adding the option to deploy across multiple availability zones once I get the chance to verify across multiple availability zones in a region.
2 participants
The patch enables the use of AWS spot instances for workers, infra, and workload nodes, except for the controller nodes, which will be deployed as normal instance types. To use this feature, a new environment variable SPOT_INSTANCE_ZONE must be set to the zone where the spot instances would be deployed. Example:
export SPOT_INSTANCE_ZONE=us-east-2a
The instance type for the nodes will use the existing environment variables OPENSHIFT_WORKER_INSTANCE_TYPE, OPENSHIFT_INFRA_NODE_INSTANCE_TYPE, and OPENSHIFT_NODE_INSTANCE_TYPE.
The spot instance type available for use in a zone can be obtained from the AWS spot request console. Have created a script spotlst.sh(https://gist.github.com/yogananth-subramanian/1e69b11c4ce1564cbbc612f61ea05031), that can be used to pick the spot instance type and zone to use, it provides details about interrupt percentage per instance_type for each zone and their corresponding spot pricing and savings percentage over on-demand price.
Example:
./spotlst.sh --mincpu 4 --maxcpu 4 --minmem 16 --maxmem 16 --intr 1 -region us-east-1,us-east-2 --inst m5.xlarge
Using minimum price of the on-demand instance as maximum price for spot intance 0.1920000000
region,zone,instance_type,price,savings,iterrupt
us-east-2,us-east-2a,m5.xlarge,0.041400,79,0
Description
Fixes