mirror of
https://github.com/kubernetes-sigs/node-feature-discovery.git
synced 2025-03-28 10:47:23 +00:00
docs: markdown style fixes
Fix markdown syntax and style for content that was moved from README.md to docs/: - get-started/introduction - examples-and-demos - get-started/features - contributing Unify the spelling of master and worker in headings and beginning of senctences. Also, env variable for container name in developers-guide.
This commit is contained in:
Markus Lehtonen
parent
a9d45c80ac
commit
2469db839f
6 changed files with 200 additions and 159 deletions
|
|
@ -17,32 +17,32 @@ sort: 1
|
|||
|
||||
## Building from Source
|
||||
|
||||
**Download the source code:**
|
||||
### Download the source code
|
||||
|
||||
```
|
||||
```bash
|
||||
git clone https://github.com/kubernetes-sigs/node-feature-discovery
|
||||
cd node-feature-discovery
|
||||
```
|
||||
|
||||
### Docker Build
|
||||
|
||||
#### Build the container image
|
||||
|
||||
**Build the container image:**<br>
|
||||
See [customizing the build](#customizing-the-build) below for altering the
|
||||
container image registry, for example.
|
||||
|
||||
```
|
||||
```bash
|
||||
make
|
||||
```
|
||||
|
||||
**Push the container image:**<br>
|
||||
#### Push the container image
|
||||
Optional, this example with Docker.
|
||||
|
||||
```
|
||||
```bash
|
||||
docker push <IMAGE_TAG>
|
||||
```
|
||||
|
||||
**Change the job spec to use your custom image (optional):**
|
||||
#### Change the job spec to use your custom image (optional)
|
||||
|
||||
To use your published image from the step above instead of the
|
||||
`k8s.gcr.io/nfd/node-feature-discovery` image, edit `image`
|
||||
|
|
@ -52,7 +52,8 @@ attribute in the spec template(s) to the new location
|
|||
### Building Locally
|
||||
|
||||
You can also build the binaries locally
|
||||
```
|
||||
|
||||
```bash
|
||||
make build
|
||||
```
|
||||
|
||||
|
|
@ -80,17 +81,18 @@ makefile overrides.
|
|||
|
||||
For example, to use a custom registry:
|
||||
|
||||
```
|
||||
```bash
|
||||
make IMAGE_REGISTRY=<my custom registry uri>
|
||||
```
|
||||
|
||||
Or to specify a build tool different from Docker, It can be done in 2 ways:
|
||||
|
||||
1. via environment
|
||||
```
|
||||
```bash
|
||||
IMAGE_BUILD_CMD="buildah bud" make
|
||||
```
|
||||
2. by overriding the variable value
|
||||
```
|
||||
1. by overriding the variable value
|
||||
```bash
|
||||
make IMAGE_BUILD_CMD="buildah bud"
|
||||
```
|
||||
|
||||
|
|
@ -98,18 +100,19 @@ make IMAGE_BUILD_CMD="buildah bud"
|
|||
|
||||
Unit tests are automatically run as part of the container image build. You can
|
||||
also run them manually in the source code tree by simply running:
|
||||
```
|
||||
|
||||
```bash
|
||||
make test
|
||||
```
|
||||
|
||||
End-to-end tests are built on top of the e2e test framework of Kubernetes, and,
|
||||
they required a cluster to run them on. For running the tests on your test
|
||||
cluster you need to specify the kubeconfig to be used:
|
||||
```
|
||||
|
||||
```bash
|
||||
make e2e-test KUBECONFIG=$HOME/.kube/config
|
||||
```
|
||||
|
||||
|
||||
## Running Locally
|
||||
|
||||
You can run NFD locally, either directly on your host OS or in containers for
|
||||
|
|
@ -121,15 +124,18 @@ features-detection.
|
|||
When running as a standalone container labeling is expected to fail because
|
||||
Kubernetes API is not available. Thus, it is recommended to use `--no-publish`
|
||||
command line flag. E.g.
|
||||
```
|
||||
$ docker run --rm --name=nfd-test <NFD_CONTAINER_IMAGE> nfd-master --no-publish
|
||||
|
||||
```bash
|
||||
$ export NFD_CONTAINER_IMAGE=gcr.io/k8s-staging-nfd/node-feature-discovery:master
|
||||
$ docker run --rm --name=nfd-test ${NFD_CONTAINER_IMAGE} nfd-master --no-publish
|
||||
2019/02/01 14:48:21 Node Feature Discovery Master <NFD_VERSION>
|
||||
2019/02/01 14:48:21 gRPC server serving on port: 8080
|
||||
```
|
||||
|
||||
Command line flags of nfd-master:
|
||||
```
|
||||
$ docker run --rm <NFD_CONTAINER_IMAGE> nfd-master --help
|
||||
|
||||
```bash
|
||||
$ docker run --rm ${NFD_CONTAINER_IMAGE} nfd-master --help
|
||||
...
|
||||
Usage:
|
||||
nfd-master [--prune] [--no-publish] [--label-whitelist=<pattern>] [--port=<port>]
|
||||
|
|
@ -168,22 +174,24 @@ Usage:
|
|||
[Default: ]
|
||||
```
|
||||
|
||||
|
||||
### NFD-Worker
|
||||
|
||||
In order to run nfd-worker as a "stand-alone" container against your
|
||||
standalone nfd-master you need to run them in the same network namespace:
|
||||
```
|
||||
$ docker run --rm --network=container:nfd-test <NFD_CONTAINER_IMAGE> nfd-worker
|
||||
|
||||
```bash
|
||||
$ docker run --rm --network=container:nfd-test ${NFD_CONTAINER_IMAGE} nfd-worker
|
||||
2019/02/01 14:48:56 Node Feature Discovery Worker <NFD_VERSION>
|
||||
...
|
||||
```
|
||||
|
||||
If you just want to try out feature discovery without connecting to nfd-master,
|
||||
pass the `--no-publish` flag to nfd-worker.
|
||||
|
||||
Command line flags of nfd-worker:
|
||||
```
|
||||
$ docker run --rm <CONTAINER_IMAGE_ID> nfd-worker --help
|
||||
|
||||
```bash
|
||||
$ docker run --rm ${NFD_CONTAINER_IMAGE} nfd-worker --help
|
||||
...
|
||||
nfd-worker.
|
||||
|
||||
|
|
@ -230,6 +238,7 @@ nfd-worker.
|
|||
value implies no re-labeling (i.e. infinite
|
||||
sleep). [Default: 60s]
|
||||
```
|
||||
|
||||
**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
|
||||
|
|
@ -237,7 +246,6 @@ stand-alone directly with `docker run`. See the
|
|||
[template spec](https://github.com/kubernetes-sigs/node-feature-discovery/blob/master/nfd-worker-daemonset.yaml.template)
|
||||
for up-to-date information about the required volume mounts.
|
||||
|
||||
|
||||
## Documentation
|
||||
|
||||
*WORK IN PROGRESS...*
|
||||
|
|
|
|||
|
|
@ -12,22 +12,23 @@ sort: 3
|
|||
|
||||
You can reach us via the following channels:
|
||||
|
||||
- [#node-feature-discovery](https://kubernetes.slack.com/messages/node-feature-discovery) channel in
|
||||
[Kubernetes Slack](slack.k8s.io)
|
||||
- [#node-feature-discovery](https://kubernetes.slack.com/messages/node-feature-discovery)
|
||||
channel in [Kubernetes Slack](slack.k8s.io)
|
||||
- [SIG-Node](https://groups.google.com/g/kubernetes-sig-node) mailing list
|
||||
- File an [issue](https://github.com/kubernetes-sigs/node-feature-discovery/issues/new) in this repository
|
||||
|
||||
- File an
|
||||
[issue](https://github.com/kubernetes-sigs/node-feature-discovery/issues/new)
|
||||
in this repository
|
||||
|
||||
## Governance
|
||||
|
||||
This is a [SIG-node](https://github.com/kubernetes/community/blob/master/sig-node/README.md)
|
||||
This is a
|
||||
[SIG-node](https://github.com/kubernetes/community/blob/master/sig-node/README.md)
|
||||
subproject, hosted under the
|
||||
[Kubernetes SIGs](https://github.com/kubernetes-sigs) organization in
|
||||
Github. The project was established in 2016 as a
|
||||
[Kubernetes SIGs](https://github.com/kubernetes-sigs) organization in Github.
|
||||
The project was established in 2016 as a
|
||||
[Kubernetes Incubator](https://github.com/kubernetes/community/blob/master/incubator.md)
|
||||
project and migrated to Kubernetes SIGs in 2018.
|
||||
|
||||
|
||||
## License
|
||||
|
||||
This is open source software released under the [Apache 2.0 License](LICENSE).
|
||||
|
|
|
|||
|
|
@ -24,9 +24,9 @@ sort: 3
|
|||
|
||||
## Usage
|
||||
|
||||
### nfd-master
|
||||
### NFD-Master
|
||||
|
||||
Nfd-master runs as a deployment (with a replica count of 1), by default
|
||||
NFD-Master runs as a deployment (with a replica count of 1), by default
|
||||
it prefers running on the cluster's master nodes but will run on worker
|
||||
nodes if no master nodes are found.
|
||||
|
||||
|
|
@ -45,7 +45,7 @@ make IMAGE_TAG=<IMAGE_TAG>
|
|||
docker push <IMAGE_TAG>
|
||||
kubectl create -f nfd-master.yaml
|
||||
```
|
||||
Nfd-master listens for connections from nfd-worker(s) and connects to the
|
||||
NFD-Master listens for connections from nfd-worker(s) and connects to the
|
||||
Kubernetes API server to add node labels advertised by them.
|
||||
|
||||
If you have RBAC authorization enabled (as is the default e.g. with clusters
|
||||
|
|
@ -54,9 +54,9 @@ ClusterRoleBindings and a ServiceAccount in order for NFD to create node
|
|||
labels. The provided template will configure these for you.
|
||||
|
||||
|
||||
### nfd-worker
|
||||
### NFD-Worker
|
||||
|
||||
Nfd-worker is preferably run as a Kubernetes DaemonSet. There is an
|
||||
NFD-Worker is preferably run as a Kubernetes DaemonSet. There is an
|
||||
example spec (`nfd-worker-daemonset.yaml.template`) that can be used
|
||||
as a template, or, as is when just trying out the service. Similarly
|
||||
to nfd-master above, the `Makefile` also generates
|
||||
|
|
@ -68,7 +68,7 @@ docker push <IMAGE_TAG>
|
|||
kubectl create -f nfd-worker-daemonset.yaml
|
||||
```
|
||||
|
||||
Nfd-worker connects to the nfd-master service to advertise hardware features.
|
||||
NFD-Worker connects to the nfd-master service to advertise hardware features.
|
||||
|
||||
When run as a daemonset, nodes are re-labeled at an interval specified using
|
||||
the `--sleep-interval` option. In the
|
||||
|
|
@ -88,7 +88,7 @@ The label-nodes.sh script tries to launch as many jobs as there are Ready nodes.
|
|||
Note that this approach does not guarantee running once on every node.
|
||||
For example, if some node is tainted NoSchedule or fails to start a job for some other reason, then some other node will run extra job instance(s) to satisfy the request and the tainted/failed node does not get labeled.
|
||||
|
||||
### nfd-master and nfd-worker in the same Pod
|
||||
### NFD-Master and NFD-Worker in the same Pod
|
||||
|
||||
You can also run nfd-master and nfd-worker inside a single pod (skip the `sed`
|
||||
part if running the latest released version):
|
||||
|
|
@ -148,7 +148,7 @@ build images and deploy them on your cluster.
|
|||
|
||||
## Configuration
|
||||
|
||||
Nfd-worker supports a configuration file. The default location is
|
||||
NFD-Worker supports a configuration file. The default location is
|
||||
`/etc/kubernetes/node-feature-discovery/nfd-worker.conf`, but,
|
||||
this can be changed by specifying the`--config` command line flag.
|
||||
Configuration file is re-read on each labeling pass (determined by
|
||||
|
|
|
|||
|
|
@ -23,7 +23,6 @@ This page contains usage examples and demos.
|
|||
|
||||
[](https://asciinema.org/a/247316)
|
||||
|
||||
|
||||
### Demo Use Case
|
||||
|
||||
A demo on the benefits of using node feature discovery can be found in the
|
||||
|
|
|
|||
|
|
@ -32,9 +32,11 @@ The published node labels encode a few pieces of information:
|
|||
- The value of the discovered feature.
|
||||
|
||||
Feature label names adhere to the following pattern:
|
||||
|
||||
```
|
||||
<namespace>/<source name>-<feature name>[.<attribute name>]
|
||||
```
|
||||
|
||||
The last component (i.e. `attribute-name`) is optional, and only used if a
|
||||
feature logically has sub-hierarchy, e.g. `sriov.capable` and
|
||||
`sriov.configure` from the `network` source.
|
||||
|
|
@ -46,7 +48,6 @@ 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
|
||||
|
||||
### CPU
|
||||
|
|
@ -56,15 +57,15 @@ The **cpu** feature source supports the following labels:
|
|||
| Feature name | Attribute | Description |
|
||||
| ----------------------- | ------------------ | ----------------------------- |
|
||||
| cpuid | <cpuid flag> | CPU capability is supported
|
||||
| hardware_multithreading | <br> | Hardware multithreading, such as Intel HTT, enabled (number of logical CPUs is greater than physical CPUs)
|
||||
| hardware_multithreading | | Hardware multithreading, such as Intel HTT, enabled (number of logical CPUs is greater than physical CPUs)
|
||||
| power | sst_bf.enabled | Intel SST-BF ([Intel Speed Select Technology][intel-sst] - Base frequency) enabled
|
||||
| [pstate][intel-pstate] | turbo | Set to 'true' if turbo frequencies are enabled in Intel pstate driver, set to 'false' if they have been disabled.
|
||||
| [rdt][intel-rdt] | RDTMON | Intel RDT Monitoring Technology
|
||||
| <br> | RDTCMT | Intel Cache Monitoring (CMT)
|
||||
| <br> | RDTMBM | Intel Memory Bandwidth Monitoring (MBM)
|
||||
| <br> | RDTL3CA | Intel L3 Cache Allocation Technology
|
||||
| <br> | RDTL2CA | Intel L2 Cache Allocation Technology
|
||||
| <br> | RDTMBA | Intel Memory Bandwidth Allocation (MBA) Technology
|
||||
| | RDTCMT | Intel Cache Monitoring (CMT)
|
||||
| | RDTMBM | Intel Memory Bandwidth Monitoring (MBM)
|
||||
| | RDTL3CA | Intel L3 Cache Allocation Technology
|
||||
| | RDTL2CA | Intel L2 Cache Allocation Technology
|
||||
| | RDTMBA | Intel Memory Bandwidth Allocation (MBA) Technology
|
||||
|
||||
The (sub-)set of CPUID attributes to publish is configurable via the
|
||||
`attributeBlacklist` and `attributeWhitelist` cpuid options of the cpu source.
|
||||
|
|
@ -79,7 +80,6 @@ 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)
|
||||
|
||||
| Attribute | Description |
|
||||
|
|
@ -120,14 +120,14 @@ capability might be supported but not enabled.
|
|||
| JSCVT | Perform Conversion to Match Javascript
|
||||
| DCPOP | Persistent Memory Support
|
||||
|
||||
|
||||
### Custom
|
||||
|
||||
The Custom feature source allows the user to define features based on a mix of predefined rules.
|
||||
A rule is provided input witch affects its process of matching for a defined feature.
|
||||
The Custom feature source allows the user to define features based on a mix of
|
||||
predefined rules. A rule is provided input witch affects its process of
|
||||
matching for a defined feature.
|
||||
|
||||
To aid in making Custom Features clearer, we define a general and a per rule nomenclature, keeping things as
|
||||
consistent as possible.
|
||||
To aid in making Custom Features clearer, we define a general and a per rule
|
||||
nomenclature, keeping things as consistent as possible.
|
||||
|
||||
#### General Nomenclature & Definitions
|
||||
|
||||
|
|
@ -159,11 +159,13 @@ Matcher :A composition of Rules, each Matcher may be composed of at most one
|
|||
Specifying Rules to match on a feature is done by providing a list of Matchers.
|
||||
Each Matcher contains one or more Rules.
|
||||
|
||||
Logical _OR_ is performed between Matchers and logical _AND_ is performed between Rules
|
||||
of a given Matcher.
|
||||
Logical _OR_ is performed between Matchers and logical _AND_ is performed
|
||||
between Rules of a given Matcher.
|
||||
|
||||
#### Rules
|
||||
|
||||
##### PciId Rule
|
||||
|
||||
###### Nomenclature
|
||||
|
||||
```
|
||||
|
|
@ -171,8 +173,9 @@ Attribute :A PCI attribute.
|
|||
Element :An identifier of the PCI attribute.
|
||||
```
|
||||
|
||||
The PciId Rule allows matching the PCI devices in the system on the following Attributes: `class`,`vendor` and
|
||||
`device`. A list of Elements is provided for each Attribute.
|
||||
The PciId Rule allows matching the PCI devices in the system on the following
|
||||
Attributes: `class`,`vendor` and `device`. A list of Elements is provided for
|
||||
each Attribute.
|
||||
|
||||
###### Format
|
||||
|
||||
|
|
@ -183,11 +186,13 @@ pciId :
|
|||
device: [<device id>, ...]
|
||||
```
|
||||
|
||||
Matching is done by performing a logical _OR_ between Elements of an Attribute 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.
|
||||
Matching is done by performing a logical _OR_ between Elements of an Attribute
|
||||
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
|
||||
|
||||
###### Nomenclature
|
||||
|
||||
```
|
||||
|
|
@ -195,8 +200,9 @@ Attribute :A USB attribute.
|
|||
Element :An identifier of the USB attribute.
|
||||
```
|
||||
|
||||
The UsbId Rule allows matching the USB devices in the system on the following Attributes: `class`,`vendor` and
|
||||
`device`. A list of Elements is provided for each Attribute.
|
||||
The UsbId Rule allows matching the USB devices in the system on the following
|
||||
Attributes: `class`,`vendor` and `device`. A list of Elements is provided for
|
||||
each Attribute.
|
||||
|
||||
###### Format
|
||||
|
||||
|
|
@ -207,56 +213,73 @@ usbId :
|
|||
device: [<device id>, ...]
|
||||
```
|
||||
|
||||
Matching is done by performing a logical _OR_ between Elements of an Attribute 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.
|
||||
Matching is done by performing a logical _OR_ between Elements of an Attribute
|
||||
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
|
||||
|
||||
###### Nomenclature
|
||||
|
||||
```
|
||||
Element :A kernel module
|
||||
```
|
||||
|
||||
The LoadedKMod Rule allows matching the loaded kernel modules in the system against a provided list of Elements.
|
||||
The LoadedKMod Rule allows matching the loaded kernel modules in the system
|
||||
against a provided list of Elements.
|
||||
|
||||
###### Format
|
||||
|
||||
```yaml
|
||||
loadedKMod : [<kernel module>, ...]
|
||||
```
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
###### Nomenclature
|
||||
|
||||
```
|
||||
Element :A CPUID flag
|
||||
```
|
||||
|
||||
The Rule allows matching the available CPUID flags in the system against a provided list of Elements.
|
||||
The Rule allows matching the available CPUID flags in the system against a
|
||||
provided list of Elements.
|
||||
|
||||
###### Format
|
||||
|
||||
```yaml
|
||||
cpuId : [<CPUID flag string>, ...]
|
||||
```
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
###### Nomenclature
|
||||
|
||||
```
|
||||
Element :A Kconfig option
|
||||
```
|
||||
|
||||
The Rule allows matching the kconfig options in the system against a provided list of Elements.
|
||||
The Rule allows matching the kconfig options in the system against a provided
|
||||
list of Elements.
|
||||
|
||||
###### Format
|
||||
|
||||
```yaml
|
||||
kConfig: [<kernel config option ('y' or 'm') or '=<value>'>, ...]
|
||||
```
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
@ -280,7 +303,7 @@ custom:
|
|||
- loadedKMod : ["vendor_kmod1", "vendor_kmod2"]
|
||||
pciId:
|
||||
vendor: ["15b3"]
|
||||
device: ["1014", "1017"]
|
||||
device: ["1014", "1017"]
|
||||
- name: "my.accumulated.feature"
|
||||
matchOn:
|
||||
- loadedKMod : ["some_kmod1", "some_kmod2"]
|
||||
|
|
@ -298,42 +321,55 @@ custom:
|
|||
```
|
||||
|
||||
__In the example above:__
|
||||
- A node would contain the label: `feature.node.kubernetes.io/custom-my.kernel.feature=true`
|
||||
if the node has `kmod1` _AND_ `kmod2` kernel modules loaded.
|
||||
- A node would contain the label: `feature.node.kubernetes.io/custom-my.pci.feature=true`
|
||||
if the node contains a PCI device with a PCI vendor ID of `15b3` _AND_ PCI device ID of `1014` _OR_ `1017`.
|
||||
- A node would contain the label: `feature.node.kubernetes.io/custom-my.usb.feature=true`
|
||||
if the node contains a USB device with a USB vendor ID of `1d6b` _AND_ USB device ID of `0003`.
|
||||
- A node would contain the label: `feature.node.kubernetes.io/custom-my.combined.feature=true`
|
||||
if `vendor_kmod1` _AND_ `vendor_kmod2` kernel modules are loaded __AND__ the node contains a PCI device
|
||||
with a PCI vendor ID of `15b3` _AND_ PCI device ID of `1014` _or_ `1017`.
|
||||
- A node would contain the label: `feature.node.kubernetes.io/custom-my.accumulated.feature=true`
|
||||
if `some_kmod1` _AND_ `some_kmod2` kernel modules are loaded __OR__ the node contains a PCI device
|
||||
with a PCI vendor ID of `15b3` _AND_ PCI device ID of `1014` _OR_ `1017`.
|
||||
- A node would contain the label: `feature.node.kubernetes.io/custom-my.kernel.featureneedscpu=true`
|
||||
if `KVM_INTEL` kernel config is enabled __AND__ the node CPU supports `VMX` virtual machine extensions
|
||||
- A node would contain the label: `feature.node.kubernetes.io/custom-my.kernel.modulecompiler=true` if the in-tree `kmod1` kernel module is loaded __AND__ it's built with `GCC_VERSION=100101`.
|
||||
|
||||
- A node would contain the label:
|
||||
`feature.node.kubernetes.io/custom-my.kernel.feature=true` if the node has
|
||||
`kmod1` _AND_ `kmod2` kernel modules loaded.
|
||||
- A node would contain the label:
|
||||
`feature.node.kubernetes.io/custom-my.pci.feature=true` if the node contains
|
||||
a PCI device with a PCI vendor ID of `15b3` _AND_ PCI device ID of `1014` _OR_
|
||||
`1017`.
|
||||
- A node would contain the label:
|
||||
`feature.node.kubernetes.io/custom-my.usb.feature=true` if the node contains
|
||||
a USB device with a USB vendor ID of `1d6b` _AND_ USB device ID of `0003`.
|
||||
- A node would contain the label:
|
||||
`feature.node.kubernetes.io/custom-my.combined.feature=true` if
|
||||
`vendor_kmod1` _AND_ `vendor_kmod2` kernel modules are loaded __AND__ the node
|
||||
contains a PCI device
|
||||
with a PCI vendor ID of `15b3` _AND_ PCI device ID of `1014` _or_ `1017`.
|
||||
- A node would contain the label:
|
||||
`feature.node.kubernetes.io/custom-my.accumulated.feature=true` if
|
||||
`some_kmod1` _AND_ `some_kmod2` kernel modules are loaded __OR__ the node
|
||||
contains a PCI device
|
||||
with a PCI vendor ID of `15b3` _AND_ PCI device ID of `1014` _OR_ `1017`.
|
||||
- A node would contain the label:
|
||||
`feature.node.kubernetes.io/custom-my.kernel.featureneedscpu=true` if
|
||||
`KVM_INTEL` kernel config is enabled __AND__ the node CPU supports `VMX`
|
||||
virtual machine extensions
|
||||
- A node would contain the label:
|
||||
`feature.node.kubernetes.io/custom-my.kernel.modulecompiler=true` if the
|
||||
in-tree `kmod1` kernel module is loaded __AND__ it's built with
|
||||
`GCC_VERSION=100101`.
|
||||
|
||||
#### Statically defined features
|
||||
|
||||
Some feature labels which are common and generic are defined statically in the `custom` feature source.
|
||||
A user may add additional Matchers to these feature labels by defining them in the `nfd-worker` configuration file.
|
||||
Some feature labels which are common and generic are defined statically in the
|
||||
`custom` feature source. A user may add additional Matchers to these feature
|
||||
labels by defining them in the `nfd-worker` configuration file.
|
||||
|
||||
| Feature | Attribute | Description |
|
||||
| ------- | --------- | -----------|
|
||||
| rdma | capable | The node has an RDMA capable Network adapter |
|
||||
| rdma | enabled | The node has the needed RDMA modules loaded to run RDMA traffic |
|
||||
|
||||
|
||||
### IOMMU
|
||||
|
||||
The **iommu** feature source supports the following labels:
|
||||
|
||||
| Feature name | Description |
|
||||
| :------------: | :---------------------------------------------------------------------------------: |
|
||||
| Feature name | Description |
|
||||
| :------------: | :---------------------------------------------------------: |
|
||||
| enabled | IOMMU is present and enabled in the kernel
|
||||
|
||||
|
||||
### Kernel
|
||||
|
||||
The **kernel** feature source supports the following labels:
|
||||
|
|
@ -343,26 +379,24 @@ The **kernel** feature source supports the following labels:
|
|||
| config | <option name> | Kernel config option is enabled (set 'y' or 'm').<br> Default options are `NO_HZ`, `NO_HZ_IDLE`, `NO_HZ_FULL` and `PREEMPT`
|
||||
| selinux | enabled | Selinux is enabled on the node
|
||||
| version | full | Full kernel version as reported by `/proc/sys/kernel/osrelease` (e.g. '4.5.6-7-g123abcde')
|
||||
| <br> | major | First component of the kernel version (e.g. '4')
|
||||
| <br> | minor | Second component of the kernel version (e.g. '5')
|
||||
| <br> | revision | Third component of the kernel version (e.g. '6')
|
||||
| | major | First component of the kernel version (e.g. '4')
|
||||
| | minor | Second component of the kernel version (e.g. '5')
|
||||
| | revision | Third component of the kernel version (e.g. '6')
|
||||
|
||||
Kernel config file to use, and, the set of config options to be detected are
|
||||
configurable.
|
||||
See [configuration options](#configuration-options) for more information.
|
||||
|
||||
|
||||
### Memory
|
||||
|
||||
The **memory** feature source supports the following labels:
|
||||
|
||||
| Feature | Attribute | Description |
|
||||
| ------- | --------- | ------------------------------------------------------ |
|
||||
| numa | <br> | Multiple memory nodes i.e. NUMA architecture detected
|
||||
| numa | | Multiple memory nodes i.e. NUMA architecture detected
|
||||
| nv | present | NVDIMM device(s) are present
|
||||
| nv | dax | NVDIMM region(s) configured in DAX mode are present
|
||||
|
||||
|
||||
### Network
|
||||
|
||||
The **network** feature source supports the following labels:
|
||||
|
|
@ -370,23 +404,22 @@ The **network** feature source supports the following labels:
|
|||
| Feature | Attribute | Description |
|
||||
| ------- | ---------- | ----------------------------------------------------- |
|
||||
| sriov | capable | [Single Root Input/Output Virtualization][sriov] (SR-IOV) enabled Network Interface Card(s) present
|
||||
| <br> | configured | SR-IOV virtual functions have been configured
|
||||
|
||||
| | configured | SR-IOV virtual functions have been configured
|
||||
|
||||
### PCI
|
||||
|
||||
The **pci** feature source supports the following labels:
|
||||
|
||||
| Feature | Attribute | Description |
|
||||
| -------------------- | ------------- | ----------------------------------------- |
|
||||
| Feature | Attribute | Description |
|
||||
| -------------------- | ------------- | ------------------------------------- |
|
||||
| <device label> | present | PCI device is detected
|
||||
| <device label> | sriov.capable | [Single Root Input/Output Virtualization][sriov] (SR-IOV) enabled PCI device present
|
||||
|
||||
`<device label>` is composed of raw PCI IDs, separated by underscores.
|
||||
The set of fields used in `<device label>` is configurable, valid fields being
|
||||
`class`, `vendor`, `device`, `subsystem_vendor` and `subsystem_device`.
|
||||
Defaults are `class` and `vendor`. An example label using the default
|
||||
label fields:
|
||||
`<device label>` is composed of raw PCI IDs, separated by underscores. The set
|
||||
of fields used in `<device label>` is configurable, valid fields being `class`,
|
||||
`vendor`, `device`, `subsystem_vendor` and `subsystem_device`. Defaults are
|
||||
`class` and `vendor`. An example label using the default label fields:
|
||||
|
||||
```
|
||||
feature.node.kubernetes.io/pci-1200_8086.present=true
|
||||
```
|
||||
|
|
@ -395,37 +428,34 @@ Also the set of PCI device classes that the feature source detects is
|
|||
configurable. By default, device classes (0x)03, (0x)0b40 and (0x)12, i.e.
|
||||
GPUs, co-processors and accelerator cards are detected.
|
||||
|
||||
|
||||
### USB
|
||||
|
||||
The **usb** feature source supports the following labels:
|
||||
|
||||
| Feature | Attribute | Description |
|
||||
| -------------------- | ------------- | ----------------------------------------- |
|
||||
| Feature | Attribute | Description |
|
||||
| -------------------- | ------------- | ------------------------------------- |
|
||||
| <device label> | present | USB device is detected
|
||||
|
||||
`<device label>` is composed of raw USB IDs, separated by underscores.
|
||||
The set of fields used in `<device label>` is configurable, valid fields being
|
||||
`class`, `vendor`, and `device`.
|
||||
Defaults are `class`, `vendor` and `device`. An example label using the default
|
||||
label fields:
|
||||
`<device label>` is composed of raw USB IDs, separated by underscores. The set
|
||||
of fields used in `<device label>` is configurable, valid fields being `class`,
|
||||
`vendor`, and `device`. Defaults are `class`, `vendor` and `device`. An
|
||||
example label using the default label fields:
|
||||
|
||||
```
|
||||
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
|
||||
```
|
||||
|
||||
See [configuration options](#configuration-options)
|
||||
for more information on NFD config.
|
||||
|
||||
See [configuration options](#configuration-options) for more information on NFD
|
||||
config.
|
||||
|
||||
### Storage
|
||||
|
||||
The **storage** feature source supports the following labels:
|
||||
|
||||
| Feature name | Description |
|
||||
| :--------------: | :---------------------------------------------------------------------------------: |
|
||||
| Feature name | Description |
|
||||
| ------------------ | ------------------------------------------------------- |
|
||||
| nonrotationaldisk | Non-rotational disk, like SSD, is present in the node
|
||||
|
||||
|
||||
### System
|
||||
|
||||
The **system** feature source supports the following labels:
|
||||
|
|
@ -433,29 +463,31 @@ The **system** feature source supports the following labels:
|
|||
| Feature | Attribute | Description |
|
||||
| ----------- | ---------------- | --------------------------------------------|
|
||||
| os_release | ID | Operating system identifier
|
||||
| <br> | VERSION_ID | Operating system version identifier (e.g. '6.7')
|
||||
| <br> | VERSION_ID.major | First component of the OS version id (e.g. '6')
|
||||
| <br> | VERSION_ID.minor | Second component of the OS version id (e.g. '7')
|
||||
|
||||
| | VERSION_ID | Operating system version identifier (e.g. '6.7')
|
||||
| | 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
|
||||
|
||||
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 users to
|
||||
implement custom feature sources in a pluggable way, without modifying nfd
|
||||
source code or Docker images. The local feature source can be used to advertise
|
||||
new user-specific features, and, for overriding labels created by the other
|
||||
feature sources.
|
||||
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
|
||||
users to implement custom feature sources in a pluggable way, without modifying
|
||||
nfd source code or Docker images. The local feature source can be used to
|
||||
advertise new user-specific features, and, for overriding labels created by the
|
||||
other feature sources.
|
||||
|
||||
The *local* feature source gets its labels by two different ways:
|
||||
* It tries to execute files found under `/etc/kubernetes/node-feature-discovery/source.d/`
|
||||
directory. The hook files must be executable and they are supposed to print all
|
||||
discovered features in `stdout`, one per line. With ELF binaries static
|
||||
linking is recommended as the selection of system libraries available in the
|
||||
NFD release image is very limited. Other runtimes currently supported by the
|
||||
NFD stock image are bash and perl.
|
||||
* It reads files found under `/etc/kubernetes/node-feature-discovery/features.d/`
|
||||
directory. The file content is expected to be similar to the hook output (described above).
|
||||
|
||||
- It tries to execute files found under
|
||||
`/etc/kubernetes/node-feature-discovery/source.d/` directory. The hook files
|
||||
must be executable and they are supposed to print all discovered features in
|
||||
`stdout`, one per line. With ELF binaries static linking is recommended as
|
||||
the selection of system libraries available in the NFD release image is very
|
||||
limited. Other runtimes currently supported by the NFD stock image are bash
|
||||
and perl.
|
||||
- It reads files found under
|
||||
`/etc/kubernetes/node-feature-discovery/features.d/` directory. The file
|
||||
content is expected to be similar to the hook output (described above).
|
||||
|
||||
These directories must be available inside the Docker image so Volumes and
|
||||
VolumeMounts must be used if standard NFD images are used. The given template
|
||||
|
|
@ -497,12 +529,12 @@ 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
|
||||
|
||||
User has a shell script
|
||||
`/etc/kubernetes/node-feature-discovery/source.d/my-source` which has the
|
||||
following `stdout` output:
|
||||
|
||||
```
|
||||
MY_FEATURE_1
|
||||
MY_FEATURE_2=myvalue
|
||||
|
|
@ -510,7 +542,9 @@ MY_FEATURE_2=myvalue
|
|||
/override_source-OVERRIDE_VALUE=123
|
||||
override.namespace/value=456
|
||||
```
|
||||
|
||||
which, in turn, will translate into the following node labels:
|
||||
|
||||
```
|
||||
feature.node.kubernetes.io/my-source-MY_FEATURE_1=true
|
||||
feature.node.kubernetes.io/my-source-MY_FEATURE_2=myvalue
|
||||
|
|
@ -521,9 +555,9 @@ override.namespace/value=456
|
|||
|
||||
#### A File Example
|
||||
|
||||
User has a file
|
||||
`/etc/kubernetes/node-feature-discovery/features.d/my-source` which contains the
|
||||
following lines:
|
||||
User has a file `/etc/kubernetes/node-feature-discovery/features.d/my-source`
|
||||
which contains the following lines:
|
||||
|
||||
```
|
||||
MY_FEATURE_1
|
||||
MY_FEATURE_2=myvalue
|
||||
|
|
@ -531,7 +565,9 @@ MY_FEATURE_2=myvalue
|
|||
/override_source-OVERRIDE_VALUE=123
|
||||
override.namespace/value=456
|
||||
```
|
||||
|
||||
which, in turn, will translate into the following node labels:
|
||||
|
||||
```
|
||||
feature.node.kubernetes.io/my-source-MY_FEATURE_1=true
|
||||
feature.node.kubernetes.io/my-source-MY_FEATURE_2=myvalue
|
||||
|
|
@ -556,8 +592,6 @@ temporary file (outside the `source.d` and `features.d` directories), and,
|
|||
atomically create/update the original file by doing a filesystem move
|
||||
operation.
|
||||
|
||||
|
||||
|
||||
## Extended resources
|
||||
|
||||
This feature is experimental and by no means a replacement for the usage of
|
||||
|
|
@ -584,12 +618,12 @@ Example usage of the command line arguments, using a new namespace:
|
|||
|
||||
The above would result in following extended resources provided that related
|
||||
labels exist:
|
||||
|
||||
```
|
||||
sgx.some.ns/epc: <label value>
|
||||
feature.node.kubernetes.io/my_source-my.feature: <label value>
|
||||
```
|
||||
|
||||
|
||||
<!-- Links -->
|
||||
[intel-rdt]: http://www.intel.com/content/www/us/en/architecture-and-technology/resource-director-technology.html
|
||||
[intel-pstate]: https://www.kernel.org/doc/Documentation/cpu-freq/intel-pstate.txt
|
||||
|
|
|
|||
|
|
@ -20,27 +20,26 @@ hardware features available on each node in a Kubernetes cluster, and
|
|||
advertises those features using node labels.
|
||||
|
||||
NFD consists of two software components:
|
||||
1. nfd-master
|
||||
2. nfd-worker
|
||||
|
||||
1. nfd-master
|
||||
1. nfd-worker
|
||||
|
||||
## NFD-Master
|
||||
|
||||
Nfd-master is the daemon responsible for communication towards the Kubernetes
|
||||
NFD-Master is the daemon responsible for communication towards the Kubernetes
|
||||
API. That is, it receives labeling requests from the worker and modifies node
|
||||
objects accordingly.
|
||||
|
||||
|
||||
## NFD-Worker
|
||||
|
||||
Nfd-worker is a daemon responsible for feature detection. It then communicates
|
||||
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 is divided into domain-specific feature sources:
|
||||
|
||||
- CPU
|
||||
- IOMMU
|
||||
- Kernel
|
||||
|
|
@ -60,6 +59,7 @@ Non-standard user-specific feature labels can be created with the local and
|
|||
custom feature sources.
|
||||
|
||||
An overview of the default feature labels:
|
||||
|
||||
```json
|
||||
{
|
||||
"feature.node.kubernetes.io/cpu-<feature-name>": "true",
|
||||
|
|
@ -76,7 +76,6 @@ An overview of the default feature labels:
|
|||
}
|
||||
```
|
||||
|
||||
|
||||
## Node Annotations
|
||||
|
||||
NFD also annotates nodes it is running on:
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue