Node classification mechnism based on workload profiles

[digambar15]

User Story

As a user/operator I would like to introduce mechnism which will classify nodes based on workload profiles so that I will get right match of node before deployment any workloads/applications.

Detailed Description

Custer-api will create multiple clusters at any cloud be it VMware, GCP, AWS or Baremetal etc.
If some user is looking for worker-node where he will run his workloads on pods. But he has very specific requirements like he wants node should have minimum Memory/Storage/CPU's so that he can deploy his app on the pod with specific node Or in some cases, he has very specific hardware configuration for node which is required for his workloads, in that case, he has to go through every cluster and find right match would be difficult job for him.

So I am proposing here classification framework where user will define what of hardware configuration required for his workload, this CRD/mechanism will filter out all the worker nodes where it will find right match to his/her workload profile.

This approach will help not only filtering the hosts, but also will help implement many more classification filters/algorithms which will make users life easy in future.

/kind feature

[detiber]

@digambar15 I'm trying to understand the requirements/UX you are looking for here.

At a high level, I would say that this feels very much analogous to node feature discovery, however that would only be helpful in the context of a single workload cluster.

We could potentially replicate the labels that node-feature-discovery adds to Nodes to the Machines/MachinePools that we manage in Cluster API, but that still feels like an awkward UX to me for the end user (query all Machines in Clusters that I have access to and filter on these labels), just to find the right Cluster to target and then replicate those labels as a Node Selector on the deployment that I create.

I feel like to achieve a good user experience around this, we need to target at least a portion of the functionality towards either developer tooling or an application management layer. With that being the case, it is not too much of a stretch to also have that layer do the Machine -> Node mapping for the node feature detection labels rather than relying on Cluster API to ensure that the labels are in sync on a Machine resource.

[vincepri]

/milestone Next
/kind design
/priority awaiting-more-evidence

[digambar15]

Hey @detiber, @vincepri,

Sorry for late reply.

As an Operator or User, I have some kind of workloads / application needs very specific hardware configuration on my cluster. Find a right matching host in cluster will be headache and on top of this, we will have to go and check whether we have matched hardware configuration available on that host or not.
Agree, this idea is relying on cluster-api but not needed any modification in cluster-api directly.
but looking at future requirements, we need some kind of classification framework to filter out hosts for this kind scenarios. I am thinking in this cases, we should fetch only unowned hosts under MachineSet and label them for specific hardware/workload profile.
In future, we can add many classification filter like -
Minimum, RAMFilter, DiskFilter, CPUFilter, GPUFilter etc

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[randomvariable]

/lifecycle frozen

[vincepri]

Closing this in favor of #3150

This information might be exposed in the future, and folks should be able to use it outside of Cluster API

[vincepri]

/close

[k8s-ci-robot]

@vincepri: Closing this issue.

In response to this:

/close

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.