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.

Sign up for GitHub

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

Jump to bottom

AWS: allow users to specify that their node ASG should use spot instances #21200

Closed
justinsb opened this issue Feb 12, 2016 · 4 comments
Closed

AWS: allow users to specify that their node ASG should use spot instances #21200

justinsb opened this issue Feb 12, 2016 · 4 comments
Labels
priority/backlog Higher priority than priority/awaiting-more-evidence.
Milestone
v1.2

Comments

@justinsb
Copy link
Member

Particularly now we have KUBE_USE_EXISTING_MASTER, it would make sense to allow users to add an ASG which uses spot instances.

Probably yet another env var.
@justinsb justinsb added this to the v1.2-candidate milestone Feb 12, 2016
@binarybana
Copy link

In addition to the spot based ASGs we've been using in our cloudformation scripts, we've also begun experimenting with spot fleets for multiple instances types and more granular control over instance termination on cluster spin down as our long running jobs complete.

@guang
Copy link

guang commented Feb 14, 2016

+1 for spot fleet, that would sweeet

@therc
Copy link
Member

therc commented Feb 15, 2016

Does this need any new code to detect in a timely fashion that a node is getting evicted? Amazon recommends checking metadata for the termination notice every five seconds, but the AWS cloudprovider's isAlive() already considers a machine in "shutting down" state as not present. That could use better log messages, but is it already enough? I haven't tried it, but I assume that the spot instance would also be in "shutting down" state during those two minutes. And the nodecontroller runs every five seconds.. right?

@justinsb
Copy link
Member Author

I believe an ASG using spot instances will work with today's code. Maybe we'll make some poor scheduling decisions if we don't listen to notifications, but it should look like our instances are just a little less reliable.

@davidopp davidopp added the priority/backlog Higher priority than priority/awaiting-more-evidence. label Feb 19, 2016
@davidopp davidopp modified the milestones: v1.2, v1.2-candidate Feb 19, 2016
justinsb added a commit to justinsb/kubernetes that referenced this issue Feb 22, 2016
@justinsb
AWS kube-up: Allow spot instances
fb12c48 
I think we should probably leave this undocumented for now, until we
have a better way to launch multiple sets of nodes, but it's great for
cost savings while testing!

Fix kubernetes#21200
@justinsb justinsb mentioned this issue Feb 22, 2016
Merged
justinsb added a commit to justinsb/kubernetes that referenced this issue Feb 22, 2016
@justinsb
AWS kube-up: Build kubeconfig asap
050863c 
Once we've built the master, we can build kubeconfig.  By doing so, if
we time out waiting for the nodes, the system is still configured
correctly.

In particular, spot instances can be slow to launch.

Related to issue kubernetes#21200
@justinsb justinsb mentioned this issue Feb 22, 2016
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
priority/backlog Higher priority than priority/awaiting-more-evidence.
Projects
None yet
Milestone
v1.2
Development

No branches or pull requests
7 participants
@justinsb @binarybana @mikedanese @guang @bgrant0607 @davidopp @therc