mirrors/node-feature-discovery
mirrors/node-feature-discovery
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/node-feature-discovery.git synced 2025-03-15 21:08:23 +00:00
Code Activity

docs: unify formatting of NOTEs

Browse source
This commit is contained in:
Markus Lehtonen 2023-08-03 13:38:07 +03:00
parent 45dc46ab81
commit 0a8b514d67
13 changed files with 120 additions and 118 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
docs/deployment/helm.md
View file

@ -17,9 +17,9 @@ sort: 3
Node Feature Discovery Helm chart allow to easily deploy and manage NFD. Node Feature Discovery Helm chart allow to easily deploy and manage NFD.
> NOTE: NFD is not ideal for other Helm charts to depend on as that may result > **NOTE:** NFD is not ideal for other Helm charts to depend on as that may
> in multiple parallel NFD deployments in the same cluster which is not fully > result in multiple parallel NFD deployments in the same cluster which is not
> supported by the NFD Helm chart. > fully supported by the NFD Helm chart.
## Prerequisites ## Prerequisites

12
docs/deployment/kustomize.md
View file

@ -32,9 +32,9 @@ kubectl apply -k https://github.com/kubernetes-sigs/node-feature-discovery/deplo
This will required RBAC rules and deploy nfd-master (as a deployment) and This will required RBAC rules and deploy nfd-master (as a deployment) and
nfd-worker (as daemonset) in the `node-feature-discovery` namespace. nfd-worker (as daemonset) in the `node-feature-discovery` namespace.
**NOTE:** nfd-topology-updater is not deployed as part of the `default` overlay. > **NOTE:** nfd-topology-updater is not deployed as part of the `default`
Please refer to the [Master Worker Topologyupdater](#master-worker-topologyupdater) > overlay. Please refer to the [Master Worker Topologyupdater](#master-worker-topologyupdater)
and [Topologyupdater](#topologyupdater) below. > and [Topologyupdater](#topologyupdater) below.
Alternatively you can clone the repository and customize the deployment by Alternatively you can clone the repository and customize the deployment by
creating your own overlays. For example, to deploy the creating your own overlays. For example, to deploy the
@ -86,9 +86,9 @@ This creates a DaemonSet that runs nfd-worker and nfd-master in the same Pod.
In this case no nfd-master is run on the master node(s), but, the worker nodes In this case no nfd-master is run on the master node(s), but, the worker nodes
are able to label themselves which may be desirable e.g. in single-node setups. are able to label themselves which may be desirable e.g. in single-node setups.
**NOTE:** nfd-topology-updater is not deployed by the default-combined overlay. > **NOTE:** nfd-topology-updater is not deployed by the default-combined
To enable nfd-topology-updater in this scenario,the users must customize the > overlay. To enable nfd-topology-updater in this scenario,the users must
deployment themselves. > customize the deployment themselves.
### Worker one-shot ### Worker one-shot

4
docs/deployment/uninstallation.md
View file

@ -26,5 +26,5 @@ kubectl -n node-feature-discovery wait job.batch/nfd-master --for=condition=comp
kubectl delete -k https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/prune?ref={{ site.release }} kubectl delete -k https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/prune?ref={{ site.release }}
``` ```
**NOTE:** You must run prune before removing the RBAC rules (serviceaccount, > **NOTE:** You must run prune before removing the RBAC rules (serviceaccount,
clusterrole and clusterrolebinding). > clusterrole and clusterrolebinding).

39
docs/developer-guide/index.md
View file

@ -197,12 +197,12 @@ $ docker run --rm --network=container:nfd-test ${NFD_CONTAINER_IMAGE} nfd-worker
If you just want to try out feature discovery without connecting to nfd-master, If you just want to try out feature discovery without connecting to nfd-master,
pass the `-no-publish` flag to nfd-worker. pass the `-no-publish` flag to nfd-worker.
**NOTE** Some feature sources need certain directories and/or files from the > **NOTE:** Some feature sources need certain directories and/or files from the
host mounted inside the NFD container. Thus, you need to provide Docker with the > host mounted inside the NFD container. Thus, you need to provide Docker with
correct `--volume` options in order for them to work correctly when run > the correct `--volume` options in order for them to work correctly when run
stand-alone directly with `docker run`. See the > stand-alone directly with `docker run`. See
[default deployment](https://github.com/kubernetes-sigs/node-feature-discovery/blob/{{site.release}}/deployment/components/common/worker-mounts.yaml) > the [default deployment](https://github.com/kubernetes-sigs/node-feature-discovery/blob/{{site.release}}/deployment/components/common/worker-mounts.yaml)
for up-to-date information about the required volume mounts. > for up-to-date information about the required volume mounts.
### NFD-Topology-Updater ### NFD-Topology-Updater
@ -218,20 +218,19 @@ $ docker run --rm --network=container:nfd-test ${NFD_CONTAINER_IMAGE} nfd-topolo
If you just want to try out feature discovery without connecting to nfd-master, If you just want to try out feature discovery without connecting to nfd-master,
pass the `-no-publish` flag to nfd-topology-updater. pass the `-no-publish` flag to nfd-topology-updater.
NOTE: > **NOTE:** NFD topology updater needs certain directories and/or files from
> the host mounted inside the NFD container. Thus, you need to provide Docker
NFD topology updater needs certain directories and/or files from the > with the correct `--volume` options in order for them to work correctly when
host mounted inside the NFD container. Thus, you need to provide Docker with the > run stand-alone directly with `docker run`. See
correct `--volume` options in order for them to work correctly when run > the [template spec](https://github.com/kubernetes-sigs/node-feature-discovery/blob/{{site.release}}/deployment/components/topology-updater/topologyupdater-mounts.yaml)
stand-alone directly with `docker run`. See the > for up-to-date information about the required volume mounts.
[template spec](https://github.com/kubernetes-sigs/node-feature-discovery/blob/{{site.release}}/deployment/components/topology-updater/topologyupdater-mounts.yaml) >
for up-to-date information about the required volume mounts. > [PodResource API][podresource-api] is a prerequisite for
> nfd-topology-updater. Preceding Kubernetes v1.23, the `kubelet` must be
[PodResource API][podresource-api] is a prerequisite for nfd-topology-updater. > started with the following flag:
Preceding Kubernetes v1.23, the `kubelet` must be started with the following flag: > `--feature-gates=KubeletPodResourcesGetAllocatable=true`. Starting
`--feature-gates=KubeletPodResourcesGetAllocatable=true`. > Kubernetes v1.23, the `GetAllocatableResources` is enabled by default through
Starting Kubernetes v1.23, the `GetAllocatableResources` is enabled by default > `KubeletPodResourcesGetAllocatable` [feature gate][feature-gate].
through `KubeletPodResourcesGetAllocatable` [feature gate][feature-gate].
## Running with Tilt ## Running with Tilt

4
docs/get-started/introduction.md
View file

@ -107,8 +107,8 @@ NFD also annotates nodes it is running on:
| [<instance>.]nfd.node.kubernetes.io/feature-labels | Comma-separated list of node labels managed by NFD. NFD uses this internally so must not be edited by users. | [<instance>.]nfd.node.kubernetes.io/feature-labels | Comma-separated list of node labels managed by NFD. NFD uses this internally so must not be edited by users.
| [<instance>.]nfd.node.kubernetes.io/extended-resources | Comma-separated list of node extended resources managed by NFD. NFD uses this internally so must not be edited by users. | [<instance>.]nfd.node.kubernetes.io/extended-resources | Comma-separated list of node extended resources managed by NFD. NFD uses this internally so must not be edited by users.
NOTE: the [`-instance`](../reference/master-commandline-reference.md#instance) > **NOTE:** the [`-instance`](../reference/master-commandline-reference.md#instance)
command line flag affects the annotation names > command line flag affects the annotation names
Unapplicable annotations are not created, i.e. for example master.version is Unapplicable annotations are not created, i.e. for example master.version is
only created on nodes running nfd-master. only created on nodes running nfd-master.

11
docs/reference/master-commandline-reference.md
View file

@ -74,7 +74,7 @@ and cert files configured in order for the incoming requests to be accepted.
Default: *empty* Default: *empty*
Note: Must be specified together with `-cert-file` and `-key-file` > **NOTE:** Must be specified together with `-cert-file` and `-key-file`
Example: Example:
@ -91,7 +91,7 @@ authenticating outgoing traffic towards nfd-worker.
Default: *empty* Default: *empty*
Note: Must be specified together with `-ca-file` and `-key-file` > **NOTE:** Must be specified together with `-ca-file` and `-key-file`
Example: Example:
@ -109,7 +109,7 @@ traffic.
Default: *empty* Default: *empty*
Note: Must be specified together with `-cert-file` and `-ca-file` > **NOTE:** Must be specified together with `-cert-file` and `-ca-file`
Example: Example:
@ -216,8 +216,9 @@ The `-label-whitelist` specifies a regular expression for filtering feature
labels based on their name. Each label must match against the given reqular labels based on their name. Each label must match against the given reqular
expression in order to be published. expression in order to be published.
Note: The regular expression is only matches against the "basename" part of the > **NOTE:** The regular expression is only matches against the "basename" part
label, i.e. to the part of the name after '/'. The label namespace is omitted. > of the label, i.e. to the part of the name after '/'. The label namespace is
> omitted.
Default: *empty* Default: *empty*

5
docs/reference/master-configuration-reference.md
View file

@ -103,8 +103,9 @@ enableTaints: true
labels based on their name. Each label must match against the given reqular labels based on their name. Each label must match against the given reqular
expression in order to be published. expression in order to be published.
Note: The regular expression is only matches against the "basename" part of the > ** NOTE:** The regular expression is only matches against the "basename" part
label, i.e. to the part of the name after '/'. The label namespace is omitted. > of the label, i.e. to the part of the name after '/'. The label namespace is
> omitted.
Default: *empty* Default: *empty*

26
docs/reference/worker-commandline-reference.md
View file

@ -80,7 +80,7 @@ authenticity of nfd-master.
Default: *empty* Default: *empty*
Note: Must be specified together with `-cert-file` and `-key-file` > **NOTE:** Must be specified together with `-cert-file` and `-key-file`
Example: Example:
@ -97,7 +97,7 @@ requests.
Default: *empty* Default: *empty*
Note: Must be specified together with `-ca-file` and `-key-file` > **NOTE:** Must be specified together with `-ca-file` and `-key-file`
Example: Example:
@ -114,7 +114,7 @@ This flag specifies the private key corresponding the given certificate file
Default: *empty* Default: *empty*
Note: Must be specified together with `-cert-file` and `-ca-file` > **NOTE:** Must be specified together with `-cert-file` and `-ca-file`
Example: Example:
@ -164,8 +164,8 @@ labels are generated nor the raw feature data is available for custom rule
processing. Consider using the `core.featureSources` config file option, processing. Consider using the `core.featureSources` config file option,
instead, allowing dynamic configurability. instead, allowing dynamic configurability.
Note: This flag takes precedence over the `core.featureSources` configuration > **NOTE:** This flag takes precedence over the `core.featureSources`
file option. > configuration file option.
Default: all Default: all
@ -184,8 +184,8 @@ meaningful when used in conjunction with `all`. Consider using the
`core.labelSources` config file option, instead, allowing dynamic `core.labelSources` config file option, instead, allowing dynamic
configurability. configurability.
Note: This flag takes precedence over the `core.labelSources` configuration > **NOTE:** This flag takes precedence over the `core.labelSources`
file option. > configuration file option.
Default: all Default: all
@ -220,9 +220,9 @@ NFD-Worker runs feature detection normally, but no labeling requests are sent
to nfd-master and no NodeFeature objects are created or updated in the API to nfd-master and no NodeFeature objects are created or updated in the API
server. server.
Note: This flag takes precedence over the > **NOTE:** This flag takes precedence over the
[`core.noPublish`](worker-configuration-reference.md#corenopublish) > [`core.noPublish`](worker-configuration-reference.md#corenopublish)
configuration file option. > configuration file option.
Default: *false* Default: *false*
@ -250,9 +250,9 @@ nfd-worker -oneshot -no-publish
The following logging-related flags are inherited from the The following logging-related flags are inherited from the
[klog](https://pkg.go.dev/k8s.io/klog/v2) package. [klog](https://pkg.go.dev/k8s.io/klog/v2) package.
Note: The logger setup can also be specified via the `core.klog` configuration > **NOTE:** The logger setup can also be specified via the `core.klog`
file options. However, the command line flags take precedence over any > configuration file options. However, the command line flags take precedence
corresponding config file options specified. > over any corresponding config file options specified.
#### -add_dir_header #### -add_dir_header

36
docs/reference/worker-configuration-reference.md
View file

@ -79,8 +79,8 @@ conjunction with `all`. This configuration option affects the generation of
node labels but not the actual discovery of the underlying feature data that is node labels but not the actual discovery of the underlying feature data that is
used e.g. in custom/`NodeFeatureRule` rules. used e.g. in custom/`NodeFeatureRule` rules.
Note: Overridden by the `-label-sources` command line flag and > **NOTE:** Overridden by the `-label-sources` command line flag and the
the `core.sources` configurations option (if either of them is specified). > `core.sources` configurations option (if either of them is specified).
Default: `[all]` Default: `[all]`
@ -107,17 +107,17 @@ core:
**DEPRECATED**: use [`core.labelSources`](#core.labelSources) instead. **DEPRECATED**: use [`core.labelSources`](#core.labelSources) instead.
Note: `core.sources` takes precedence over the `core.labelSources` > **NOTE:** `core.sources` takes precedence over the `core.labelSources`
configuration file option. > configuration file option.
### core.labelWhiteList ### core.labelWhiteList
`core.labelWhiteList` specifies a regular expression for filtering feature `core.labelWhiteList` specifies a regular expression for filtering feature
labels based on the label name. Non-matching labels are not published. labels based on the label name. Non-matching labels are not published.
Note: The regular expression is only matches against the "basename" part of the > **NOTE:** The regular expression is only matches against the "basename" part
label, i.e. to the part of the name after '/'. The label prefix (or namespace) > of the label, i.e. to the part of the name after '/'. The label prefix (or
is omitted. > namespace) is omitted.
Default: `null` Default: `null`
@ -136,9 +136,9 @@ NFD-Worker runs feature detection normally, but no labeling requests are sent
to nfd-master and no [NodeFeature](../usage/custom-resources.md#nodefeature) to nfd-master and no [NodeFeature](../usage/custom-resources.md#nodefeature)
objects are created or updated in the API server. objects are created or updated in the API server.
Note: Overridden by the > **NOTE:** Overridden by the
[`-no-publish`](worker-commandline-reference.md#-no-publish) command line flag (if > [`-no-publish`](worker-commandline-reference.md#-no-publish)
specified). > command line flag (if specified).
Default: `false` Default: `false`
@ -154,8 +154,8 @@ core:
The following options specify the logger configuration. Most of which can be The following options specify the logger configuration. Most of which can be
dynamically adjusted at run-time. dynamically adjusted at run-time.
Note: The logger options can also be specified via command line flags which > **NOTE:** The logger options can also be specified via command line flags
take precedence over any corresponding config file options. > which take precedence over any corresponding config file options.
#### core.klog.addDirHeader #### core.klog.addDirHeader
@ -264,7 +264,7 @@ The `sources` section contains feature source specific configuration parameters.
Prevent publishing cpuid features listed in this option. Prevent publishing cpuid features listed in this option.
Note: overridden by `sources.cpu.cpuid.attributeWhitelist` (if specified) > **NOTE:** overridden by `sources.cpu.cpuid.attributeWhitelist` (if specified)
Default: `[BMI1, BMI2, CLMUL, CMOV, CX16, ERMS, F16C, HTT, LZCNT, MMX, MMXEXT, Default: `[BMI1, BMI2, CLMUL, CMOV, CX16, ERMS, F16C, HTT, LZCNT, MMX, MMXEXT,
NX, POPCNT, RDRAND, RDSEED, RDTSCP, SGX, SGXLC, SSE, SSE2, SSE3, SSE4.1, NX, POPCNT, RDRAND, RDSEED, RDTSCP, SGX, SGXLC, SSE, SSE2, SSE3, SSE4.1,
@ -283,7 +283,7 @@ sources:
Only publish the cpuid features listed in this option. Only publish the cpuid features listed in this option.
Note: takes precedence over `sources.cpu.cpuid.attributeBlacklist` > **NOTE:** takes precedence over `sources.cpu.cpuid.attributeBlacklist`
Default: *empty* Default: *empty*
@ -336,10 +336,10 @@ Hooks are DEPRECATED since v0.12.0 release and support will be removed in a
future release. Use future release. Use
[feature files](../usage//customization-guide.md#feature-files) instead. [feature files](../usage//customization-guide.md#feature-files) instead.
Note: The default NFD container image only supports statically linked binaries. > **NOTE:** The default NFD container image only supports statically linked
Use the [full](../deployment/image-variants.md#full) image variant for a > binaries. Use the [full](../deployment/image-variants.md#full) image variant
slightly more extensive environment that additionally supports bash and perl > for a slightly more extensive environment that additionally supports bash and
runtimes. > perl runtimes.
Related tracking issues: Related tracking issues:

62
docs/usage/customization-guide.md
View file

@ -177,10 +177,10 @@ To enable the tainting feature, `--enable-taints` flag needs to be set to `true`
If the flag `--enable-taints` is set to `false` (i.e. disabled), taints defined in If the flag `--enable-taints` is set to `false` (i.e. disabled), taints defined in
the NodeFeatureRule CR have no effect and will be ignored by the NFD master. the NodeFeatureRule CR have no effect and will be ignored by the NFD master.
**NOTE**: Before enabling any taints, make sure to edit nfd-worker daemonset to > **NOTE:** Before enabling any taints, make sure to edit nfd-worker daemonset
tolerate the taints to be created. Otherwise, already running pods that do not > to tolerate the taints to be created. Otherwise, already running pods that do
tolerate the taint are evicted immediately from the node including the nfd-worker > not tolerate the taint are evicted immediately from the node including the
pod. > nfd-worker pod.
Example NodeFeatureRule with custom taints: Example NodeFeatureRule with custom taints:
@ -232,11 +232,11 @@ used in label rules specified in
[`NodeFeatureRule`](#nodefeaturerule-custom-resource) objects and the [`NodeFeatureRule`](#nodefeaturerule-custom-resource) objects and the
[`custom`](#custom-feature-source) feature source. [`custom`](#custom-feature-source) feature source.
**NOTE:** Be careful when creating and/or updating hook or feature files while > **NOTE:** Be careful when creating and/or updating hook or feature files
NFD is running. In order to avoid race conditions you should write into a > while NFD is running. In order to avoid race conditions you should write into
temporary file (outside the `source.d` and `features.d` directories), and, > a temporary file (outside the `source.d` and `features.d` directories), and,
atomically create/update the original file by doing a filesystem move > atomically create/update the original file by doing a filesystem move
operation. > operation.
### A hook example ### A hook example
@ -277,9 +277,9 @@ should be placed in a separate directory in order to avoid NFD unnecessarily
trying to execute them. A subdirectory under the hooks directory can be used, trying to execute them. A subdirectory under the hooks directory can be used,
for example `/etc/kubernetes/node-feature-discovery/source.d/conf/`. for example `/etc/kubernetes/node-feature-discovery/source.d/conf/`.
**NOTE:** Hooks are being DEPRECATED and will be removed in a future release. > **NOTE:** Hooks are being DEPRECATED and will be removed in a future release.
Starting from release v0.14 hooks are disabled by default and can be enabled > Starting from release v0.14 hooks are disabled by default and can be enabled
via `sources.local.hooksEnabled` field in the worker configuration. > via `sources.local.hooksEnabled` field in the worker configuration.
```yaml ```yaml
sources: sources:
@ -287,13 +287,13 @@ sources:
hooksEnabled: true # true by default at this point hooksEnabled: true # true by default at this point
``` ```
**NOTE:** NFD will blindly run any executables placed/mounted in the hooks > **NOTE:** NFD will blindly run any executables placed/mounted in the hooks
directory. It is the user's responsibility to review the hooks for e.g. > directory. It is the user's responsibility to review the hooks for e.g.
possible security implications. > possible security implications.
>
**NOTE:** The [full](../deployment/image-variants.md#full) image variant > **NOTE:** The [full](../deployment/image-variants.md#full) image variant
provides backwards-compatibility with older NFD versions by including a more > provides backwards-compatibility with older NFD versions by including a more
expanded environment, supporting bash and perl runtimes. > expanded environment, supporting bash and perl runtimes.
### Feature files ### Feature files
@ -513,9 +513,9 @@ The `.labelsTemplate` field specifies a text template for dynamically creating
labels based on the matched features. See [templating](#templating) for labels based on the matched features. See [templating](#templating) for
details. details.
**NOTE** The `labels` field has priority over `labelsTemplate`, i.e. > **NOTE:** The `labels` field has priority over `labelsTemplate`, i.e.
labels specified in the `labels` field will override anything > labels specified in the `labels` field will override anything
originating from `labelsTemplate`. > originating from `labelsTemplate`.
#### Taints #### Taints
@ -523,8 +523,8 @@ originating from `labelsTemplate`.
where the `value` is optional. Effect could be `NoSchedule`, `PreferNoSchedule` where the `value` is optional. Effect could be `NoSchedule`, `PreferNoSchedule`
or `NoExecute`. To learn more about the meaning of these effects, check out k8s [documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/). or `NoExecute`. To learn more about the meaning of these effects, check out k8s [documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/).
**NOTE** taints field is not available for the custom rules of nfd-worker and only > **NOTE:** taints field is not available for the custom rules of nfd-worker
for NodeFeatureRule objects. > and only for NodeFeatureRule objects.
#### Vars #### Vars
@ -599,9 +599,9 @@ vars based on the matched features. See [templating](#templating) for details
on using templates and [backreferences](#backreferences) for more details on on using templates and [backreferences](#backreferences) for more details on
the usage of vars. the usage of vars.
**NOTE** The `vars` field has priority over `varsTemplate`, i.e. > **NOTE:** The `vars` field has priority over `varsTemplate`, i.e.
vars specified in the `vars` field will override anything originating from > vars specified in the `vars` field will override anything originating from
`varsTemplate`. > `varsTemplate`.
#### MatchFeatures #### MatchFeatures
@ -847,10 +847,10 @@ feature:
``` ```
<!-- {% endraw %} --> <!-- {% endraw %} -->
**NOTE** In case of matchAny is specified, the template is executed separately > **NOTE:** In case of matchAny is specified, the template is executed
against each individual `matchFeatures` field and the final set of labels will > separately against each individual `matchFeatures` field and the final set of
be superset of all these separate template expansions. E.g. consider the > labels will be superset of all these separate template expansions. E.g.
following: > consider the following:
```yaml ```yaml
- name: <name> - name: <name>

20
docs/usage/features.md
View file

@ -33,14 +33,14 @@ have the following format.
feature.node.kubernetes.io/<feature> = <value> feature.node.kubernetes.io/<feature> = <value>
``` ```
> NOTE: Consecutive runs of nfd-worker will update the labels on a > **NOTE:** Consecutive runs of nfd-worker will update the labels on a given
given node. If features are not discovered on a consecutive run, the corresponding > node. If features are not discovered on a consecutive run, the corresponding
label will be removed. This includes any restrictions placed on the consecutive run, > label will be removed. This includes any restrictions placed on the
such as restricting discovered features with the > consecutive run, such as restricting discovered features with the
[`-label-whitelist`](../reference/master-commandline-reference.md#-label-whitelist) > [`-label-whitelist`](../reference/master-commandline-reference.md#-label-whitelist)
flag of nfd-master or > flag of nfd-master or
[`core.labelWhiteList`](../reference/worker-configuration-reference.md#corelabelwhitelist) > [`core.labelWhiteList`](../reference/worker-configuration-reference.md#corelabelwhitelist)
option of nfd-worker. > option of nfd-worker.
### CPU ### CPU
@ -70,8 +70,8 @@ option of nfd-worker.
| **`cpu-model.family`** | int | CPU family. | **`cpu-model.family`** | int | CPU family.
| **`cpu-model.id`** | int | CPU model number. | **`cpu-model.id`** | int | CPU model number.
> NOTE: the `cpu-rdt.<rdt-flag>` labels are deprecated and will be removed in a > **NOTE:** the `cpu-rdt.<rdt-flag>` labels are deprecated and will be removed
> future release. They will remain to be available as features > in a future release. They will remain to be available as features
> for [NodeFeatureRule](custom-resources.md#nodefeaturerule) to consume. > for [NodeFeatureRule](custom-resources.md#nodefeaturerule) to consume.
> See [customization guide](customization-guide.md#nodefeaturerule-custom-resource) > See [customization guide](customization-guide.md#nodefeaturerule-custom-resource)
> for details how to use NodeFeatureRule objects to create labels. > for details how to use NodeFeatureRule objects to create labels.

8
docs/usage/nfd-master.md
View file

@ -25,7 +25,7 @@ processing pipeline. In addition, any labels listed in the NodeFeature object
are created on the node (note the allowed are created on the node (note the allowed
[label namespaces](customization-guide.md#node-labels) are controlled). [label namespaces](customization-guide.md#node-labels) are controlled).
> NOTE: NodeFeature API must also be enabled in nfd-worker with > **NOTE:** NodeFeature API must also be enabled in nfd-worker with
> its [`-enable-nodefeature-api`](../reference/worker-commandline-reference.md#-enable-nodefeature-api) > its [`-enable-nodefeature-api`](../reference/worker-commandline-reference.md#-enable-nodefeature-api)
> flag. > flag.
@ -45,7 +45,7 @@ received from nfd-worker instances through the gRPC interface or from
requires that the [NodeFeaure controller](#nodefeature-controller) has been requires that the [NodeFeaure controller](#nodefeature-controller) has been
enabled. enabled.
> NOTE: when gRPC is used for communicating the features (the default > **NOTE:** when gRPC is used for communicating the features (the default
> mechanism), (re-)labelling only happens when a request is received from > mechanism), (re-)labelling only happens when a request is received from
> nfd-worker. That is, in practice rules are evaluated and labels for each node > nfd-worker. That is, in practice rules are evaluated and labels for each node
> are created on intervals specified by the > are created on intervals specified by the
@ -103,8 +103,8 @@ affinity to prevent masters from running on the same node.
However note that inter-pod affinity is costly and is not recommended However note that inter-pod affinity is costly and is not recommended
in bigger clusters. in bigger clusters.
> NOTE: If the [NodeFeature controller](#nodefeature-controller) is enabled the > **NOTE:** If the [NodeFeature controller](#nodefeature-controller) is enabled
> replica count should be 1. > the replica count should be 1.
If you have RBAC authorization enabled (as is the default e.g. with clusters If you have RBAC authorization enabled (as is the default e.g. with clusters
initialized with kubeadm) you need to configure the appropriate ClusterRoles, initialized with kubeadm) you need to configure the appropriate ClusterRoles,

5
docs/usage/nfd-topology-updater.md
View file

@ -52,8 +52,9 @@ Starting from Kubernetes v1.23, the `KubeletPodResourcesGetAllocatable`
NFD-Topology-Updater supports configuration through a configuration file. The NFD-Topology-Updater supports configuration through a configuration file. The
default location is `/etc/kubernetes/node-feature-discovery/topology-updater.conf`, default location is `/etc/kubernetes/node-feature-discovery/topology-updater.conf`,
but, this can be changed by specifying the`-config` command line flag. but, this can be changed by specifying the`-config` command line flag.
> NOTE: unlike nfd-worker,
> dynamic configuration updates are not currently supported. > **NOTE:** unlike nfd-worker, dynamic configuration updates are not currently
> supported.
Topology-Updater configuration file is read inside the container, Topology-Updater configuration file is read inside the container,
and thus, Volumes and VolumeMounts are needed and thus, Volumes and VolumeMounts are needed