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

docs: Update to remove drift feature gate reference #7056

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

Conversation

engedaam
Copy link
Contributor

Fixes #N/A

Description

  • Remove drift feature gate reference
  • Add note on drift having a one node replacement

How was this change tested?

Does this change impact docs?

  • Yes, PR includes docs updates
  • Yes, issue opened: #
  • No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@engedaam engedaam requested a review from a team as a code owner September 23, 2024 13:55
Copy link

netlify bot commented Sep 23, 2024

Deploy Preview for karpenter-docs-prod ready!

Name Link
🔨 Latest commit 7d3bd96
🔍 Latest deploy log https://app.netlify.com/sites/karpenter-docs-prod/deploys/66f17340f9f6d70008865f0c
😎 Deploy Preview https://deploy-preview-7056--karpenter-docs-prod.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@coveralls
Copy link

Pull Request Test Coverage Report for Build 10995796888

Details

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.02%) to 83.01%

Totals Coverage Status
Change from base Build 10989352480: 0.02%
Covered Lines: 5521
Relevant Lines: 6651

💛 - Coveralls

@@ -133,7 +133,7 @@ Karpenter requires a minimum instance type flexibility of 15 instance types when


### Drift
Drift handles changes to the NodePool/EC2NodeClass. For Drift, values in the NodePool/EC2NodeClass are reflected in the NodeClaimTemplateSpec/EC2NodeClassSpec in the same way that they’re set. A NodeClaim will be detected as drifted if the values in its owning NodePool/EC2NodeClass do not match the values in the NodeClaim. Similar to the upstream `deployment.spec.template` relationship to pods, Karpenter will annotate the owning NodePool and EC2NodeClass with a hash of the NodeClaimTemplateSpec to check for drift. Some special cases will be discovered either from Karpenter or through the CloudProvider interface, triggered by NodeClaim/Instance/NodePool/EC2NodeClass changes.
Drift handles changes to the NodePool/EC2NodeClass. For Drift, values in the NodePool/EC2NodeClass are reflected in the NodeClaimTemplateSpec/EC2NodeClassSpec in the same way that they’re set. A NodeClaim will be detected as drifted if the values in its owning NodePool/EC2NodeClass do not match the values in the NodeClaim. Similar to the upstream `deployment.spec.template` relationship to pods, Karpenter will annotate the owning NodePool and EC2NodeClass with a hash of the NodeClaimTemplateSpec to check for drift. Some special cases will be discovered either from Karpenter or through the CloudProvider interface, triggered by NodeClaim/Instance/NodePool/EC2NodeClass changes. Karpenter will add the `Drifted` status condition on NodeClaims if the NodeClaim is drifted from its owning NodePool.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
Drift handles changes to the NodePool/EC2NodeClass. For Drift, values in the NodePool/EC2NodeClass are reflected in the NodeClaimTemplateSpec/EC2NodeClassSpec in the same way that they’re set. A NodeClaim will be detected as drifted if the values in its owning NodePool/EC2NodeClass do not match the values in the NodeClaim. Similar to the upstream `deployment.spec.template` relationship to pods, Karpenter will annotate the owning NodePool and EC2NodeClass with a hash of the NodeClaimTemplateSpec to check for drift. Some special cases will be discovered either from Karpenter or through the CloudProvider interface, triggered by NodeClaim/Instance/NodePool/EC2NodeClass changes. Karpenter will add the `Drifted` status condition on NodeClaims if the NodeClaim is drifted from its owning NodePool.
Drift handles changes to the NodePool/EC2NodeClass. For Drift, values in the NodePool/EC2NodeClass are reflected in the NodeClaimTemplateSpec/EC2NodeClassSpec in the same way that they’re set. A NodeClaim will be detected as drifted if the values in its owning NodePool/EC2NodeClass do not match the values in the NodeClaim. Similar to the upstream `deployment.spec.template` relationship to pods, Karpenter will annotate the owning NodePool and EC2NodeClass with a hash of the NodeClaimTemplateSpec to check for drift. Some special cases will be discovered either from Karpenter or through the CloudProvider interface, triggered by NodeClaim/Instance/NodePool/EC2NodeClass changes. Karpenter will add the `Drifted` status condition on NodeClaims if the NodeClaim is drifted from its owning NodePool or owning EC2NodeClass.

Since you callout that we mark drift for both objects in a previous statement, should probably also call it out here too

@@ -327,3 +321,7 @@ spec:
budgets:
- nodes: "0"
```

{{% alert title="Note" color="primary" %}}
Unlike other form of disruption, Karpenter will drift nodes by launching one replacement node at a time despite nodepool budget allowing for more then one node. The process will wait until the replacement node is ready and initialized before beginning to launch a new node. Karpenter disrupts and upgrades your nodes, prioritizing availability and safety to your applications.
Copy link
Contributor

Choose a reason for hiding this comment

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

I almost think that we shouldn't include this. This is a bit misleading given what we actually do. We allow more nodes to be disrupted while we are waiting for that other node to go initialized -- up to the budget

Copy link
Contributor

Choose a reason for hiding this comment

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

I sort of agree. I think we want to let users know that we enqueue nodes for disruption, but be clear that we're not only going to do one at a time all the time.

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.

4 participants