mirrors/node-feature-discovery
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/node-feature-discovery.git synced 2024-12-14 11:57:51 +00:00
Code Activity

Merge pull request #1454 from marquiz/devel/docs-ers

Browse source 
docs: stop advertising --resource-labels flag
This commit is contained in:
Kubernetes Prow Robot 2023-11-08 10:39:50 +01:00 committed by GitHub
commit 9527b69972
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

38
docs/usage/features.md
View file

@ -251,35 +251,19 @@ detailed documentation.
## Extended resources
This feature is experimental and by no means a replacement for the usage of
device plugins.
NFD is able to create extended resources, see the
[NodeFeatureRule](custom-resources.md#nodefeaturerule) CRD and its
[extendedResources](#customization-guide.md#extendedresources) field for more
details.
Labels which have integer values, can be promoted to Kubernetes extended
resources by listing them to the master `-resource-labels` command line flag.
These labels won't then show in the node label section, they will appear only
as extended resources.
Note that NFD is not a replacement for the usage of device plugins.
An example use-case for the extended resources could be based on a hook which
creates a label for the node SGX EPC memory section size. By giving the name of
that label in the `-resource-labels` flag, that value will then turn into an
extended resource of the node, allowing PODs to request that resource and the
Kubernetes scheduler to schedule such PODs to only those nodes which have a
sufficient capacity of said resource left.
Similar to labels, the default namespace `feature.node.kubernetes.io` is
automatically prefixed to the extended resource, if the promoted label doesn't
have a namespace.
Example usage of the command line arguments, using a new namespace:
`nfd-master -resource-labels=my_source-my.feature,sgx.some.ns/epc -extra-label-ns=sgx.some.ns`
The above would result in following extended resources provided that related
labels exist:
```plaintext
sgx.some.ns/epc: <label value>
feature.node.kubernetes.io/my_source-my.feature: <label value>
```
An example use-case for extended resources could be based on custom feature
(created e.g. with [feature files](#customization-guide.md#feature-files) that
exposes the node SGX EPC memory section size. This value will then be turned
into an extended resource of the node, allowing PODs to request that resource
and the Kubernetes scheduler to schedule such PODs to only those nodes which
have a sufficient capacity of said resource left.
<!-- Links -->
[klauspost-cpuid]: https://github.com/klauspost/cpuid#x86-cpu-instructions