• ✅login: leoryu / (ec4bbf2)

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: leoryu
Once this PR has been reviewed and has the lgtm label, please assign ellistarn for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Welcome @leoryu!

It looks like this is your first PR to kubernetes-sigs/karpenter 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/karpenter has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

Hi @leoryu. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Pull Request Test Coverage Report for Build 10789870773

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 5 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-0.02%) to 80.552%

Totals
Change from base Build 10729017085:	-0.02%
Covered Lines:	8379
Relevant Lines:	10402

💛 - Coveralls

Why is this a chore to you rather than a feature request? This would be a very very large change to our scheduling algorithm, as it's an invariant that spot prices will always be cheaper than on-demand prices. Obviously this may change between cloud providers. How is it impacting you?

Why is this a chore to you rather than a feature request? This would be a very very large change to our scheduling algorithm, as it's an invariant that spot prices will always be cheaper than on-demand prices. Obviously this may change between cloud providers. How is it impacting you?

@njtran If the nodeclaim is for 8C 16G OD instance type, and here is an 2c 4G OD instance type (no available spot) which is cheaper and meets the all pods requirements. For this case, the karpenter will trigger the consolidation, but since the nodeclaim will be forced to set spot:

{"level":"INFO","time":"2024-09-23T06:27:22.627Z","logger":"controller","message":"disrupting nodeclaim(s) via replace, terminating 1 nodes (1 pods) {node-name}/{instance-type}/on-demand and replacing with spot node from types {instance-type},{instance-type}, {instance-type}","controller":"disruption","namespace":"","name":"","reconcileID":"4de5441d-b9a7-4089-afe0-7762b5b640cc","command-id":"6f8ef575-d844-410a-a4e0-709af27d36d8","reason":"underutilized"}

The controller will get an error:

{"level":"ERROR","time":"2024-09-23T06:27:00.080Z","logger":"controller","message":"failed launching nodeclaim","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"test-njk7n"},"namespace":"","name":"test-njk7n","reconcileID":"333a7dec-4354-4076-9015-6db7eb5f69bf","error":"insufficient capacity, all requested instance types were unavailable during launch"}

Setting spot as preferred selection makes sense, but karpenter should consider whether the spot is available or not.

This PR has been inactive for 14 days. StaleBot will close this stale PR after 14 more days of inactivity.

Why is this a chore to you rather than a feature request? This would be a very very large change to our scheduling algorithm, as it's an invariant that spot prices will always be cheaper than on-demand prices. Obviously this may change between cloud providers. How is it impacting you?

@njtran If the nodeclaim is for 8C 16G OD instance type, and here is an 2c 4G OD instance type (no available spot) which is cheaper and meets the all pods requirements. For this case, the karpenter will trigger the consolidation, but since the nodeclaim will be forced to set spot:

{"level":"INFO","time":"2024-09-23T06:27:22.627Z","logger":"controller","message":"disrupting nodeclaim(s) via replace, terminating 1 nodes (1 pods) {node-name}/{instance-type}/on-demand and replacing with spot node from types {instance-type},{instance-type}, {instance-type}","controller":"disruption","namespace":"","name":"","reconcileID":"4de5441d-b9a7-4089-afe0-7762b5b640cc","command-id":"6f8ef575-d844-410a-a4e0-709af27d36d8","reason":"underutilized"}

The controller will get an error:

{"level":"ERROR","time":"2024-09-23T06:27:00.080Z","logger":"controller","message":"failed launching nodeclaim","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"test-njk7n"},"namespace":"","name":"test-njk7n","reconcileID":"333a7dec-4354-4076-9015-6db7eb5f69bf","error":"insufficient capacity, all requested instance types were unavailable during launch"}

Setting spot as preferred selection makes sense, but karpenter should consider whether the spot is available or not.

Hi, please check this comment at your convenience. @njtran

This PR has been inactive for 14 days. StaleBot will close this stale PR after 14 more days of inactivity.