mirror of
https://github.com/kubernetes-sigs/node-feature-discovery.git
synced 2024-12-14 11:57:51 +00:00
docs: unify formatting of NOTEs
This commit is contained in:
Markus Lehtonen
parent
45dc46ab81
commit
0a8b514d67
13 changed files with 120 additions and 118 deletions
|
|
@ -17,9 +17,9 @@ sort: 3
|
|||
|
||||
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
|
||||
> in multiple parallel NFD deployments in the same cluster which is not fully
|
||||
> supported by the NFD Helm chart.
|
||||
> **NOTE:** NFD is not ideal for other Helm charts to depend on as that may
|
||||
> result in multiple parallel NFD deployments in the same cluster which is not
|
||||
> fully supported by the NFD Helm chart.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
nfd-worker (as daemonset) in the `node-feature-discovery` namespace.
|
||||
|
||||
**NOTE:** nfd-topology-updater is not deployed as part of the `default` overlay.
|
||||
Please refer to the [Master Worker Topologyupdater](#master-worker-topologyupdater)
|
||||
and [Topologyupdater](#topologyupdater) below.
|
||||
> **NOTE:** nfd-topology-updater is not deployed as part of the `default`
|
||||
> overlay. Please refer to the [Master Worker Topologyupdater](#master-worker-topologyupdater)
|
||||
> and [Topologyupdater](#topologyupdater) below.
|
||||
|
||||
Alternatively you can clone the repository and customize the deployment by
|
||||
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
|
||||
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.
|
||||
To enable nfd-topology-updater in this scenario,the users must customize the
|
||||
deployment themselves.
|
||||
> **NOTE:** nfd-topology-updater is not deployed by the default-combined
|
||||
> overlay. To enable nfd-topology-updater in this scenario,the users must
|
||||
> customize the deployment themselves.
|
||||
|
||||
### Worker one-shot
|
||||
|
||||
|
|
|
|||
|
|
@ -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 }}
|
||||
```
|
||||
|
||||
**NOTE:** You must run prune before removing the RBAC rules (serviceaccount,
|
||||
clusterrole and clusterrolebinding).
|
||||
> **NOTE:** You must run prune before removing the RBAC rules (serviceaccount,
|
||||
> clusterrole and clusterrolebinding).
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
pass the `-no-publish` flag to nfd-worker.
|
||||
|
||||
**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
|
||||
correct `--volume` options in order for them to work correctly when run
|
||||
stand-alone directly with `docker run`. See 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.
|
||||
> **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 correct `--volume` options in order for them to work correctly when run
|
||||
> stand-alone directly with `docker run`. See
|
||||
> 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.
|
||||
|
||||
### 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,
|
||||
pass the `-no-publish` flag to nfd-topology-updater.
|
||||
|
||||
NOTE:
|
||||
|
||||
NFD topology updater needs certain directories and/or files from the
|
||||
host mounted inside the NFD container. Thus, you need to provide Docker with the
|
||||
correct `--volume` options in order for them to work correctly when run
|
||||
stand-alone directly with `docker run`. See the
|
||||
[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 started with the following flag:
|
||||
`--feature-gates=KubeletPodResourcesGetAllocatable=true`.
|
||||
Starting Kubernetes v1.23, the `GetAllocatableResources` is enabled by default
|
||||
through `KubeletPodResourcesGetAllocatable` [feature gate][feature-gate].
|
||||
> **NOTE:** NFD topology updater needs certain directories and/or files from
|
||||
> the host mounted inside the NFD container. Thus, you need to provide Docker
|
||||
> with the correct `--volume` options in order for them to work correctly when
|
||||
> run stand-alone directly with `docker run`. See
|
||||
> the [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
|
||||
> started with the following flag:
|
||||
> `--feature-gates=KubeletPodResourcesGetAllocatable=true`. Starting
|
||||
> Kubernetes v1.23, the `GetAllocatableResources` is enabled by default through
|
||||
> `KubeletPodResourcesGetAllocatable` [feature gate][feature-gate].
|
||||
|
||||
## Running with Tilt
|
||||
|
||||
|
|
|
|||
|
|
@ -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/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)
|
||||
command line flag affects the annotation names
|
||||
> **NOTE:** the [`-instance`](../reference/master-commandline-reference.md#instance)
|
||||
> command line flag affects the annotation names
|
||||
|
||||
Unapplicable annotations are not created, i.e. for example master.version is
|
||||
only created on nodes running nfd-master.
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ and cert files configured in order for the incoming requests to be accepted.
|
|||
|
||||
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:
|
||||
|
||||
|
|
@ -91,7 +91,7 @@ authenticating outgoing traffic towards nfd-worker.
|
|||
|
||||
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:
|
||||
|
||||
|
|
@ -109,7 +109,7 @@ traffic.
|
|||
|
||||
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:
|
||||
|
||||
|
|
@ -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
|
||||
expression in order to be published.
|
||||
|
||||
Note: The regular expression is only matches against the "basename" part of the
|
||||
label, i.e. to the part of the name after '/'. The label namespace is omitted.
|
||||
> **NOTE:** The regular expression is only matches against the "basename" part
|
||||
> of the label, i.e. to the part of the name after '/'. The label namespace is
|
||||
> omitted.
|
||||
|
||||
Default: *empty*
|
||||
|
||||
|
|
|
|||
|
|
@ -103,8 +103,9 @@ enableTaints: true
|
|||
labels based on their name. Each label must match against the given reqular
|
||||
expression in order to be published.
|
||||
|
||||
Note: The regular expression is only matches against the "basename" part of the
|
||||
label, i.e. to the part of the name after '/'. The label namespace is omitted.
|
||||
> ** NOTE:** The regular expression is only matches against the "basename" part
|
||||
> of the label, i.e. to the part of the name after '/'. The label namespace is
|
||||
> omitted.
|
||||
|
||||
Default: *empty*
|
||||
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ authenticity of nfd-master.
|
|||
|
||||
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:
|
||||
|
||||
|
|
@ -97,7 +97,7 @@ requests.
|
|||
|
||||
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:
|
||||
|
||||
|
|
@ -114,7 +114,7 @@ This flag specifies the private key corresponding the given certificate file
|
|||
|
||||
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:
|
||||
|
||||
|
|
@ -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,
|
||||
instead, allowing dynamic configurability.
|
||||
|
||||
Note: This flag takes precedence over the `core.featureSources` configuration
|
||||
file option.
|
||||
> **NOTE:** This flag takes precedence over the `core.featureSources`
|
||||
> configuration file option.
|
||||
|
||||
Default: all
|
||||
|
||||
|
|
@ -184,8 +184,8 @@ meaningful when used in conjunction with `all`. Consider using the
|
|||
`core.labelSources` config file option, instead, allowing dynamic
|
||||
configurability.
|
||||
|
||||
Note: This flag takes precedence over the `core.labelSources` configuration
|
||||
file option.
|
||||
> **NOTE:** This flag takes precedence over the `core.labelSources`
|
||||
> configuration file option.
|
||||
|
||||
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
|
||||
server.
|
||||
|
||||
Note: This flag takes precedence over the
|
||||
[`core.noPublish`](worker-configuration-reference.md#corenopublish)
|
||||
configuration file option.
|
||||
> **NOTE:** This flag takes precedence over the
|
||||
> [`core.noPublish`](worker-configuration-reference.md#corenopublish)
|
||||
> configuration file option.
|
||||
|
||||
Default: *false*
|
||||
|
||||
|
|
@ -250,9 +250,9 @@ nfd-worker -oneshot -no-publish
|
|||
The following logging-related flags are inherited from the
|
||||
[klog](https://pkg.go.dev/k8s.io/klog/v2) package.
|
||||
|
||||
Note: The logger setup can also be specified via the `core.klog` configuration
|
||||
file options. However, the command line flags take precedence over any
|
||||
corresponding config file options specified.
|
||||
> **NOTE:** The logger setup can also be specified via the `core.klog`
|
||||
> configuration file options. However, the command line flags take precedence
|
||||
> over any corresponding config file options specified.
|
||||
|
||||
#### -add_dir_header
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
used e.g. in custom/`NodeFeatureRule` rules.
|
||||
|
||||
Note: Overridden by the `-label-sources` command line flag and
|
||||
the `core.sources` configurations option (if either of them is specified).
|
||||
> **NOTE:** Overridden by the `-label-sources` command line flag and the
|
||||
> `core.sources` configurations option (if either of them is specified).
|
||||
|
||||
Default: `[all]`
|
||||
|
||||
|
|
@ -107,17 +107,17 @@ core:
|
|||
|
||||
**DEPRECATED**: use [`core.labelSources`](#core.labelSources) instead.
|
||||
|
||||
Note: `core.sources` takes precedence over the `core.labelSources`
|
||||
configuration file option.
|
||||
> **NOTE:** `core.sources` takes precedence over the `core.labelSources`
|
||||
> configuration file option.
|
||||
|
||||
### core.labelWhiteList
|
||||
|
||||
`core.labelWhiteList` specifies a regular expression for filtering feature
|
||||
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
|
||||
label, i.e. to the part of the name after '/'. The label prefix (or namespace)
|
||||
is omitted.
|
||||
> **NOTE:** The regular expression is only matches against the "basename" part
|
||||
> of the label, i.e. to the part of the name after '/'. The label prefix (or
|
||||
> namespace) is omitted.
|
||||
|
||||
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)
|
||||
objects are created or updated in the API server.
|
||||
|
||||
Note: Overridden by the
|
||||
[`-no-publish`](worker-commandline-reference.md#-no-publish) command line flag (if
|
||||
specified).
|
||||
> **NOTE:** Overridden by the
|
||||
> [`-no-publish`](worker-commandline-reference.md#-no-publish)
|
||||
> command line flag (if specified).
|
||||
|
||||
Default: `false`
|
||||
|
||||
|
|
@ -154,8 +154,8 @@ core:
|
|||
The following options specify the logger configuration. Most of which can be
|
||||
dynamically adjusted at run-time.
|
||||
|
||||
Note: The logger options can also be specified via command line flags which
|
||||
take precedence over any corresponding config file options.
|
||||
> **NOTE:** The logger options can also be specified via command line flags
|
||||
> which take precedence over any corresponding config file options.
|
||||
|
||||
#### core.klog.addDirHeader
|
||||
|
||||
|
|
@ -264,7 +264,7 @@ The `sources` section contains feature source specific configuration parameters.
|
|||
|
||||
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,
|
||||
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.
|
||||
|
||||
Note: takes precedence over `sources.cpu.cpuid.attributeBlacklist`
|
||||
> **NOTE:** takes precedence over `sources.cpu.cpuid.attributeBlacklist`
|
||||
|
||||
Default: *empty*
|
||||
|
||||
|
|
@ -336,10 +336,10 @@ Hooks are DEPRECATED since v0.12.0 release and support will be removed in a
|
|||
future release. Use
|
||||
[feature files](../usage//customization-guide.md#feature-files) instead.
|
||||
|
||||
Note: The default NFD container image only supports statically linked binaries.
|
||||
Use the [full](../deployment/image-variants.md#full) image variant for a
|
||||
slightly more extensive environment that additionally supports bash and perl
|
||||
runtimes.
|
||||
> **NOTE:** The default NFD container image only supports statically linked
|
||||
> binaries. Use the [full](../deployment/image-variants.md#full) image variant
|
||||
> for a slightly more extensive environment that additionally supports bash and
|
||||
> perl runtimes.
|
||||
|
||||
Related tracking issues:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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
|
||||
tolerate the taints to be created. Otherwise, already running pods that do not
|
||||
tolerate the taint are evicted immediately from the node including the nfd-worker
|
||||
pod.
|
||||
> **NOTE:** Before enabling any taints, make sure to edit nfd-worker daemonset
|
||||
> to tolerate the taints to be created. Otherwise, already running pods that do
|
||||
> not tolerate the taint are evicted immediately from the node including the
|
||||
> nfd-worker pod.
|
||||
|
||||
Example NodeFeatureRule with custom taints:
|
||||
|
||||
|
|
@ -232,11 +232,11 @@ used in label rules specified in
|
|||
[`NodeFeatureRule`](#nodefeaturerule-custom-resource) objects and the
|
||||
[`custom`](#custom-feature-source) feature source.
|
||||
|
||||
**NOTE:** Be careful when creating and/or updating hook or feature files while
|
||||
NFD is running. In order to avoid race conditions you should write into a
|
||||
temporary file (outside the `source.d` and `features.d` directories), and,
|
||||
atomically create/update the original file by doing a filesystem move
|
||||
operation.
|
||||
> **NOTE:** Be careful when creating and/or updating hook or feature files
|
||||
> while NFD is running. In order to avoid race conditions you should write into
|
||||
> a temporary file (outside the `source.d` and `features.d` directories), and,
|
||||
> atomically create/update the original file by doing a filesystem move
|
||||
> operation.
|
||||
|
||||
### 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,
|
||||
for example `/etc/kubernetes/node-feature-discovery/source.d/conf/`.
|
||||
|
||||
**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
|
||||
via `sources.local.hooksEnabled` field in the worker configuration.
|
||||
> **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
|
||||
> via `sources.local.hooksEnabled` field in the worker configuration.
|
||||
|
||||
```yaml
|
||||
sources:
|
||||
|
|
@ -287,13 +287,13 @@ sources:
|
|||
hooksEnabled: true # true by default at this point
|
||||
```
|
||||
|
||||
**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.
|
||||
possible security implications.
|
||||
|
||||
**NOTE:** The [full](../deployment/image-variants.md#full) image variant
|
||||
provides backwards-compatibility with older NFD versions by including a more
|
||||
expanded environment, supporting bash and perl runtimes.
|
||||
> **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.
|
||||
> possible security implications.
|
||||
>
|
||||
> **NOTE:** The [full](../deployment/image-variants.md#full) image variant
|
||||
> provides backwards-compatibility with older NFD versions by including a more
|
||||
> expanded environment, supporting bash and perl runtimes.
|
||||
|
||||
### 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
|
||||
details.
|
||||
|
||||
**NOTE** The `labels` field has priority over `labelsTemplate`, i.e.
|
||||
labels specified in the `labels` field will override anything
|
||||
originating from `labelsTemplate`.
|
||||
> **NOTE:** The `labels` field has priority over `labelsTemplate`, i.e.
|
||||
> labels specified in the `labels` field will override anything
|
||||
> originating from `labelsTemplate`.
|
||||
|
||||
#### Taints
|
||||
|
||||
|
|
@ -523,8 +523,8 @@ originating from `labelsTemplate`.
|
|||
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/).
|
||||
|
||||
**NOTE** taints field is not available for the custom rules of nfd-worker and only
|
||||
for NodeFeatureRule objects.
|
||||
> **NOTE:** taints field is not available for the custom rules of nfd-worker
|
||||
> and only for NodeFeatureRule objects.
|
||||
|
||||
#### 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
|
||||
the usage of vars.
|
||||
|
||||
**NOTE** The `vars` field has priority over `varsTemplate`, i.e.
|
||||
vars specified in the `vars` field will override anything originating from
|
||||
`varsTemplate`.
|
||||
> **NOTE:** The `vars` field has priority over `varsTemplate`, i.e.
|
||||
> vars specified in the `vars` field will override anything originating from
|
||||
> `varsTemplate`.
|
||||
|
||||
#### MatchFeatures
|
||||
|
||||
|
|
@ -847,10 +847,10 @@ feature:
|
|||
```
|
||||
|
||||
<!-- {% endraw %} -->
|
||||
**NOTE** In case of matchAny is specified, the template is executed separately
|
||||
against each individual `matchFeatures` field and the final set of labels will
|
||||
be superset of all these separate template expansions. E.g. consider the
|
||||
following:
|
||||
> **NOTE:** In case of matchAny is specified, the template is executed
|
||||
> separately against each individual `matchFeatures` field and the final set of
|
||||
> labels will be superset of all these separate template expansions. E.g.
|
||||
> consider the following:
|
||||
|
||||
```yaml
|
||||
- name: <name>
|
||||
|
|
|
|||
|
|
@ -33,14 +33,14 @@ have the following format.
|
|||
feature.node.kubernetes.io/<feature> = <value>
|
||||
```
|
||||
|
||||
> NOTE: Consecutive runs of nfd-worker will update the labels on a
|
||||
given 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,
|
||||
such as restricting discovered features with the
|
||||
[`-label-whitelist`](../reference/master-commandline-reference.md#-label-whitelist)
|
||||
flag of nfd-master or
|
||||
[`core.labelWhiteList`](../reference/worker-configuration-reference.md#corelabelwhitelist)
|
||||
option of nfd-worker.
|
||||
> **NOTE:** Consecutive runs of nfd-worker will update the labels on a given
|
||||
> 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, such as restricting discovered features with the
|
||||
> [`-label-whitelist`](../reference/master-commandline-reference.md#-label-whitelist)
|
||||
> flag of nfd-master or
|
||||
> [`core.labelWhiteList`](../reference/worker-configuration-reference.md#corelabelwhitelist)
|
||||
> option of nfd-worker.
|
||||
|
||||
### CPU
|
||||
|
||||
|
|
@ -70,8 +70,8 @@ option of nfd-worker.
|
|||
| **`cpu-model.family`** | int | CPU family.
|
||||
| **`cpu-model.id`** | int | CPU model number.
|
||||
|
||||
> NOTE: the `cpu-rdt.<rdt-flag>` labels are deprecated and will be removed in a
|
||||
> future release. They will remain to be available as features
|
||||
> **NOTE:** the `cpu-rdt.<rdt-flag>` labels are deprecated and will be removed
|
||||
> in a future release. They will remain to be available as features
|
||||
> for [NodeFeatureRule](custom-resources.md#nodefeaturerule) to consume.
|
||||
> See [customization guide](customization-guide.md#nodefeaturerule-custom-resource)
|
||||
> for details how to use NodeFeatureRule objects to create labels.
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ processing pipeline. In addition, any labels listed in the NodeFeature object
|
|||
are created on the node (note the allowed
|
||||
[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)
|
||||
> 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
|
||||
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
|
||||
> nfd-worker. That is, in practice rules are evaluated and labels for each node
|
||||
> 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
|
||||
in bigger clusters.
|
||||
|
||||
> NOTE: If the [NodeFeature controller](#nodefeature-controller) is enabled the
|
||||
> replica count should be 1.
|
||||
> **NOTE:** If the [NodeFeature controller](#nodefeature-controller) is enabled
|
||||
> the replica count should be 1.
|
||||
|
||||
If you have RBAC authorization enabled (as is the default e.g. with clusters
|
||||
initialized with kubeadm) you need to configure the appropriate ClusterRoles,
|
||||
|
|
|
|||
|
|
@ -52,8 +52,9 @@ Starting from Kubernetes v1.23, the `KubeletPodResourcesGetAllocatable`
|
|||
NFD-Topology-Updater supports configuration through a configuration file. The
|
||||
default location is `/etc/kubernetes/node-feature-discovery/topology-updater.conf`,
|
||||
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,
|
||||
and thus, Volumes and VolumeMounts are needed
|
||||
|
|
|
|||
Loading…
Reference in a new issue