-
Notifications
You must be signed in to change notification settings - Fork 238
-
Notifications
You must be signed in to change notification settings - Fork 238
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
KEP: NodeFeatureGroup API (CRD) #1423
Comments
/assign |
@ArangoGutierrez Do you mind clarifying on I am trying to understand what is it you are looking for. There are multiple multi-cluster management tools already available, is this a feature request? or do you have a specific product/project in mind you want to extend? |
Sure, as I said
When I refer to a single API, I am saying that instead of having to query all the nodes for the created labels (NFD Labels), the new |
would there be a way that this work intersects with the open-cluster-management project? https://open-cluster-management.io/ |
Hey! |
right! let me get more specific, |
I also got a bit of a heads-up from an engineer that works in o-c-m, and he shared some additional insights
|
Hey! we would love to help |
To my understanding, this is to collect features in a cluster and have a singleton API in this cluster to summarize all the features from nodes? This is a bit different from cluster-inventory-api, since the latter requires a cluster management control plane. However I think there is another project seeming similar from sig-mc (https://github.com/kubernetes-sigs/about-api) to introduce a |
A lot of action in this space. A few random thoughts from an uneducated person:
|
I was tagged in slack about this :) |
yes, that is the plan. |
@ArangoGutierrez I think I understand the change now, and I agree this would be great for Fluence. Do you want any help? |
Is this KEP actively being worked on? If not, happy to get the ball rolling by creating a first draft. |
yes, this week we are just getting attention from the community, before working on it |
@ArangoGutierrez is this KEP concern the creation of ClusterFeature CR in the cluster, or it will also try to integrate with cluster management by extending, for example ClusterClaim? |
Hey! 👋🏻 I'm curious about what cluster features would be exposed exactly. kcp (which is mentioned in the initial description and was notified of this) in specific is not dealing with compute workloads directly, so aggregation of NFD-discovered features would not relate to it. Because of that, I'm mostly interested in this part:
Are there any clear ideas what examples there could be beyond network config? |
All, me here to lead, what is this intersection NFD y'all are talking about, I assume it could reduce k8 costs What do I need to study to contribute |
Hi @yevgeny-shnaidman , it is a Non-goal to walk into cluster management territory |
Hey @embik ! we are gathering requests from multiple places. |
@ArangoGutierrez are we going to add something like NodeFeatureRules for the new CRD? i am guessing that it can come useful to determine if cluster supports GPU loads etc' |
|
Yes, maybe this could be a further addition/enhancement if some rule-based aggregation of features would be needed |
I'm trying to understand what |
Hey, sure! You can find all the feature sources NFD discovers and advertise on a per-Node basis here -> https://kubernetes-sigs.github.io/node-feature-discovery/v0.14/usage/features.html#table-of-contents |
For all those interested I have filed #1487 |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
Summary
The Kubernetes cluster object doesn't expose all available features in a programmatic way.
When working in a MultiCluster environment (example kcp, hypershift ) the central control plane can not access all the available features on each cluster, making it hard to take scheduling and management decisions.
The Node-Feature-Discovery does a good work for exposing a per-node basis feature inventory but querying each cluster in a per-node basis can be a network intensive task. Various use cases have been identified where having a cluster inventory would facilitate operations at the Cluster management level.
This KEP proposes NFD to expose an inventory of available features in the cluster via a new API (CRD)
Goals
Non-Goals
Proposal
User Stories
Story 1
As a platform engineer, I want to known the available features on each cluster registered on my network to be able to make optimal, platform specific, scheduling decisions.
Story 2
As a System-Admin I want a single API to know the available features of each cluster on the network.
resource allocations.
CRD API
The text was updated successfully, but these errors were encountered: