Karpenter as default scheduler

[runningman84]

Tell us about your request

Right now karpenter is simulating how the kube-scheduler would react in a given scenario. The simulation by karpenter and final decision by kube-scheduler is also not happening at the exact same time.

Maybe it would make sense to have karpenter as a replacement for kube-scheduler?

If it can simulate scheduling decision anyway, it should not be a big effort to replace it completely?

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?

na

Are you currently working around this issue?

na

Additional Context

Default scheduler could be changed like this:
https://stackoverflow.com/questions/63830665/how-to-change-default-kube-scheduler-in-kubernetes

Attachments

No response

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[bwagner5]

This is something we have entertained. In fact, Karpenter previously performed the scheduling operation by binding the pods directly to the nodes (even though Karpenter was not the configured scheduler). We've been moving away from doing more non-standard things and trying to stay in-line with kube-scheduler. There may be some things that would be easier if Karpenter were a custom scheduler but configuring a cluster with a custom scheduler tends to be a more intrusive thing to do than to just work with kube-scheduler, so we likely won't take that path unless there's a significant benefit in doing-so and the experience doesn't degrade of an installation and configuration perspective.

Are there specific problems you are encountering where Karpenter's simulated scheduling decisions do not match what kube-scheduler actually does? We are aware that kube-scheduler can make different decisions but these usually only result in temporary inefficiencies which can solved with Karpenter's consolidation mechanism.

[runningman84]

I do not see a real problem here, I was just thinking about possible inefficiencies...

[runningman84]

This is the first real problem we have seen: aws/karpenter-provider-aws#3577

[LorenzoLou]

This is something we have entertained. In fact, Karpenter previously performed the scheduling operation by binding the pods directly to the nodes (even though Karpenter was not the configured scheduler). We've been moving away from doing more non-standard things and trying to stay in-line with kube-scheduler. There may be some things that would be easier if Karpenter were a custom scheduler but configuring a cluster with a custom scheduler tends to be a more intrusive thing to do than to just work with kube-scheduler, so we likely won't take that path unless there's a significant benefit in doing-so and the experience doesn't degrade of an installation and configuration perspective.

Are there specific problems you are encountering where Karpenter's simulated scheduling decisions do not match what kube-scheduler actually does? We are aware that kube-scheduler can make different decisions but these usually only result in temporary inefficiencies which can solved with Karpenter's consolidation mechanism.

Hi @bwagner5 very excited to see your awesome answer here. I'm a fan of this project, but many of my friends also have the same question that why in provisioner we need to simulated scheduling decisions? In code level, we see that the provisioner will try to schedule a pod to an Existingnode first (we can see Existingnode keeps the relations with pods running on it) and we can see the corresponding logs of nomination, but we really don't get the point that why we need to predict the kube-scheduler's behaviour when it is trying to "schedule" a pod to an ExistingNode.(I'm referring to scheduler.solve() method, it will try to list all the existing node first to see if there is any node can be suitable to a pod. but this process is just like a prediction of "bind").

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.