mirror of
https://github.com/kubernetes-sigs/node-feature-discovery.git
synced 2025-03-14 20:56:42 +00:00
docs: fix internal cross-page references by injecting .md
This commit is contained in:
parent
497e6c7b25
commit
bfbc47f55e
16 changed files with 60 additions and 60 deletions
|
@ -49,7 +49,7 @@ helm install node-feature-discovery ./node-feature-discovery/ --namespace $NFD_N
|
|||
See the [configuration](#configuration) section below for instructions how to
|
||||
alter the deployment parameters.
|
||||
|
||||
In order to deploy the [minimal](image-variants#minimal) image you need to
|
||||
In order to deploy the [minimal](image-variants.md#minimal) image you need to
|
||||
override the image tag:
|
||||
|
||||
```bash
|
||||
|
@ -101,7 +101,7 @@ We have introduced the following Chart parameters.
|
|||
| `fullnameOverride` | string | | Override a default fully qualified app name |
|
||||
| `tls.enable` | bool | false | Specifies whether to use TLS for communications between components |
|
||||
| `tls.certManager` | bool | false | If enabled, requires [cert-manager](https://cert-manager.io/docs/) to be installed and will automatically create the required TLS certificates |
|
||||
| `enableNodeFeatureApi` | bool | false | Enable the [NodeFeature](../usage/custom-resources#nodefeature) CRD API for communicating node features. This will automatically disable the gRPC communication.
|
||||
| `enableNodeFeatureApi` | bool | false | Enable the [NodeFeature](../usage/custom-resources.md#nodefeature) CRD API for communicating node features. This will automatically disable the gRPC communication.
|
||||
|
||||
### Master pod parameters
|
||||
|
||||
|
|
|
@ -38,7 +38,7 @@ and [Topologyupdater](#topologyupdater) below.
|
|||
|
||||
Alternatively you can clone the repository and customize the deployment by
|
||||
creating your own overlays. For example, to deploy the
|
||||
[minimal](image-variants#minimal) image. See [kustomize][kustomize] for more
|
||||
[minimal](image-variants.md#minimal) image. See [kustomize][kustomize] for more
|
||||
information about managing deployment configurations.
|
||||
|
||||
## Overlays
|
||||
|
@ -59,7 +59,7 @@ scenarios under
|
|||
see [Topology Updater](#topologyupdater) below
|
||||
- [`prune`](https://github.com/kubernetes-sigs/node-feature-discovery/blob/{{site.release}}/deployment/overlays/prune):
|
||||
clean up the cluster after uninstallation, see
|
||||
[Removing feature labels](uninstallation#removing-feature-labels)
|
||||
[Removing feature labels](uninstallation.md#removing-feature-labels)
|
||||
- [`samples/cert-manager`](https://github.com/kubernetes-sigs/node-feature-discovery/blob/{{site.release}}/deployment/overlays/samples/cert-manager):
|
||||
an example for supplementing the default deployment with cert-manager for TLS
|
||||
authentication, see
|
||||
|
@ -68,7 +68,7 @@ scenarios under
|
|||
- [`samples/custom-rules`](https://github.com/kubernetes-sigs/node-feature-discovery/blob/{{site.release}}/deployment/overlays/samples/custom-rules):
|
||||
an example for spicing up the default deployment with a separately managed
|
||||
configmap of custom labeling rules, see
|
||||
[Custom feature source](../usage/features#custom) for more information about
|
||||
[Custom feature source](../usage/features.md#custom) for more information about
|
||||
custom node labels
|
||||
|
||||
### Master-worker pod
|
||||
|
|
|
@ -59,7 +59,7 @@ is recommended to be done via
|
|||
EOF
|
||||
```
|
||||
|
||||
In order to deploy the [minimal](image-variants#minimal) image you need to use
|
||||
In order to deploy the [minimal](image-variants.md#minimal) image you need to use
|
||||
|
||||
```yaml
|
||||
image: {{ site.container_image }}-minimal
|
||||
|
|
|
@ -65,8 +65,8 @@ To make use of the helm chart, override `values.yaml` to enable both the
|
|||
deployment will wait until certificates are manually created, as demonstrated
|
||||
below.
|
||||
|
||||
See the sample installation commands in the Helm [Deployment](helm#deployment)
|
||||
and [Configuration](helm#configuration) sections above for how to either override
|
||||
See the sample installation commands in the Helm [Deployment](helm.md#deployment)
|
||||
and [Configuration](helm.md#configuration) sections above for how to either override
|
||||
individual values, or provide a yaml file with which to override default
|
||||
values.
|
||||
|
||||
|
|
|
@ -16,9 +16,9 @@ sort: 6
|
|||
---
|
||||
|
||||
Follow the uninstallation instructions of the deployment method used
|
||||
([kustomize](kustomize#uninstallation),
|
||||
[helm](helm#uninstalling-the-chart) or
|
||||
[operator](operator#uninstallation)).
|
||||
([kustomize](kustomize.md#uninstallation),
|
||||
[helm](helm.md#uninstalling-the-chart) or
|
||||
[operator](operator.md#uninstallation)).
|
||||
|
||||
## Removing feature labels
|
||||
|
||||
|
|
|
@ -43,14 +43,14 @@ NFD-Topology-Updater is a daemon responsible for examining allocated
|
|||
resources on a worker node to account for resources available to be allocated
|
||||
to new pod on a per-zone basis (where a zone can be a NUMA node). It then
|
||||
creates or updates a
|
||||
[NodeResourceTopology](../usage/custom-resources#noderesourcetopology) custom
|
||||
[NodeResourceTopology](../usage/custom-resources.md#noderesourcetopology) custom
|
||||
resource object specific to this node. One instance of nfd-topology-updater is
|
||||
supposed to be running on each node of the cluster.
|
||||
|
||||
## NFD-Topology-Garbage-Collector
|
||||
|
||||
NFD-Topology-Garbage-Collector is a daemon responsible for cleaning obsolete
|
||||
[NodeResourceTopology](../usage/custom-resources#noderesourcetopology) objects,
|
||||
[NodeResourceTopology](../usage/custom-resources.md#noderesourcetopology) objects,
|
||||
obsolete means that there is no corresponding worker node.
|
||||
|
||||
One instance of nfd-topology-gc is supposed to be running in the cluster.
|
||||
|
@ -104,7 +104,7 @@ 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#instance)
|
||||
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
|
||||
|
@ -114,13 +114,13 @@ only created on nodes running nfd-master.
|
|||
|
||||
NFD takes use of some Kubernetes Custom Resources.
|
||||
|
||||
[NodeFeature](../usage/custom-resources#nodefeature)s (EXPERIMENTAL)
|
||||
[NodeFeature](../usage/custom-resources.md#nodefeature)s (EXPERIMENTAL)
|
||||
can be used for representing node features and requesting node labels to be
|
||||
generated.
|
||||
|
||||
NFD-Master uses [NodeFeatureRule](../usage/custom-resources#nodefeaturerule)s
|
||||
NFD-Master uses [NodeFeatureRule](../usage/custom-resources.md#nodefeaturerule)s
|
||||
for custom labeling of nodes.
|
||||
|
||||
NFD-Topology-Updater creates
|
||||
[NodeResourceTopology](../usage/custom-resources#noderesourcetopology) objects
|
||||
[NodeResourceTopology](../usage/custom-resources.md#noderesourcetopology) objects
|
||||
that describe the hardware topology of node resources.
|
||||
|
|
|
@ -140,7 +140,7 @@ nfd-master -verify-node-name -ca-file=/opt/nfd/ca.crt \
|
|||
### -enable-nodefeature-api
|
||||
|
||||
The `-enable-nodefeature-api` flag enables the
|
||||
[NodeFeature](../usage/custom-resources#nodefeature) CRD API for receiving
|
||||
[NodeFeature](../usage/custom-resources.md#nodefeature) CRD API for receiving
|
||||
feature requests. This will also automatically disable the gRPC interface.
|
||||
|
||||
Default: false
|
||||
|
@ -181,8 +181,8 @@ nfd-master -no-publish
|
|||
|
||||
The `-crd-controller` flag specifies whether the NFD CRD API controller is
|
||||
enabled or not. The controller is responsible for processing
|
||||
[NodeFeature](../usage/custom-resources#nodefeature) and
|
||||
[NodeFeatureRule](../usage/custom-resources#nodefeaturerule) objects.
|
||||
[NodeFeature](../usage/custom-resources.md#nodefeature) and
|
||||
[NodeFeatureRule](../usage/custom-resources.md#nodefeaturerule) objects.
|
||||
|
||||
Default: *true*
|
||||
|
||||
|
|
|
@ -126,7 +126,7 @@ nfd-worker -key-file=/opt/nfd/worker.key -cert-file=/opt/nfd/worker.crt -ca-file
|
|||
|
||||
The `-kubeconfig` flag specifies the kubeconfig to use for connecting to the
|
||||
Kubernetes API server. It is only needed for manipulating
|
||||
[NodeFeature](../usage/custom-resources#nodefeature) objects, and thus the flag
|
||||
[NodeFeature](../usage/custom-resources.md#nodefeature) objects, and thus the flag
|
||||
only takes effect when
|
||||
[`-enable-nodefeature-api`](#-enable-nodefeature-api)) is specified. An empty
|
||||
value (which is also the default) implies in-cluster kubeconfig.
|
||||
|
@ -198,7 +198,7 @@ nfd-worker -label-sources=kernel,system,local
|
|||
### -enable-nodefeature-api
|
||||
|
||||
The `-enable-nodefeature-api` flag enables the experimental
|
||||
[NodeFeature](../usage/custom-resources#nodefeature) CRD API
|
||||
[NodeFeature](../usage/custom-resources.md#nodefeature) CRD API
|
||||
for communicating with nfd-master. This will also automatically disable the
|
||||
gRPC communication to nfd-master. When enabled, nfd-worker will create per-node
|
||||
NodeFeature objects the contain all discovered node features and the set of
|
||||
|
@ -221,7 +221,7 @@ 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#corenopublish)
|
||||
[`core.noPublish`](worker-configuration-reference.md#corenopublish)
|
||||
configuration file option.
|
||||
|
||||
Default: *false*
|
||||
|
|
|
@ -133,11 +133,11 @@ core:
|
|||
Setting `core.noPublish` to `true` disables all communication with the
|
||||
nfd-master and the Kubernetes API server. It is effectively a "dry-run" option.
|
||||
NFD-Worker runs feature detection normally, but no labeling requests are sent
|
||||
to nfd-master and no [NodeFeature](../usage/custom-resources#nodefeature)
|
||||
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#-no-publish) command line flag (if
|
||||
[`-no-publish`](worker-commandline-reference.md#-no-publish) command line flag (if
|
||||
specified).
|
||||
|
||||
Default: `false`
|
||||
|
@ -334,7 +334,7 @@ sources:
|
|||
Configuration option to disable/enable hooks execution. Enabled by default.
|
||||
Hooks are DEPRECATED since v0.12.0 release and support will be removed in a
|
||||
future release. Use
|
||||
[feature files](../usage//customization-guide#feature-files) instead.
|
||||
[feature files](../usage//customization-guide.md#feature-files) instead.
|
||||
|
||||
Related tracking issues:
|
||||
|
||||
|
@ -429,7 +429,7 @@ With the example config above NFD would publish labels like:
|
|||
|
||||
List of rules to process in the custom feature source to create user-specific
|
||||
labels. Refer to the documentation of the
|
||||
[custom feature source](../usage/customization-guide#custom-feature-source) for
|
||||
[custom feature source](../usage/customization-guide.md#custom-feature-source) for
|
||||
details of the available rules and their configuration.
|
||||
|
||||
Default: *empty*
|
||||
|
|
|
@ -26,7 +26,7 @@ disabled by default. If enabled, nfd-master watches for NodeFeature objects,
|
|||
labels nodes as specified and uses the listed features as input when evaluating
|
||||
[NodeFeatureRule](#nodefeaturerule)s. NodeFeature objects can be used for
|
||||
implementing 3rd party extensions (see
|
||||
[customization guide](customization-guide#nodefeature-custom-resource) for more
|
||||
[customization guide](customization-guide.md#nodefeature-custom-resource) for more
|
||||
details).
|
||||
|
||||
```yaml
|
||||
|
@ -85,7 +85,7 @@ spec:
|
|||
```
|
||||
|
||||
See the
|
||||
[Customization guide](customization-guide#node-feature-rule-custom-resource)
|
||||
[Customization guide](customization-guide.md#node-feature-rule-custom-resource)
|
||||
for full documentation of the NodeFeatureRule resource and its usage.
|
||||
|
||||
## NodeResourceTopology
|
||||
|
|
|
@ -284,7 +284,7 @@ sources:
|
|||
directory. It is the user's responsibility to review the hooks for e.g.
|
||||
possible security implications.
|
||||
|
||||
**NOTE:** The [minimal](../deployment/image-variants#minimal) image
|
||||
**NOTE:** The [minimal](../deployment/image-variants.md#minimal) image
|
||||
variant only supports running statically linked binaries.
|
||||
|
||||
### Feature files
|
||||
|
@ -334,7 +334,7 @@ label creation, similar to the
|
|||
that the rules are specified in the worker configuration instead of a
|
||||
Kubernetes API object.
|
||||
|
||||
See [worker configuration](nfd-worker#worker-configuration)
|
||||
See [worker configuration](nfd-worker.md#worker-configuration)
|
||||
for instructions how to set-up and manage the worker configuration.
|
||||
|
||||
### An example custom feature source configuration
|
||||
|
@ -419,7 +419,7 @@ The namespace part (i.e. prefix) of the labels is controlled by nfd:
|
|||
sub-namespaces (e.g. `vendor.profile.node.kubernetes.io` and
|
||||
`sub.ns.profile.node.kubernetes.io`) by default
|
||||
- Additional namespaces may be enabled with the
|
||||
[`-extra-label-ns`](../reference/master-commandline-reference#-extra-label-ns)
|
||||
[`-extra-label-ns`](../reference/master-commandline-reference.md#-extra-label-ns)
|
||||
command line flag of nfd-master
|
||||
|
||||
## Label rule format
|
||||
|
@ -608,7 +608,7 @@ The following features are available for matching:
|
|||
| | | **`turbo`** | bool | 'true' if turbo frequencies are enabled, otherwise 'false'
|
||||
| | | **`scaling`** | string | Active scaling_governor, possible values are 'powersave' or 'performance'.
|
||||
| **`cpu.rdt`** | flag | | | Intel RDT capabilities supported by the system
|
||||
| | | **`<rdt-flag>`** | | RDT capability is supported, see [RDT flags](features#intel-rdt-flags) for details
|
||||
| | | **`<rdt-flag>`** | | RDT capability is supported, see [RDT flags](features.md#intel-rdt-flags) for details
|
||||
| **`cpu.security`** | attribute | | | Features related to security and trusted execution environments
|
||||
| | | **`sgx.enabled`** | bool | `true` if Intel SGX (Software Guard Extensions) has been enabled, otherwise does not exist
|
||||
| | | **`se.enabled`** | bool | `true` if IBM Secure Execution for Linux is available and has been enabled, otherwise does not exist
|
||||
|
|
|
@ -21,9 +21,9 @@ Features are advertised as labels in the Kubernetes Node object.
|
|||
|
||||
Label creation in nfd-worker is performed by a set of separate modules called
|
||||
label sources. The
|
||||
[`core.labelSources`](../reference/worker-configuration-reference#corelabelsources)
|
||||
[`core.labelSources`](../reference/worker-configuration-reference.md#corelabelsources)
|
||||
configuration option (or
|
||||
[`-label-sources`](../reference/worker-commandline-reference#-label-sources)
|
||||
[`-label-sources`](../reference/worker-commandline-reference.md#-label-sources)
|
||||
flag) of nfd-worker controls which sources to enable for label generation.
|
||||
|
||||
All built-in labels use the `feature.node.kubernetes.io` label namespace and
|
||||
|
@ -37,9 +37,9 @@ feature.node.kubernetes.io/<feature> = <value>
|
|||
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#-label-whitelist)
|
||||
[`-label-whitelist`](../reference/master-commandline-reference.md#-label-whitelist)
|
||||
flag of nfd-master or
|
||||
[`core.labelWhiteList`](../reference/worker-configuration-reference#corelabelwhitelist)
|
||||
[`core.labelWhiteList`](../reference/worker-configuration-reference.md#corelabelwhitelist)
|
||||
option of nfd-worker.
|
||||
|
||||
### CPU
|
||||
|
@ -64,8 +64,8 @@ option of nfd-worker.
|
|||
| **`cpu-model.id`** | int | CPU model number.
|
||||
|
||||
The CPU label source is configurable, see
|
||||
[worker configuration](nfd-worker#worker-configuration) and
|
||||
[`sources.cpu`](../reference/worker-configuration-reference#sourcescpu)
|
||||
[worker configuration](nfd-worker.md#worker-configuration) and
|
||||
[`sources.cpu`](../reference/worker-configuration-reference.md#sourcescpu)
|
||||
configuration options for details.
|
||||
|
||||
#### X86 CPUID flags (partial list)
|
||||
|
@ -111,7 +111,7 @@ configuration options for details.
|
|||
By default, the following CPUID flags have been blacklisted: BMI1, BMI2, CLMUL,
|
||||
CMOV, CX16, ERMS, F16C, HTT, LZCNT, MMX, MMXEXT, NX, POPCNT, RDRAND, RDSEED,
|
||||
RDTSCP, SGX, SSE, SSE2, SSE3, SSE4, SSE42 and SSSE3. See
|
||||
[`sources.cpu`](../reference/worker-configuration-reference#sourcescpu)
|
||||
[`sources.cpu`](../reference/worker-configuration-reference.md#sourcescpu)
|
||||
configuration options to change the behavior.
|
||||
|
||||
See the full list in [github.com/klauspost/cpuid][klauspost-cpuid].
|
||||
|
@ -170,8 +170,8 @@ See the full list in [github.com/klauspost/cpuid][klauspost-cpuid].
|
|||
| **`kernel-version.revision`** | string | Third component of the kernel version (e.g. '6')
|
||||
|
||||
The kernel label source is configurable, see
|
||||
[worker configuration](nfd-worker#worker-configuration) and
|
||||
[`sources.kernel`](../reference/worker-configuration-reference#sourceskernel)
|
||||
[worker configuration](nfd-worker.md#worker-configuration) and
|
||||
[`sources.kernel`](../reference/worker-configuration-reference.md#sourceskernel)
|
||||
configuration options for details.
|
||||
|
||||
### Memory
|
||||
|
@ -198,8 +198,8 @@ configuration options for details.
|
|||
|
||||
`<device label>` is format is configurable and set to `<class>_<vendor>` by
|
||||
default. For more more details about configuration of the pci labels, see
|
||||
[`sources.pci`](../reference/worker-configuration-reference#sourcespci) options
|
||||
and [worker configuration](nfd-worker#worker-configuration)
|
||||
[`sources.pci`](../reference/worker-configuration-reference.md#sourcespci) options
|
||||
and [worker configuration](nfd-worker.md#worker-configuration)
|
||||
instructions.
|
||||
|
||||
### USB
|
||||
|
@ -211,8 +211,8 @@ instructions.
|
|||
`<device label>` is format is configurable and set to
|
||||
`<class>_<vendor>_<device>` by default. For more more details about
|
||||
configuration of the usb labels, see
|
||||
[`sources.usb`](../reference/worker-configuration-reference#sourcesusb) options
|
||||
and [worker configuration](nfd-worker#worker-configuration)
|
||||
[`sources.usb`](../reference/worker-configuration-reference.md#sourcesusb) options
|
||||
and [worker configuration](nfd-worker.md#worker-configuration)
|
||||
instructions.
|
||||
|
||||
### Storage
|
||||
|
|
|
@ -16,27 +16,27 @@ extended resources based on requests from nfd-workers and 3rd party extensions.
|
|||
## NodeFeature controller
|
||||
|
||||
**EXPERIMENTAL**
|
||||
Controller for [NodeFeature](custom-resources#nodefeature-custom-resource)
|
||||
Controller for [NodeFeature](custom-resources.md#nodefeature-custom-resource)
|
||||
objects can be enabled with the
|
||||
[`-enable-nodefeature-api`](../reference/master-commandline-reference#-enable-nodefeature-api)
|
||||
[`-enable-nodefeature-api`](../reference/master-commandline-reference.md#-enable-nodefeature-api)
|
||||
command line flag. When enabled, features from NodeFeature objects are used as
|
||||
the input for the [NodeFeatureRule](custom-resources#nodefeaturerule)
|
||||
the input for the [NodeFeatureRule](custom-resources.md#nodefeaturerule)
|
||||
processing pipeline. In addition, any labels listed in the NodeFeature object
|
||||
are created on the node (note the allowed
|
||||
[label namespaces](customization-guide#node-labels) are controlled).
|
||||
[label namespaces](customization-guide.md#node-labels) are controlled).
|
||||
|
||||
> NOTE: NodeFeature API must also be enabled in nfd-worker with
|
||||
> its [`-enable-nodefeature-api`](../reference/worker-commandline-reference#-enable-nodefeature-api)
|
||||
> its [`-enable-nodefeature-api`](../reference/worker-commandline-reference.md#-enable-nodefeature-api)
|
||||
> flag.
|
||||
|
||||
## NodeFeatureRule controller
|
||||
|
||||
NFD-Master acts as the controller for
|
||||
[NodeFeatureRule](custom-resources#nodefeaturerule) objects.
|
||||
[NodeFeatureRule](custom-resources.md#nodefeaturerule) objects.
|
||||
It applies the rules specified in NodeFeatureRule objects on raw feature data
|
||||
and creates node labels accordingly. The feature data used as the input can be
|
||||
received from nfd-worker instances through the gRPC interface or from
|
||||
[NodeFeature](custom-resources#nodefeature-custom-resource) objects. The latter
|
||||
[NodeFeature](custom-resources.md#nodefeature-custom-resource) objects. The latter
|
||||
requires that the [NodeFeaure controller](#nodefeature-controller) has been
|
||||
enabled.
|
||||
|
||||
|
@ -44,13 +44,13 @@ enabled.
|
|||
> 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
|
||||
> [`core.sleepInterval`](../reference/worker-configuration-reference#coresleepinterval)
|
||||
> [`core.sleepInterval`](../reference/worker-configuration-reference.md#coresleepinterval)
|
||||
> configuration option of nfd-worker instances. This means that modification or
|
||||
> creation of NodeFeatureRule objects does not instantly cause the node
|
||||
> labels to be updated. Instead, the changes only come visible in node labels
|
||||
> as nfd-worker instances send their labelling requests. This limitation is not
|
||||
> present when gRPC interface is disabled
|
||||
> and [NodeFeature](custom-resources#nodefeature-custom-resource) API is used.
|
||||
> and [NodeFeature](custom-resources.md#nodefeature-custom-resource) API is used.
|
||||
|
||||
## Deployment notes
|
||||
|
||||
|
|
|
@ -11,7 +11,7 @@ sort: 6
|
|||
|
||||
NFD-Topology-Garbage-Collector is preferably run as a Kubernetes deployment
|
||||
with one replica. It makes sure that all
|
||||
[NodeResourceTopology](custom-resources#noderesourcetopology)
|
||||
[NodeResourceTopology](custom-resources.md#noderesourcetopology)
|
||||
have corresponding worker nodes and removes stale objects for worker nodes
|
||||
which are no longer part of Kubernetes cluster.
|
||||
|
||||
|
|
|
@ -12,14 +12,14 @@ sort: 5
|
|||
NFD-Topology-Updater is preferably run as a Kubernetes DaemonSet. This assures
|
||||
re-examination on regular intervals, capturing changes in the allocated
|
||||
resources and hence the allocatable resources on a per zone basis by updating
|
||||
[NodeResourceTopology](custom-resources#noderesourcetopology) custom resources.
|
||||
[NodeResourceTopology](custom-resources.md#noderesourcetopology) custom resources.
|
||||
It makes sure that new NodeResourceTopology instances are created for each new
|
||||
nodes that get added to the cluster.
|
||||
|
||||
When run as a daemonset, nodes are re-examined for the allocated resources
|
||||
(to determine the information of the allocatable resources on a per zone basis
|
||||
where a zone can be a NUMA node) at an interval specified using the
|
||||
[`-sleep-interval`](../reference/topology-updater-commandline-reference.html#-sleep-interval)
|
||||
[`-sleep-interval`](../reference/topology-updater-commandline-reference.html.md#-sleep-interval)
|
||||
option. The default sleep interval is set to 60s which is the value when no
|
||||
-sleep-interval is specified.
|
||||
In addition, it can avoid examining specific allocated resources
|
||||
|
|
|
@ -22,7 +22,7 @@ Worker connects to the nfd-master service to advertise hardware features.
|
|||
|
||||
When run as a daemonset, nodes are re-labeled at an default interval of 60s.
|
||||
This can be changed by using the
|
||||
[`core.sleepInterval`](../reference/worker-configuration-reference.html#coresleepinterval)
|
||||
[`core.sleepInterval`](../reference/worker-configuration-reference.md#coresleepinterval)
|
||||
config option.
|
||||
|
||||
The worker configuration file is watched and re-read on every change which
|
||||
|
@ -51,7 +51,7 @@ kubectl -n ${NFD_NS} edit configmap nfd-worker-conf
|
|||
```
|
||||
|
||||
In Helm deployments,
|
||||
[Worker pod parameter](../deployment/helm#worker-pod-parameters)
|
||||
[Worker pod parameter](../deployment/helm.md#worker-pod-parameters)
|
||||
`worker.config` can be used to edit the respective configuration.
|
||||
|
||||
See
|
||||
|
|
Loading…
Add table
Reference in a new issue