[EKS] Karpenter inside control plane

[James-Quigley]

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

Tell us about your request
It would be really useful if EKS came pre-installed with Karpenter running in the control plane. Currently with Karpenter you have to first setup at least one nodegroup for Karpenter, then Karpenter can manage the rest.

If the control plane ran Karpenter for you, then there wouldn't be a need for any management of nodegroups for customers.

Which service(s) is this request for?
EKS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
As an EKS cluster manager, when creating a cluster I have to bootstrap it with various tools as well as enough resources to run workloads. Also as a user of Karpenter, this requires setting up a nodegroup (managed), installing Karpenter and limiting it to run on that nodegroup before deploying other workloads.

This also means that as a cluster manager I need to be aware of the two different node setups: managed nodegroups and Karpenter nodes.

Are you currently working around this issue?
Currently we deploy managed nodegroups, then karpenter.

Additional context
Sort of similar to #47

[krmayankk]

Karpenter doesnt use ASG's and hence its availability is of paramount importance (equal to the availability requirement of ASG itself). Is that the main reason you use managed node group to run Karpenter ? You could technically run Karpenter in a node group managed by ASG as well. Would help to understand why that would not work ?
Overall I support it being available as pre-installed and managed by EKS, but looking for how other teams are currently using it ? Also is Karpenter production ready ?

[stevehipwell]

@krmayankk Karpenter has been ready for production for almost a year at this point.

I'd love to see Karpenter running as part of the control plane, otherwise I have to managed separate node groups which don't have the best ergonomics for upgrades.

[runningman84]

I run karpenter using eks fargate which is a good solution until karpenter moves to the control plane itself.

[HenryYanTR]

Same here, running Karpenter in fargate. Feel it's a perfect fit for EKS control plane.

[danielloader]

I'd feel happier if I could use fargate spot instances but it's a compromise.

[abebars]

@mikestef9 Any thoughts on when this is going to become available? Also happy to work on some testing when it's ready for that.

[KuldeepSharmaTR]

@mikestef9 Any thoughts on when this is going to become available? Also happy to work on some testing when it's ready for that.

I believe it will be available after coming re:invent..!!

[kasvith]

I was also looking for this, we were setting up a ng only for karpenter, but if it can run on control plane...the problem is gone

[duxing]

would love to EKS control plan enhancement on supporting dedicated hardware for karpenter control plane without us having to manage fargate or EKS node group.

maturity improvements like this would benefit the adoption for both EKS and karpenter.

[deimosfr]

Hi,

Could we have more information about the implementation? How will it work? What will be the required setup compared to current EKS etc...

Thanks

[zendz]

Hello,

Do you have any update this?.

I need this feature.

[kr3cj]

If we're already managing karpenter ourselves (using Fargate/MNGs/whatever), I'm curious how cutting over to the karpenter-inside-control-plane would look/work.

[FernandoMiguel]

If we're already managing karpenter ourselves (using Fargate/MNGs/whatever), I'm curious how cutting over to the karpenter-inside-control-plane would look/work.

i would expect us to provide our own provisioners, let the managed karpenter create new nodes, and set the existing ones as unscheduled, so workloads move