Intro carpenter #2425
Open
Intro carpenter #2425
+167
−16
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
marians
reviewed
Dec 17, 2024
src/content/tutorials/fleet-management/cluster-management/cluster-scaling/_index.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Marian Steinbach <[email protected]>
|
This PR moves/renames or deletes some files. Please make sure to
|
|
Hugo yielded some warnings. Please check whether they require action. |
pipo02mix
commented
Dec 17, 2024
| To avoid collisions between both, the cluster autoscaler is configured to have a lower priority than `Karpenter`, so it will react only after a pod is on `Pending` for a while (default 5 minutes). | ||
|
|
||
| ## Configuration | ||
|
|
There was a problem hiding this comment.
@T-Kukawka does it come installed in CAPA WC by default?
There was a problem hiding this comment.
It doesn't come pre-installed. And therefore, we should clarify at the top of the article that it's a custom addition at the moment, while cluster-autoscaler is built-in and works fine out of the box.
iuriaranda
reviewed
Dec 31, 2024
|
|
||
| At Giant Swarm, your workload clusters run with [cluster autoscaler](https://github.com/kubernetes/autoscaler) and [`Karpenter`](https://karpenter.sh/) to reach optimal scaling for your workloads and keeping the costs at minimum. This tutorial will guide you through the configuration and management of both. | ||
|
|
||
| The cluster autoscaler is responsible for scaling the number of nodes on the different node pools of your workload cluster. It's triggered by not schedule pods, pods in `Pending` state, making the controller increase the number of desired nodes in the node pool. Indeed it modifies the `AutoScalingGroup` to reflect the new desired capacity. |
There was a problem hiding this comment.
Suggested change
| The cluster autoscaler is responsible for scaling the number of nodes on the different node pools of your workload cluster. It's triggered by not schedule pods, pods in `Pending` state, making the controller increase the number of desired nodes in the node pool. Indeed it modifies the `AutoScalingGroup` to reflect the new desired capacity. | |
| The cluster autoscaler is responsible for scaling the number of nodes on the different node pools of your workload cluster. It's triggered by not scheduled pods, pods in `Pending` state, making the controller increase the number of desired nodes in the node pool. Indeed it modifies the `AutoScalingGroup` to reflect the new desired capacity. |
|
|
||
| The cluster autoscaler is responsible for scaling the number of nodes on the different node pools of your workload cluster. It's triggered by not schedule pods, pods in `Pending` state, making the controller increase the number of desired nodes in the node pool. Indeed it modifies the `AutoScalingGroup` to reflect the new desired capacity. | ||
|
|
||
| Instead, `Karpenter` relies on the Kubernetes events to scale up or down the number of nodes in the cluster. It's select from a suite of instance types defined in a special `Provisioner` resources to match the workload requirements and can be configured to use spot instances to save costs. It's faster and more efficient than the cluster autoscaler, but does not operate well with base on-demand instances. |
There was a problem hiding this comment.
Why do you say it doesn't operate well with base on-demand instances?
|
|
||
| Our recommendation for the autoscaling configuration is to set two different profiles. One will target `Spot` compute and the other `On-Demand` instances. The `Spot` profile will have a higher weight to be prioritized over the `On-Demand` profile. And the `on-demand` profile will ensure that the cluster has a base capacity to handle the main workloads. | ||
|
|
||
| First, let's dive in what is a `Provisioner` custom resource to understand how to configure it. There are a set of parameters to help you define how the nodes should be provisioned: |
There was a problem hiding this comment.
Suggested change
| First, let's dive in what is a `Provisioner` custom resource to understand how to configure it. There are a set of parameters to help you define how the nodes should be provisioned: | |
| First, let's dive into what a `Provisioner` custom resource is to understand how to configure it. There are a set of parameters to help you define how the nodes should be provisioned: |
| First, let's dive in what is a `Provisioner` custom resource to understand how to configure it. There are a set of parameters to help you define how the nodes should be provisioned: | ||
|
|
||
| - **labels**: Used to select which nodes should be managed by the provisioner. | ||
| - **limits**: Define the resources limits for the nodes. |
There was a problem hiding this comment.
Suggested change
| - **limits**: Define the resources limits for the nodes. | |
| - **limits**: Lets you set limits on the total CPU and Memory that can be used by the node pool, effectively stopping further node provisioning when those limits have been reached. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it
Towards https://github.com/giantswarm/giantswarm/issues/29503
Things to check/remember before submitting
last_review_datein the front matter header of the pages you've touched.