aws / aws/containers-roadmap

[EKS] [request]: Using Karpenter in a multi-tenancy EKS Cluster - Need to assign Label to Worker nodes with namespace name

Open
#1,966 2 comments 1 reaction 0 assignees View on GitHub
EKS OSS Proposed
Dominant language
Shell
Stars
5.4k
Forks
334
PR merge metrics
No merged PRs in 30d

Description

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) 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**
What do you want us to build?

- We planning to use Karpenter for autoscaling in our EKS clusters, this is a multi-tenant EKS clusters and each tenant should have the ability to choose and create there own worker nodes based on their own workload requirements.
- As a platform team we need to know which worker nodes realted to which team so we need to enforce kind or labeling to worker nodes on Karpenter and EKS scheduler to enforce this labeling strategy for each Name Space ( tenant ).
- Using OPA GK or Kybverno is not really efficient ion this situation today in our environment, enforcing multi-tenancy with the OPA brings a lot of problems on our side, basically we will have to think of a lot of integrations and policing. Therefore Karpenter will be narrowed to few or little use-cases/clients within our org.
- We are looking to have Karpenter and EKS Scheduler to be more multi-tenant friendly by having at least Provisioner CRD has to have a namespace.
-
**Which service(s) is this request for?**
EKS, Karpenter

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.

- We looking to have Karpenter more Multi-tenant friendly by having a namespace spec on it's CRDs so we can know which namespace those worker nodes related to.
- We will not be able to use Karpenter in our environment due to this missing capabilities.

**Are you currently working around this issue?**
How are you currently solving this problem?

- Using OPA GK to Mutate Pods with Toleration and NodeSelector and assign labels to the newly created nodes whenever Karpenter add them.

This is not really working on a large scale!!
**Additional context**
Anything else we should know?

This is blocking us on Certifying Karpenter within our environment.
**Attachments**
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

Contributor guide

Open the contributing guide

Research direction

No repository files or tests are named. Start by reviewing how Karpenter Provisioner CRDs and EKS scheduling currently handle tenant-specific nodes, then define the namespace and labeling behavior needed for multi-tenancy. Done means tenant workloads can create and identify appropriately labeled worker nodes without relying on OPA Gatekeeper or Kyverno.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, kubernetes
Domain
cloud, devops, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.