mirror of
https://github.com/kubernetes-sigs/node-feature-discovery.git
synced 2025-03-05 08:17:04 +00:00
docs: unify capitalization of headings
This commit is contained in:
Markus Lehtonen
parent
4c5285d9ed
commit
7fc6cd632c
11 changed files with 64 additions and 64 deletions
|
|
@ -1,15 +1,15 @@
|
|||
---
|
||||
title: "Customization Guide"
|
||||
title: "Customization guide"
|
||||
layout: default
|
||||
sort: 5
|
||||
published: false
|
||||
---
|
||||
|
||||
# Customization Guide
|
||||
# Customization guide
|
||||
|
||||
{: .no_toc }
|
||||
|
||||
## Table of Contents
|
||||
## Table of contents
|
||||
|
||||
{: .no_toc .text-delta }
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
title: "Developer Guide"
|
||||
title: "Developer guide"
|
||||
layout: default
|
||||
sort: 1
|
||||
---
|
||||
|
||||
# Developer Guide
|
||||
# Developer guide
|
||||
|
||||
{: .no_toc }
|
||||
|
||||
|
|
@ -17,7 +17,7 @@ sort: 1
|
|||
|
||||
---
|
||||
|
||||
## Building from Source
|
||||
## Building from source
|
||||
|
||||
### Download the source code
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ git clone https://github.com/kubernetes-sigs/node-feature-discovery
|
|||
cd node-feature-discovery
|
||||
```
|
||||
|
||||
### Docker Build
|
||||
### Docker build
|
||||
|
||||
#### Build the container image
|
||||
|
||||
|
|
@ -81,7 +81,7 @@ NUM_NODES=$(kubectl get no -o jsonpath='{.items[*].metadata.name}' | wc -w)
|
|||
sed s"/NUM_NODES/$NUM_NODES/" nfd-worker-job.yaml | kubectl apply -f -
|
||||
```
|
||||
|
||||
### Building Locally
|
||||
### Building locally
|
||||
|
||||
You can also build the binaries locally
|
||||
|
||||
|
|
@ -91,7 +91,7 @@ make build
|
|||
|
||||
This will compile binaries under `bin/`
|
||||
|
||||
### Customizing the Build
|
||||
### Customizing the build
|
||||
|
||||
There are several Makefile variables that control the build process and the
|
||||
name of the resulting container image. The following are targeted targeted for
|
||||
|
|
@ -149,7 +149,7 @@ cluster you need to specify the kubeconfig to be used:
|
|||
make e2e-test KUBECONFIG=$HOME/.kube/config
|
||||
```
|
||||
|
||||
## Running Locally
|
||||
## Running locally
|
||||
|
||||
You can run NFD locally, either directly on your host OS or in containers for
|
||||
testing and development purposes. This may be useful e.g. for checking
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
title: "E2E-Test Config Reference"
|
||||
title: "E2E-test config reference"
|
||||
layout: default
|
||||
sort: 7
|
||||
published: false
|
||||
---
|
||||
|
||||
# End-to-End Test Configuration File Reference
|
||||
# Configuration file reference of end-to-end tests
|
||||
|
||||
{: .no_toc }
|
||||
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
---
|
||||
title: "Master Cmdline Reference"
|
||||
title: "Master cmdline reference"
|
||||
layout: default
|
||||
sort: 2
|
||||
---
|
||||
|
||||
# NFD-Master Commandline Flags
|
||||
# Commandline flags of nfd-master
|
||||
|
||||
{: .no_toc }
|
||||
|
||||
## Table of Contents
|
||||
## Table of contents
|
||||
|
||||
{: .no_toc .text-delta }
|
||||
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
---
|
||||
title: "Worker Cmdline Reference"
|
||||
title: "Worker cmdline reference"
|
||||
layout: default
|
||||
sort: 3
|
||||
---
|
||||
|
||||
# NFD-Worker Commandline Flags
|
||||
# Commandline flags of nfd-worker
|
||||
|
||||
{: .no_toc }
|
||||
|
||||
## Table of Contents
|
||||
## Table of contents
|
||||
|
||||
{: .no_toc .text-delta }
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
title: "Worker Config Reference"
|
||||
title: "Worker config reference"
|
||||
layout: default
|
||||
sort: 4
|
||||
---
|
||||
|
||||
# NFD-Worker Configuration File Reference
|
||||
# Configuration file reference of nfd-worker
|
||||
|
||||
{: .no_toc }
|
||||
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
---
|
||||
title: "Deployment and Usage"
|
||||
title: "Deployment and usage"
|
||||
layout: default
|
||||
sort: 3
|
||||
---
|
||||
|
||||
# Deployment and Usage
|
||||
# Deployment and usage
|
||||
|
||||
{: .no_toc }
|
||||
|
||||
## Table of Contents
|
||||
## Table of contents
|
||||
|
||||
{: .no_toc .text-delta }
|
||||
|
||||
|
|
@ -60,7 +60,7 @@ is recommended to be done via
|
|||
EOF
|
||||
```
|
||||
|
||||
### Deployment Templates
|
||||
### Deployment templates
|
||||
|
||||
The template specs provided in the repo can be used directly:
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ nfd-worker (as a daemonset) in the `node-feature-discovery` namespace.
|
|||
Alternatively you can download the templates and customize the deployment
|
||||
manually.
|
||||
|
||||
#### Master-Worker Pod
|
||||
#### Master-worker pod
|
||||
|
||||
You can also run nfd-master and nfd-worker inside the same pod
|
||||
|
||||
|
|
@ -87,7 +87,7 @@ This creates a DaemonSet runs both 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.
|
||||
|
||||
#### Worker One-shot
|
||||
#### Worker one-shot
|
||||
|
||||
Feature discovery can alternatively be configured as a one-shot job.
|
||||
The Job template may be used to achieve this:
|
||||
|
|
@ -104,7 +104,7 @@ this approach does not guarantee running once on every node. For example,
|
|||
tainted, non-ready nodes or some other reasons in Job scheduling may cause some
|
||||
node(s) will run extra job instance(s) to satisfy the request.
|
||||
|
||||
### Deployment with Helm
|
||||
### Deployment with helm
|
||||
|
||||
Node Feature Discovery Helm chart allow to easily deploy and manage NFD.
|
||||
|
||||
|
|
@ -143,7 +143,7 @@ export NFD_NS=node-feature-discovery
|
|||
helm install node-feature-discovery ./node-feature-discovery/ --set nameOverride=NFDinstance --set master.replicaCount=2 --namespace $NFD_NS --create-namespace
|
||||
```
|
||||
|
||||
#### Uninstalling the Chart
|
||||
#### Uninstalling the chart
|
||||
|
||||
To uninstall the `node-feature-discovery` deployment:
|
||||
|
||||
|
|
@ -155,7 +155,7 @@ helm uninstall node-feature-discovery --namespace $NFD_NS
|
|||
The command removes all the Kubernetes components associated with the chart and
|
||||
deletes the release.
|
||||
|
||||
#### Chart Parameters
|
||||
#### Chart parameters
|
||||
|
||||
In order to tailor the deployment of the Node Feature Discovery to your cluster needs
|
||||
We have introduced the following Chart parameters.
|
||||
|
|
@ -200,7 +200,7 @@ We have introduced the following Chart parameters.
|
|||
| `worker.tolerations` | dict | {} | NFD worker pod [node tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) |
|
||||
| `worker.annotations` | dict | {} | NFD worker pod [metadata](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) |
|
||||
|
||||
### Build Your Own
|
||||
### Build your own
|
||||
|
||||
If you want to use the latest development version (master branch) you need to
|
||||
build your own custom image.
|
||||
|
|
@ -244,7 +244,7 @@ the default interval is set to 60s which is also the default when no
|
|||
`-sleep-interval` is specified. Also, the configuration file is re-read on
|
||||
each iteration providing a simple mechanism of run-time reconfiguration.
|
||||
|
||||
### TLS authentication
|
||||
### Communication security with TLS
|
||||
|
||||
NFD supports mutual TLS authentication between the nfd-master and nfd-worker
|
||||
instances. That is, nfd-worker and nfd-master both verify that the other end
|
||||
|
|
@ -263,7 +263,7 @@ nfd-master args, in which case nfd-master verifies that the NodeName presented
|
|||
by nfd-worker matches the Common Name (CN) of its certificate. This means that
|
||||
each nfd-worker requires a individual node-specific TLS certificate.
|
||||
|
||||
## Worker Configuration
|
||||
## Worker configuration
|
||||
|
||||
NFD-Worker supports dynamic configuration through a configuration file. The
|
||||
default location is `/etc/kubernetes/node-feature-discovery/nfd-worker.conf`,
|
||||
|
|
@ -302,7 +302,7 @@ file must be used, i.e. JSON (or YAML). For example:
|
|||
Configuration options specified from the command line will override those read
|
||||
from the config file.
|
||||
|
||||
## Using Node Labels
|
||||
## Using node labels
|
||||
|
||||
Nodes with specific features can be targeted using the `nodeSelector` field. The
|
||||
following example shows how to target nodes with Intel TurboBoost enabled.
|
||||
|
|
@ -327,7 +327,7 @@ For more details on targeting nodes, see
|
|||
|
||||
## Uninstallation
|
||||
|
||||
### Operator Was Used for Deployment
|
||||
### Operator was used for deployment
|
||||
|
||||
If you followed the deployment instructions above you can simply do:
|
||||
|
||||
|
|
@ -369,7 +369,7 @@ kubectl delete clusterrole nfd-master
|
|||
kubectl delete clusterrolebinding nfd-master
|
||||
```
|
||||
|
||||
### Removing Feature Labels
|
||||
### Removing feature labels
|
||||
|
||||
NFD-Master has a special `-prune` command line flag for removing all
|
||||
nfd-related node labels, annotations and extended resources from the cluster.
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
---
|
||||
title: "Examples and Demos"
|
||||
title: "Examples and demos"
|
||||
layout: default
|
||||
sort: 5
|
||||
---
|
||||
|
||||
# Examples And Demos
|
||||
# Examples and demos
|
||||
|
||||
{: .no_toc }
|
||||
|
||||
## Table of Contents
|
||||
## Table of contents
|
||||
|
||||
{: .no_toc .text-delta }
|
||||
|
||||
|
|
@ -25,7 +25,7 @@ This page contains usage examples and demos.
|
|||
|
||||
[](https://asciinema.org/a/247316)
|
||||
|
||||
### Demo Use Case
|
||||
### Demo use case
|
||||
|
||||
A demo on the benefits of using node feature discovery can be found in the
|
||||
source code repository under
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
---
|
||||
title: "Feature Discovery"
|
||||
title: "Feature discovery"
|
||||
layout: default
|
||||
sort: 4
|
||||
---
|
||||
|
||||
# Feature Discovery
|
||||
# Feature discovery
|
||||
|
||||
{: .no_toc }
|
||||
|
||||
## Table of Contents
|
||||
## Table of contents
|
||||
|
||||
{: .no_toc .text-delta }
|
||||
|
||||
|
|
@ -50,7 +50,7 @@ given node. If features are not discovered on a consecutive run, the correspondi
|
|||
label will be removed. This includes any restrictions placed on the consecutive run,
|
||||
such as restricting discovered features with the -label-whitelist option.*
|
||||
|
||||
## Feature Sources
|
||||
## Feature sources
|
||||
|
||||
### CPU
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ RDRAND, RDSEED, RDTSCP, SGX, SSE, SSE2, SSE3, SSE4.1, SSE4.2 and SSSE3.
|
|||
**NOTE** The cpuid features advertise *supported* CPU capabilities, that is, a
|
||||
capability might be supported but not enabled.
|
||||
|
||||
#### X86 CPUID Attributes (Partial List)
|
||||
#### X86 CPUID attributes (partial list)
|
||||
|
||||
| Attribute | Description |
|
||||
| --------- | ---------------------------------------------------------------- |
|
||||
|
|
@ -93,7 +93,7 @@ capability might be supported but not enabled.
|
|||
|
||||
See the full list in [github.com/klauspost/cpuid][klauspost-cpuid].
|
||||
|
||||
#### Arm CPUID Attribute (Partial List)
|
||||
#### Arm CPUID attribute (partial list)
|
||||
|
||||
| Attribute | Description |
|
||||
| --------- | ---------------------------------------------------------------- |
|
||||
|
|
@ -110,7 +110,7 @@ See the full list in [github.com/klauspost/cpuid][klauspost-cpuid].
|
|||
| NEON | NEON SIMD instructions
|
||||
| LPAE | Large Physical Address Extensions
|
||||
|
||||
#### Arm64 CPUID Attribute (Partial List)
|
||||
#### Arm64 CPUID attribute (partial list)
|
||||
|
||||
| Attribute | Description |
|
||||
| --------- | ---------------------------------------------------------------- |
|
||||
|
|
@ -147,7 +147,7 @@ mounting e.g. ConfigMap(s). The example deployment manifests provide an example
|
|||
(commented out) for providing Custom configuration with an additional
|
||||
ConfigMap, mounted into the `custom.d` directory.
|
||||
|
||||
#### General Nomenclature & Definitions
|
||||
#### General nomenclature & definitions
|
||||
|
||||
```plaintext
|
||||
Rule :Represents a matching logic that is used to match on a feature.
|
||||
|
|
@ -155,7 +155,7 @@ Rule Input :The input a Rule is provided. This determines how a Rule performs t
|
|||
Matcher :A composition of Rules, each Matcher may be composed of at most one instance of each Rule.
|
||||
```
|
||||
|
||||
#### Custom Features Format (using the Nomenclature defined above)
|
||||
#### Custom features format (using the nomenclature defined above)
|
||||
|
||||
Rules are specified under `sources.custom` in the nfd-worker configuration
|
||||
file.
|
||||
|
|
@ -188,7 +188,7 @@ between Rules of a given Matcher.
|
|||
|
||||
#### Rules
|
||||
|
||||
##### PciId Rule
|
||||
##### pciid rule
|
||||
|
||||
###### Nomenclature
|
||||
|
||||
|
|
@ -215,7 +215,7 @@ and logical _AND_ between the specified Attributes for each PCI device in the
|
|||
system. At least one Attribute must be specified. Missing attributes will not
|
||||
partake in the matching process.
|
||||
|
||||
##### UsbId Rule
|
||||
##### UsbId rule
|
||||
|
||||
###### Nomenclature
|
||||
|
||||
|
|
@ -242,7 +242,7 @@ and logical _AND_ between the specified Attributes for each USB device in the
|
|||
system. At least one Attribute must be specified. Missing attributes will not
|
||||
partake in the matching process.
|
||||
|
||||
##### LoadedKMod Rule
|
||||
##### LoadedKMod rule
|
||||
|
||||
###### Nomenclature
|
||||
|
||||
|
|
@ -263,7 +263,7 @@ Matching is done by performing logical _AND_ for each provided Element, i.e
|
|||
the Rule will match if all provided Elements (kernel modules) are loaded in the
|
||||
system.
|
||||
|
||||
##### CpuId Rule
|
||||
##### CpuId rule
|
||||
|
||||
###### Nomenclature
|
||||
|
||||
|
|
@ -284,7 +284,7 @@ Matching is done by performing logical _AND_ for each provided Element, i.e the
|
|||
Rule will match if all provided Elements (CPUID flag strings) are available in
|
||||
the system.
|
||||
|
||||
##### Kconfig Rule
|
||||
##### Kconfig rule
|
||||
|
||||
###### Nomenclature
|
||||
|
||||
|
|
@ -305,7 +305,7 @@ Matching is done by performing logical _AND_ for each provided Element, i.e the
|
|||
Rule will match if all provided Elements (kernel config options) are enabled
|
||||
(`y` or `m`) or matching `=<value>` in the kernel.
|
||||
|
||||
##### Nodename Rule
|
||||
##### Nodename rule
|
||||
|
||||
###### Nomenclature
|
||||
|
||||
|
|
@ -520,7 +520,7 @@ The **system** feature source supports the following labels:
|
|||
| | VERSION_ID.major | First component of the OS version id (e.g. '6')
|
||||
| | VERSION_ID.minor | Second component of the OS version id (e.g. '7')
|
||||
|
||||
### Local -- User-specific Features
|
||||
### Local -- user-specific features
|
||||
|
||||
NFD has a special feature source named *local* which is designed for getting
|
||||
the labels from user-specific feature detector. It provides a mechanism for
|
||||
|
|
@ -570,7 +570,7 @@ label `my.namespace.org/my-label=value`, your hook output or file must contains
|
|||
`stderr` output of the hooks is propagated to NFD log so it can be used for
|
||||
debugging and logging.
|
||||
|
||||
#### Injecting Labels from Other Pods
|
||||
#### Injecting labels from other pods
|
||||
|
||||
One use case for the hooks and/or feature files is detecting features in other
|
||||
Pods outside NFD, e.g. in Kubernetes device plugins. It is possible to mount
|
||||
|
|
@ -582,7 +582,7 @@ contains `hostPath` mounts for `sources.d` and `features.d` directories. By
|
|||
using the same mounts in the secondary Pod (e.g. device plugin) you have
|
||||
created a shared area for delivering hooks and feature files to NFD.
|
||||
|
||||
#### A Hook Example
|
||||
#### A hook example
|
||||
|
||||
User has a shell script
|
||||
`/etc/kubernetes/node-feature-discovery/source.d/my-source` which has the
|
||||
|
|
@ -606,7 +606,7 @@ feature.node.kubernetes.io/override_source-OVERRIDE_VALUE=123
|
|||
override.namespace/value=456
|
||||
```
|
||||
|
||||
#### A File Example
|
||||
#### A file example
|
||||
|
||||
User has a file `/etc/kubernetes/node-feature-discovery/features.d/my-source`
|
||||
which contains the following lines:
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ sort: 1
|
|||
|
||||
{: .no_toc }
|
||||
|
||||
## Table of Contents
|
||||
## Table of contents
|
||||
|
||||
{: .no_toc .text-delta }
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ NFD-Worker is a daemon responsible for feature detection. It then communicates
|
|||
the information to nfd-master which does the actual node labeling. One
|
||||
instance of nfd-worker is supposed to be running on each node of the cluster,
|
||||
|
||||
## Feature Discovery
|
||||
## Feature discovery
|
||||
|
||||
Feature discovery is divided into domain-specific feature sources:
|
||||
|
||||
|
|
@ -78,7 +78,7 @@ An overview of the default feature labels:
|
|||
}
|
||||
```
|
||||
|
||||
## Node Annotations
|
||||
## Node annotations
|
||||
|
||||
NFD also annotates nodes it is running on:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
title: "Quick Start"
|
||||
title: "Quick start"
|
||||
layout: default
|
||||
sort: 2
|
||||
---
|
||||
|
||||
# Quick Start
|
||||
# Quick start
|
||||
|
||||
Minimal steps to deploy latest released version of NFD in your cluster.
|
||||
|
||||
|
|
@ -47,7 +47,7 @@ $ kubectl get no -o json | jq .items[].metadata.labels
|
|||
...
|
||||
```
|
||||
|
||||
## Use Node Labels
|
||||
## Use node labels
|
||||
|
||||
Create a pod targeting a distinguishing feature (select a valid feature from
|
||||
the list printed on the previous step)
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue