404
Not Found
Not Found
git clone https://github.com/kubernetes-sigs/node-feature-discovery
+cd node-feature-discovery
+See customizing the build below for altering the container image registry, for example.
make
+Optional, this example with Docker.
docker push <IMAGE_TAG>
+To use your published image from the step above instead of the k8s.gcr.io/nfd/node-feature-discovery image, edit image attribute in the spec template(s) to the new location (<registry-name>/<image-name>[:<version>]).
The yamls makefile generates a kustomization.yaml matching your locally built image and using the deploy/overlays/default deployment. See build customization below for configurability, e.g. changing the deployment namespace.
K8S_NAMESPACE=my-ns make yamls
+kubectl apply -k .
+You can use alternative deployment methods by modifying the auto-generated kustomization file. For example, deploying worker and master in the same pod by pointing to deployment/overlays/default-combined.
You can also build the binaries locally
make build
+This will compile binaries under bin/
There are several Makefile variables that control the build process and the name of the resulting container image. The following are targeted targeted for build customization and they can be specified via environment variables or makefile overrides.
| Variable | Description | Default value |
|---|---|---|
| HOSTMOUNT_PREFIX | Prefix of system directories for feature discovery (local builds) | / (local builds) /host- (container builds) |
| IMAGE_BUILD_CMD | Command to build the image | docker build |
| IMAGE_BUILD_EXTRA_OPTS | Extra options to pass to build command | empty |
| IMAGE_PUSH_CMD | Command to push the image to remote registry | docker push |
| IMAGE_REGISTRY | Container image registry to use | k8s.gcr.io/nfd |
| IMAGE_TAG_NAME | Container image tag name | <nfd version> |
| IMAGE_EXTRA_TAG_NAMES | Additional container image tag(s) to create when building image | empty |
| K8S_NAMESPACE | nfd-master and nfd-worker namespace | kube-system |
| KUBECONFIG | Kubeconfig for running e2e-tests | empty |
| E2E_TEST_CONFIG | Parameterization file of e2e-tests (see example) | empty |
| OPENSHIFT | Non-empty value enables OpenShift specific support (currently only effective in e2e tests) | empty |
| BASE_IMAGE_FULL | Container base image for target image full (–target full) | debian:buster-slim |
| BASE_IMAGE_MINIMAL | Container base image for target image minimal (–target minimal) | gcr.io/distroless/base |
For example, to use a custom registry:
make IMAGE_REGISTRY=<my custom registry uri>
+Or to specify a build tool different from Docker, It can be done in 2 ways:
via environment
IMAGE_BUILD_CMD="buildah bud" make
+by overriding the variable value
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:
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:
make e2e-test KUBECONFIG=$HOME/.kube/config
+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 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.
$ export NFD_CONTAINER_IMAGE=k8s.gcr.io/nfd/node-feature-discovery:v0.9.0
+$ 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
+Usage of nfd-master:
+ -ca-file string
+ Root certificate for verifying connections
+ -cert-file string
+ Certificate used for authenticating connections
+ -extra-label-ns value
+ Comma separated list of allowed extra label namespaces
+ -instance string
+ Instance name. Used to separate annotation namespaces for multiple parallel deployments.
+ -key-file string
+ Private key matching -cert-file
+ -kubeconfig string
+ Kubeconfig to use
+ -label-whitelist value
+ Regular expression to filter label names to publish to the Kubernetes API server. NB: the label namespace is omitted i.e. the filter is only applied to the name part after '/'.
+ -no-publish
+ Do not publish feature labels
+ -port int
+ Port on which to listen for connections. (default 8080)
+ -prune
+ Prune all NFD related attributes from all nodes of the cluaster and exit.
+ -resource-labels value
+ Comma separated list of labels to be exposed as extended resources.
+ -verify-node-name
+ Verify worker node name against the worker's TLS certificate. Only takes effect when TLS authentication has been enabled.
+ -version
+ Print version and exit.
+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
+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 ${NFD_CONTAINER_IMAGE} nfd-worker -help
+Usage of nfd-worker:
+ -ca-file string
+ Root certificate for verifying connections
+ -cert-file string
+ Certificate used for authenticating connections
+ -config string
+ Config file to use. (default "/etc/kubernetes/node-feature-discovery/nfd-worker.conf")
+ -key-file string
+ Private key matching -cert-file
+ -label-whitelist value
+ Regular expression to filter label names to publish to the Kubernetes API server. NB: the label namespace is omitted i.e. the filter is only applied to the name part after '/'. DEPRECATED: This parameter should be set via the config file.
+ -no-publish
+ Do not publish discovered features, disable connection to nfd-master.
+ -oneshot
+ Do not publish feature labels
+ -options string
+ Specify config options from command line. Config options are specified in the same format as in the config file (i.e. json or yaml). These options
+ -server string
+ NFD server address to connecto to. (default "localhost:8080")
+ -server-name-override string
+ Hostname expected from server certificate, useful in testing
+ -sleep-interval duration
+ Time to sleep between re-labeling. Non-positive value implies no re-labeling (i.e. infinite sleep). DEPRECATED: This parameter should be set via the config file
+ -sources value
+ Comma separated list of feature sources. Special value 'all' enables all feature sources. DEPRECATED: This parameter should be set via the config file
+ -version
+ Print version and exit.
+NOTE Some feature sources need certain directories and/or files from the host mounted inside the NFD container. Thus, you need to provide Docker with the correct --volume options in order for them to work correctly when run stand-alone directly with docker run. See the default deployment for up-to-date information about the required volume mounts.
All documentation resides under the docs directory in the source tree. It is designed to be served as a html site by GitHub Pages.
Building the documentation is containerized in order to fix the build environment. The recommended way for developing documentation is to run:
make site-serve
+This will build the documentation in a container and serve it under localhost:4000/ making it easy to verify the results. Any changes made to the docs/ will automatically re-trigger a rebuild and are reflected in the served content and can be inspected with a simple browser refresh.
In order to just build the html documentation run:
make site-build
+This will generate html documentation under docs/_site/.
Advanced topics and reference.
To quickly view available command line flags execute nfd-master -help. In a docker container:
docker run k8s.gcr.io/nfd/node-feature-discovery:v0.9.0 nfd-master -help
+Print usage and exit.
Print version and exit.
The -prune flag is a sub-command like option for cleaning up the cluster. It causes nfd-master to remove all NFD related labels, annotations and extended resources from all Node objects of the cluster and exit.
The -port flag specifies the TCP port that nfd-master listens for incoming requests.
Default: 8080
Example:
nfd-master -port=443
+The -instance flag makes it possible to run multiple NFD deployments in parallel. In practice, it separates the node annotations between deployments so that each of them can store metadata independently. The instance name must start and end with an alphanumeric character and may only contain alphanumeric characters, -, _ or ..
Default: empty
Example:
nfd-master -instance=network
+The -ca-file is one of the three flags (together with -cert-file and -key-file) controlling master-worker mutual TLS authentication on the nfd-master side. This flag specifies the TLS root certificate that is used for authenticating incoming connections. NFD-Worker side needs to have matching key and cert files configured in order for the incoming requests to be accepted.
Default: empty
Note: Must be specified together with -cert-file and -key-file
Example:
nfd-master -ca-file=/opt/nfd/ca.crt -cert-file=/opt/nfd/master.crt -key-file=/opt/nfd/master.key
+The -cert-file is one of the three flags (together with -ca-file and -key-file) controlling master-worker mutual TLS authentication on the nfd-master side. This flag specifies the TLS certificate presented for authenticating outgoing traffic towards nfd-worker.
Default: empty
Note: Must be specified together with -ca-file and -key-file
Example:
nfd-master -cert-file=/opt/nfd/master.crt -key-file=/opt/nfd/master.key -ca-file=/opt/nfd/ca.crt
+The -key-file is one of the three flags (together with -ca-file and -cert-file) controlling master-worker mutual TLS authentication on the nfd-master side. This flag specifies the private key corresponding the given certificate file (-cert-file) that is used for authenticating outgoing traffic.
Default: empty
Note: Must be specified together with -cert-file and -ca-file
Example:
nfd-master -key-file=/opt/nfd/master.key -cert-file=/opt/nfd/master.crt -ca-file=/opt/nfd/ca.crt
+The -verify-node-name flag controls the NodeName based authorization of incoming requests and only has effect when mTLS authentication has been enabled (with -ca-file, -cert-file and -key-file). If enabled, the worker node name of the incoming must match with the CN or a SAN in its TLS certificate. Thus, workers are only able to label the node they are running on (or the node whose certificate they present).
Node Name based authorization is disabled by default.
Default: false
Example:
nfd-master -verify-node-name -ca-file=/opt/nfd/ca.crt \
+ -cert-file=/opt/nfd/master.crt -key-file=/opt/nfd/master.key
+The -no-publish flag disables all communication with the Kubernetes API server, making a "dry-run" flag for nfd-master. No Labels, Annotations or ExtendedResources (or any other properties of any Kubernetes API objects) are modified.
Default: false
Example:
nfd-master -no-publish
+The -label-whitelist specifies a regular expression for filtering feature labels based on their name. Each label must match against the given reqular expression in order to be published.
Note: The regular expression is only matches against the "basename" part of the label, i.e. to the part of the name after ‘/'. The label namespace is omitted.
Default: empty
Example:
nfd-master -label-whitelist='.*cpuid\.'
+The -extra-label-ns flag specifies a comma-separated list of allowed feature label namespaces. By default, nfd-master only allows creating labels in the default feature.node.kubernetes.io label namespace and its sub-namespaces (e.g. vendor.feature.node.kubernetes.io). This option can be used to allow other vendor or application specific namespaces for custom labels from the local and custom feature sources.
The same namespace control and this flag applies Extended Resources (created with -resource-labels), too.
Default: empty
Example:
nfd-master -extra-label-ns=vendor-1.com,vendor-2.io
+The -resource-labels flag specifies a comma-separated list of features to be advertised as extended resources instead of labels. Features that have integer values can be published as Extended Resources by listing them in this flag.
Default: empty
Example:
nfd-master -resource-labels=vendor-1.com/feature-1,vendor-2.io/feature-2
+The following logging-related flags are inherited from the klog package.
If true, adds the file directory to the header of the log messages.
Default: false
Log to standard error as well as files.
Default: false
When logging hits line file:N, emit a stack trace.
Default: empty
If non-empty, write log files in this directory.
Default: empty
If non-empty, use this log file.
Default: empty
Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited.
Default: 1800
Log to standard error instead of files
Default: true
If true, avoid header prefixes in the log messages.
Default: false
If true, avoid headers when opening log files.
Default: false
Logs at or above this threshold go to stderr.
Default: 2
Number for the log level verbosity.
Default: 0
Comma-separated list of pattern=N settings for file-filtered logging.
Default: empty
To quickly view available command line flags execute nfd-worker -help. In a docker container:
docker run k8s.gcr.io/nfd/node-feature-discovery:v0.9.0 nfd-worker -help
+Print usage and exit.
Print version and exit.
The -config flag specifies the path of the nfd-worker configuration file to use.
Default: /etc/kubernetes/node-feature-discovery/nfd-worker.conf
Example:
nfd-worker -config=/opt/nfd/worker.conf
+The -options flag may be used to specify and override configuration file options directly from the command line. The required format is the same as in the config file i.e. JSON or YAML. Configuration options specified via this flag will override those from the configuration file:
Default: empty
Example:
nfd-worker -options='{"sources":{"cpu":{"cpuid":{"attributeWhitelist":["AVX","AVX2"]}}}}'
+The -server flag specifies the address of the nfd-master endpoint where to connect to.
Default: localhost:8080
Example:
nfd-worker -server=nfd-master.nfd.svc.cluster.local:443
+The -ca-file is one of the three flags (together with -cert-file and -key-file) controlling the mutual TLS authentication on the worker side. This flag specifies the TLS root certificate that is used for verifying the authenticity of nfd-master.
Default: empty
Note: Must be specified together with -cert-file and -key-file
Example:
nfd-worker -ca-file=/opt/nfd/ca.crt -cert-file=/opt/nfd/worker.crt -key-file=/opt/nfd/worker.key
+The -cert-file is one of the three flags (together with -ca-file and -key-file) controlling mutual TLS authentication on the worker side. This flag specifies the TLS certificate presented for authenticating outgoing requests.
Default: empty
Note: Must be specified together with -ca-file and -key-file
Example:
nfd-workerr -cert-file=/opt/nfd/worker.crt -key-file=/opt/nfd/worker.key -ca-file=/opt/nfd/ca.crt
+The -key-file is one of the three flags (together with -ca-file and -cert-file) controlling the mutual TLS authentication on the worker side. This flag specifies the private key corresponding the given certificate file (-cert-file) that is used for authenticating outgoing requests.
Default: empty
Note: Must be specified together with -cert-file and -ca-file
Example:
nfd-worker -key-file=/opt/nfd/worker.key -cert-file=/opt/nfd/worker.crt -ca-file=/opt/nfd/ca.crt
+The -server-name-override flag specifies the common name (CN) which to expect from the nfd-master TLS certificate. This flag is mostly intended for development and debugging purposes.
Default: empty
Example:
nfd-worker -server-name-override=localhost
+The -sources flag specifies a comma-separated list of enabled feature sources. A special value all enables all feature sources.
Note: This flag takes precedence over the core.sources configuration file option.
Default: all
Example:
nfd-worker -sources=kernel,system,local
+DEPRECATED: you should use the core.sources option in the configuration file, instead.
The -no-publish flag disables all communication with the nfd-master, making it a "dry-run" flag for nfd-worker. NFD-Worker runs feature detection normally, but no labeling requests are sent to nfd-master.
Default: false
Example:
nfd-worker -no-publish
+The -label-whitelist specifies a regular expression for filtering feature labels based on their name. Each label must match against the given reqular expression in order to be published.
Note: The regular expression is only matches against the "basename" part of the label, i.e. to the part of the name after ‘/'. The label namespace is omitted.
Note: This flag takes precedence over the core.labelWhiteList configuration file option.
Default: empty
Example:
nfd-worker -label-whitelist='.*cpuid\.'
+DEPRECATED: you should use the core.labelWhiteList option in the configuration file, instead.
The -oneshot flag causes nfd-worker to exit after one pass of feature detection.
Default: false
Example:
nfd-worker -oneshot -no-publish
+The -sleep-interval specifies the interval between feature re-detection (and node re-labeling). A non-positive value implies infinite sleep interval, i.e. no re-detection or re-labeling is done.
Note: This flag takes precedence over the core.sleepInterval configuration file option.
Default: 60s
Example:
nfd-worker -sleep-interval=1h
+DEPRECATED: you should use the core.sleepInterval option in the configuration file, instead.
The following logging-related flags are inherited from the klog package.
Note: The logger setup can also be specified via the core.klog configuration file options. However, the command line flags take precedence over any corresponding config file options specified.
If true, adds the file directory to the header of the log messages.
Default: false
Log to standard error as well as files.
Default: false
When logging hits line file:N, emit a stack trace.
Default: empty
If non-empty, write log files in this directory.
Default: empty
If non-empty, use this log file.
Default: empty
Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited.
Default: 1800
Log to standard error instead of files
Default: true
If true, avoid header prefixes in the log messages.
Default: false
If true, avoid headers when opening log files.
Default: false
Logs at or above this threshold go to stderr.
Default: 2
Number for the log level verbosity.
Default: 0
Comma-separated list of pattern=N settings for file-filtered logging.
Default: empty
WORK IN PROGRESS.
See the sample configuration file for a full example configuration.
The core section contains common configuration settings that are not specific to any particular feature source.
core.sleepInterval specifies the interval between consecutive passes of feature (re-)detection, and thus also the interval between node re-labeling. A non-positive value implies infinite sleep interval, i.e. no re-detection or re-labeling is done.
Note: Overridden by the deprecated --sleep-interval command line flag (if specified).
Default: 60s
Example:
core:
+ sleepInterval: 60s
+core.sources specifies the list of enabled feature sources. A special value all enables all feature sources.
Note: Overridden by the deprecated --sources command line flag (if specified).
Default: [all]
Example:
core:
+ sources:
+ - system
+ - custom
+core.labelWhiteList specifies a regular expression for filtering feature labels based on the label name. Non-matching labels are not published.
Note: The regular expression is only matches against the "basename" part of the label, i.e. to the part of the name after ‘/'. The label prefix (or namespace) is omitted.
Note: Overridden by the deprecated --label-whitelist command line flag (if specified).
Default: null
Example:
core:
+ labelWhiteList: '^cpu-cpuid'
+Setting core.noPublish to true disables all communication with the nfd-master. It is effectively a "dry-run" flag: nfd-worker runs feature detection normally, but no labeling requests are sent to nfd-master.
Note: Overridden by the --no-publish command line flag (if specified).
Default: false
Example:
core:
+ noPublish: true
+The following options specify the logger configuration. Most of which can be dynamically adjusted at run-time.
Note: The logger options can also be specified via command line flags which take precedence over any corresponding config file options.
If true, adds the file directory to the header of the log messages.
Default: false
Run-time configurable: yes
Log to standard error as well as files.
Default: false
Run-time configurable: yes
When logging hits line file:N, emit a stack trace.
Default: empty
Run-time configurable: yes
If non-empty, write log files in this directory.
Default: empty
Run-time configurable: no
If non-empty, use this log file.
Default: empty
Run-time configurable: no
Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited.
Default: 1800
Run-time configurable: no
Log to standard error instead of files
Default: true
Run-time configurable: yes
If true, avoid header prefixes in the log messages.
Default: false
Run-time configurable: yes
If true, avoid headers when opening log files.
Default: false
Run-time configurable: no
Logs at or above this threshold go to stderr (default 2)
Run-time configurable: yes
Number for the log level verbosity.
Default: 0
Run-time configurable: yes
Comma-separated list of pattern=N settings for file-filtered logging.
Default: empty
Run-time configurable: yes
The sources section contains feature source specific configuration parameters.
Prevent publishing cpuid features listed in this option.
Note: overridden by sources.cpu.cpuid.attributeWhitelist (if specified)
Default: [BMI1, BMI2, CLMUL, CMOV, CX16, ERMS, F16C, HTT, LZCNT, MMX, MMXEXT, NX, POPCNT, RDRAND, RDSEED, RDTSCP, SGX, SGXLC, SSE, SSE2, SSE3, SSE4.1, SSE4.2, SSSE3]
Example:
sources:
+ cpu:
+ cpuid:
+ attributeBlacklist: [MMX, MMXEXT]
+Only publish the cpuid features listed in this option.
Note: takes precedence over sources.cpu.cpuid.attributeBlacklist
Default: empty
Example:
sources:
+ cpu:
+ cpuid:
+ attributeWhitelist: [AVX512BW, AVX512CD, AVX512DQ, AVX512F, AVX512VL]
+Path of the kernel config file. If empty, NFD runs a search in the well-known standard locations.
Default: empty
Example:
sources:
+ kernel:
+ kconfigFile: "/path/to/kconfig"
+Kernel configuration options to publish as feature labels.
Default: [NO_HZ, NO_HZ_IDLE, NO_HZ_FULL, PREEMPT]
Example:
sources:
+ kernel:
+ configOpts: [NO_HZ, X86, DMI]
+List of PCI device class IDs for which to publish a label. Can be specified as a main class only (e.g. 03) or full class-subclass combination (e.g. 0300) - the former implies that all subclasses are accepted. The format of the labels can be further configured with deviceLabelFields.
Default: ["03", "0b40", "12"]
Example:
sources:
+ pci:
+ deviceClassWhitelist: ["0200", "03"]
+The set of PCI ID fields to use when constructing the name of the feature label. Valid fields are class, vendor, device, subsystem_vendor and subsystem_device.
Default: [class, vendor]
Example:
sources:
+ pci:
+ deviceLabelFields: [class, vendor, device]
+With the example config above NFD would publish labels like: feature.node.kubernetes.io/pci-<class-id>_<vendor-id>_<device-id>.present=true
List of USB device class IDs for which to publish a feature label. The format of the labels can be further configured with deviceLabelFields.
Default: ["0e", "ef", "fe", "ff"]
Example:
sources:
+ usb:
+ deviceClassWhitelist: ["ef", "ff"]
+The set of USB ID fields from which to compose the name of the feature label. Valid fields are class, vendor, device and serial.
Default: [class, vendor, device]
Example:
sources:
+ pci:
+ deviceLabelFields: [class, vendor]
+With the example config above NFD would publish labels like: feature.node.kubernetes.io/usb-<class-id>_<vendor-id>.present=true
List of rules to process in the custom feature source to create user-specific labels. Refer to the documentation of the custom feature source for details of the available rules and their configuration.
Default: empty
Example:
source:
+ custom:
+ - name: "my.custom.feature"
+ matchOn:
+ - loadedKMod: ["e1000e"]
+ - pciId:
+ class: ["0200"]
+ vendor: ["8086"]
+