1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/node-feature-discovery.git synced 2025-03-15 04:57:56 +00:00

docs: fix internal cross-page references by injecting .md

This commit is contained in:
Hiren Panchasara 2023-01-11 17:23:36 -08:00
parent 497e6c7b25
commit bfbc47f55e
16 changed files with 60 additions and 60 deletions

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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.

View file

@ -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

View file

@ -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.

View file

@ -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*

View file

@ -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*

View file

@ -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*

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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.

View file

@ -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

View file

@ -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