Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable using AWS spot instances #203

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

yogananth-subramanian
Copy link
Contributor

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

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
@yogananth-subramanian
Copy link
Contributor Author

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 ) .

@@ -6,7 +6,8 @@ aws_secret_access_key: "{{ lookup('env', 'AWS_SECRET_ACCESS_KEY') }}"
aws_region: "{{ lookup('env', 'AWS_REGION') }}"
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) }}"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants