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

add desc of capacity fallback #1204

Merged
merged 4 commits into from
Jan 31, 2022
Merged

add desc of capacity fallback #1204

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
a9279cb
add desc of capacity fallback
geoffcline Jan 22, 2022
bd1e656
Apply suggestions from code review
geoffcline Jan 28, 2022
b93ef35
remove details of cache time
geoffcline Jan 28, 2022
c1c925f
Merge branch 'main' into gdc-capacity-fallback
geoffcline Jan 31, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions website/content/en/preview/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -95,6 +95,12 @@ If the instance type is unavailable for some reason, then fleet will move on to
If you are using the spot capacity type, Karpenter uses the capacity-optimized-prioritized allocation strategy which tells fleet to find the instance type that EC2 has the most capacity of which will decrease the probability of a spot interruption happening in the near term.
See [Choose the appropriate allocation strategy](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html#ec2-fleet-allocation-use-cases) for information on fleet optimization.

### What if there is no spot capacity? Will Karpenter fallback to on-demand?

Karpenter will fallback to on-demand, if your provisioner specifies both spot and on-demand.

More specifically, Karpenter maintains a concept of "offerings" for each instance type, which is a combination of zone and capacity type (equivalent in the AWS cloud provider to an EC2 purchase option). Spot offerings are prioritized, if they're available. Whenever the Fleet API returns an insufficient capacity error for Spot instances, those particular offerings are temporarily removed from consideration (across the entire provisioner) so that Karpenter can make forward progress through fallback. The retry will happen immediately within milliseconds.

## Workloads

### How can someone deploying pods take advantage of Karpenter?
Expand Down
6 changes: 4 additions & 2 deletions website/content/en/preview/provisioner.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -139,11 +139,13 @@ Karpenter supports `amd64` nodes, and `arm64` nodes.
☁️ **AWS**

- values
- `spot` (default)
- `on-demand`
- `spot`
- `on-demand` (default)

Karpenter supports specifying capacity type, which is analogous to [EC2 purchase options](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html).

Karpenter prioritizes Spot offerings if the provisioner allows Spot and on-demand instances. If the provider API (e.g. EC2 Fleet's API) indicates Spot capacity is unavailable, Karpenter caches that result across all attempts to provision EC2 capacity for that instance type and zone for the next 45 seconds. If there are no other possible offerings available for Spot, Karpenter will attempt to provision on-demand instances, generally within milliseconds.


## spec.kubeletConfiguration

Expand Down