404
Not Found
Not Found
NFD provides multiple extension points for vendor and application specific labeling:
NodeFeatureRule objects provide a way to deploy custom labeling rules via the Kubernetes APIlocal feature source of nfd-worker creates labels by executing hooks and reading filescustom feature source of nfd-worker creates labels based on user-specified rulesNodeFeatureRule objects provide an easy way to create vendor or application specific labels. It uses a flexible rule-based mechanism for creating labels based on node feature.
Consider the following referential example:
apiVersion: nfd.k8s-sigs.io/v1alpha1
+kind: NodeFeatureRule
+metadata:
+ name: my-sample-rule-object
+spec:
+ rules:
+ - name: "my sample rule"
+ labels:
+ "my-sample-feature": "true"
+ matchFeatures:
+ - feature: kernel.loadedmodule
+ matchExpressions:
+ dummy: {op: Exists}
+ - feature: kernel.config
+ matchExpressions:
+ X86: {op: In, value: ["y"]}
+It specifies one rule which creates node label feature.node.kubenernetes.io/my-sample-feature=true if both of the following conditions are true (matchFeatures implements a logical AND over the matchers):
dummy network driver module has been loaded=yCreate a NodeFeatureRule with a yaml file:
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/node-feature-discovery/v0.11.0/examples/nodefeaturerule.yaml
+Now, on X86 platforms the feature label appears after doing modprobe dummy on a system and correspondingly the label is removed after rmmod dummy. Note a re-labeling delay up to the sleep-interval of nfd-worker (1 minute by default).
NFD-Master acts as the controller for NodeFeatureRule objects. It applies these rules on raw feature data received from nfd-worker instances and creates node labels, accordingly.
NOTE nfd-master is stateless and (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 configuration option (or -sleep-interval command line flag) 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.
NFD-Worker has a special feature source named local which is an integration point for external feature detectors. It provides a mechanism for pluggable extensions, allowing the creation of new user-specific features and even overriding built-in labels.
The local feature source has two methods for detecting features, hooks and feature files. The features discovered by the local source can further be used in label rules specified in NodeFeatureRule objects and the custom feature source.
NOTE: Be careful when creating and/or updating hook or feature files while NFD is running. In order to avoid race conditions you should write into a temporary file (outside the source.d and features.d directories), and, atomically create/update the original file by doing a filesystem move operation.
Consider a shell script /etc/kubernetes/node-feature-discovery/source.d/my-hook.sh having the following stdout output, or alternatively, a plaintext file /etc/kubernetes/node-feature-discovery/features.d/my-features having the following contents:
my-feature.1
+my-feature.2=myvalue
+my.namespace/my-feature.3=456
+This will translate into the following node labels:
feature.node.kubernetes.io/my-feature.1: "true"
+feature.node.kubernetes.io/my-feature.2: "myvalue"
+my.namespace/my-feature.3: "456"
+Note that in the example above -extra-label-ns=my.namespace must be specified on the nfd-master command line.
The local source executes hooks found in /etc/kubernetes/node-feature-discovery/source.d/. The hook files must be executable and they are supposed to print all discovered features in stdout. 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 image are bash and perl.
stderr output of hooks is propagated to NFD log so it can be used for debugging and logging.
NFD tries to execute any regular files found from the hooks directory. Any additional data files the hook might need (e.g. a configuration file) should be placed in a separate directory in order to avoid NFD unnecessarily trying to execute them. A subdirectory under the hooks directory can be used, for example /etc/kubernetes/node-feature-discovery/source.d/conf/.
NOTE: NFD will blindly run any executables placed/mounted in the hooks directory. It is the user's responsibility to review the hooks for e.g. possible security implications.
NOTE: The minimal image variant only supports running statically linked binaries.
The local source reads files found in /etc/kubernetes/node-feature-discovery/features.d/.
The hook stdout and feature files are expected to contain features in simple key-value pairs, separated by newlines:
<name>[=<value>]
+The label value defaults to true, if not specified.
Label namespace may be specified with <namespace>/<name>[=<value>]. The namespace must be explicitly allowed with the -extra-label-ns command line flag of nfd-master if using something else than [<sub-ns>.]feature.node.kubernetes.io or [<sub-ns>.]profile.node.kubernetes.io.
The standard NFD deployments contain hostPath mounts for /etc/kubernetes/node-feature-discovery/source.d/ and /etc/kubernetes/node-feature-discovery/features.d/, making these directories from the host available inside the nfd-worker container.
One use case for the hooks and/or feature files is detecting features in other Pods outside NFD, e.g. in Kubernetes device plugins. By using the same hostPath mounts for /etc/kubernetes/node-feature-discovery/source.d/ and /etc/kubernetes/node-feature-discovery/features.d/ in the side-car (e.g. device plugin) creates a shared area for deploying hooks and feature files to NFD. NFD will periodically scan the directories and run any hooks and read any feature files it finds.
The custom feature source in nfd-worker provides a rule-based mechanism for label creation, similar to the NodeFeatureRule objects. The difference is that the rules are specified in the worker configuration instead of a Kubernetes API object.
See worker configuration for instructions how to set-up and manage the worker configuration.
Consider the following referential configuration for nfd-worker:
core:
+ labelSources: ["custom"]
+sources:
+ custom:
+ - name: "my sample rule"
+ labels:
+ "my-sample-feature": "true"
+ matchFeatures:
+ - feature: kernel.loadedmodule
+ matchExpressions:
+ dummy: {op: Exists}
+ - feature: kernel.config
+ matchExpressions:
+ X86: {op: In, value: ["y"]}
+It specifies one rule which creates node label feature.node.kubenernetes.io/my-sample-feature=true if both of the following conditions are true (matchFeatures implements a logical AND over the matchers):
dummy network driver module has been loaded=yIn addition, the configuration only enables the custom source, disabling all built-in labels.
Now, on X86 platforms the feature label appears after doing modprobe dummy on a system and correspondingly the label is removed after rmmod dummy. Note a re-labeling delay up to the sleep-interval of nfd-worker (1 minute by default).
In addition to the rules defined in the nfd-worker configuration file, the custom feature source can read more configuration files located in the /etc/kubernetes/node-feature-discovery/custom.d/ directory. This makes more dynamic and flexible configuration easier.
As an example, consider having file /etc/kubernetes/node-feature-discovery/custom.d/my-rule.yaml with the following content:
- name: "my e1000 rule"
+ labels:
+ "e1000.present": "true"
+ matchFeatures:
+ - feature: kernel.loadedmodule
+ matchExpressions:
+ e1000: {op: Exists}
+This simple rule will create feature.node.kubenernetes.io/e1000.present=true label if the e1000 kernel module has been loaded.
The samples/custom-rules kustomize overlay sample contains an example for deploying a custom rule from a ConfigMap.
Feature labels have the following format:
<namespace>/<name> = <value>
+The namespace part (i.e. prefix) of the labels is controlled by nfd:
feature.node.kubernetes.io. This is also the default for user defined features that don't specify any namespace.feature.node.kubernetes.io and profile.node.kubernetes.io plus their sub-namespaces (e.g. vendor.profile.node.kubernetes.io and sub.ns.profile.node.kubernetes.io) by default-extra-label-ns command line flag of nfd-masterThis section describes the rule format used in NodeFeatureRule objects and in the configuration of the custom feature source.
It is based on a generic feature matcher that covers all features discovered by nfd-worker. The rules rely on a unified data model of the available features and a generic expression-based format. Features that can be used in the rules are described in detail in available features below.
Take this rule as a referential example:
- name: "my feature rule"
+ labels:
+ "my-special-feature": "my-value"
+ matchFeatures:
+ - feature: cpu.cpuid
+ matchExpressions:
+ AVX512F: {op: Exists}
+ - feature: kernel.version
+ matchExpressions:
+ major: {op: In, value: ["5"]}
+ minor: {op: Gt, value: ["1"]}
+ - feature: pci.device
+ matchExpressions:
+ vendor: {op: In, value: ["8086"]}
+ class: {op: In, value: ["0200"]}
+This will yield feature.node.kubenernetes.io/my-special-feature=my-value node label if all of these are true (matchFeatures implements a logical AND over the matchers):
The .name field is required and used as an identifier of the rule.
The .labels is a map of the node labels to create if the rule matches.
The .labelsTemplate field specifies a text template for dynamically creating labels based on the matched features. See templating for details.
NOTE The labels field has priority over labelsTemplate, i.e. labels specified in the labels field will override anything originating from labelsTemplate.
The .vars field is a map of values (key-value pairs) to store for subsequent rules to use. In other words, these are variables that are not advertised as node labels. See backreferences for more details on the usage of vars.
The .varsTemplate field specifies a text template for dynamically creating vars based on the matched features. See templating for details on using templates and backreferences for more details on the usage of vars.
NOTE The vars field has priority over varsTemplate, i.e. vars specified in the vars field will override anything originating from varsTemplate.
The .matchFeatures field specifies a feature matcher, consisting of a list of feature matcher terms. It implements a logical AND over the terms i.e. all of them must match in order for the rule to trigger.
matchFeatures:
+ - feature: <feature-name>
+ matchExpressions:
+ <key>:
+ op: <op>
+ value:
+ - <value-1>
+ - ...
+The .matchFeatures[].feature field specifies the feature against which to match.
The .matchFeatures[].matchExpressions field specifies a map of expressions which to evaluate against the elements of the feature.
In each MatchExpression op specifies the operator to apply. Valid values are described below.
| Operator | Number of values | Matches when |
|---|---|---|
In | 1 or greater | Input is equal to one of the values |
NotIn | 1 or greater | Input is not equal to any of the values |
InRegexp | 1 or greater | Values of the MatchExpression are treated as regexps and input matches one or more of them |
Exists | 0 | The key exists |
DoesNotExist | 0 | The key does not exists |
Gt | 1 | Input is greater than the value. Both the input and value must be integer numbers. |
Lt | 1 | Input is less than the value. Both the input and value must be integer numbers. |
GtLt | 2 | Input is between two values. Both the input and value must be integer numbers. |
IsTrue | 0 | Input is equal to "true" |
IsFalse | 0 | Input is equal "false" |
The value field of MatchExpression is a list of string arguments to the operator.
The behavior of MatchExpression depends on the feature type: for flag and attribute features the MatchExpression operates on the feature element whose name matches the <key>. However, for instance features all MatchExpressions are evaluated against the attributes of each instance separately.
The .matchAny field is a list of of matchFeatures matchers. A logical OR is applied over the matchers, i.e. at least one of them must match in order for the rule to trigger.
Consider the following example:
matchAny:
+ - matchFeatures:
+ - feature: kernel.loadedmodule
+ matchExpressions:
+ kmod-1: {op: Exists}
+ - feature: pci.device
+ matchExpressions:
+ vendor: {op: In, value: ["0eee"]}
+ class: {op: In, value: ["0200"]}
+ - matchFeatures:
+ - feature: kernel.loadedmodule
+ matchExpressions:
+ kmod-2: {op: Exists}
+ - feature: pci.device
+ matchExpressions:
+ vendor: {op: In, value: ["0fff"]}
+ class: {op: In, value: ["0200"]}
+This matches if kernel module kmod-1 is loaded and a network controller from vendor 0eee is present, OR, if kernel module kmod-2 has been loaded and a network controller from vendor 0fff is present (OR both of these conditions are true).
Features are divided into three different types:
The following features are available for matching:
| Feature | Feature type | Elements | Value type | Description |
|---|---|---|---|---|
cpu.cpuid | flag | Supported CPU capabilities | ||
<cpuid-flag> | CPUID flag is present | |||
cpu.cstate | attribute | Status of cstates in the intel_idle cpuidle driver | ||
enabled | bool | ‘true' if cstates are set, otherwise ‘false'. Does not exist of intel_idle driver is not active. | ||
cpu.model | attribute | CPU model related attributes | ||
family | int | CPU family | ||
vendor_id | string | CPU vendor ID | ||
id | int | CPU model ID | ||
cpu.pstate | attribute | State of the Intel pstate driver. Does not exist if the driver is not enabled. | ||
status | string | Status of the driver, possible values are ‘active' and ‘passive' | ||
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 for details | |||
cpu.sgx | attribute | Intel SGX (Software Guard Extensions) capabilities | ||
enabled | bool | true if Intel SGX has been enabled, otherwise does not exist | ||
cpu.sst | attribute | Intel SST (Speed Select Technology) capabilities | ||
bf.enabled | bool | true if Intel SST-BF (Intel Speed Select Technology - Base frequency) has been enabled, otherwise does not exist | ||
cpu.se | attribute | IBM Secure Execution for Linux (IBM Z & LinuxONE) | ||
enabled | bool | true if IBM Secure Execution for Linux is available and has been enabled, otherwise does not exist | ||
cpu.topology | attribute | CPU topology related features | ||
hardware_multithreading | bool | Hardware multithreading, such as Intel HTT, is enabled | ||
kernel.config | attribute | Kernel configuration options | ||
<config-flag> | string | Value of the kconfig option | ||
kernel.loadedmodule | flag | Loaded kernel modules | ||
mod-name | Kernel module <mod-name> is loaded | |||
kernel.selinux | attribute | Kernel SELinux related features | ||
enabled | bool | true if SELinux has been enabled and is in enforcing mode, otherwise false | ||
kernel.version | attribute | Kernel version information | ||
full | string | Full kernel version (e.g. ‘4.5.6-7-g123abcde') | ||
major | int | First component of the kernel version (e.g. ‘4') | ||
minor | int | Second component of the kernel version (e.g. ‘5') | ||
revision | int | Third component of the kernel version (e.g. ‘6') | ||
local.label | attribute | Features from hooks and feature files, i.e. labels from the local feature source | ||
<label-name> | string | Label <label-name> created by the local feature source, value equals the value of the label | ||
memory.nv | instance | NVDIMM devices present in the system | ||
<sysfs-attribute> | string | Value of the sysfs device attribute, available attributes: devtype, mode | ||
memory.numa | attribute | NUMA nodes | ||
is_numa | bool | true if NUMA architecture, false otherwise | ||
node_count | int | Number of NUMA nodes | ||
network.device | instance | Physical (non-virtual) network interfaces present in the system | ||
name | string | Name of the network interface | ||
<sysfs-attribute> | string | Sysfs network interface attribute, available attributes: operstate, speed, sriov_numvfs, sriov_totalvfs | ||
pci.device | instance | PCI devices present in the system | ||
<sysfs-attribute> | string | Value of the sysfs device attribute, available attributes: class, vendor, device, subsystem_vendor, subsystem_device, sriov_totalvfs, iommu_group/type, iommu/intel-iommu/version | ||
storage.device | instance | Block storage devices present in the system | ||
name | string | Name of the block device | ||
<sysfs-attribute> | string | Sysfs network interface attribute, available attributes: dax, rotational, nr_zones, zoned | ||
system.osrelease | attribute | System identification data from /etc/os-release | ||
<parameter> | string | One parameter from /etc/os-release | ||
system.name | attribute | System name information | ||
nodename | string | Name of the kubernetes node object | ||
usb.device | instance | USB devices present in the system | ||
<sysfs-attribute> | string | Value of the sysfs device attribute, available attributes: class, vendor, device, serial | ||
rule.matched | attribute | Previously matched rules | ||
<label-or-var> | string | Label or var from a preceding rule that matched |
Rules support template-based creation of labels and vars with the .labelsTemplate and .varsTemplate fields. These makes it possible to dynamically generate labels and vars based on the features that matched.
The template must expand into a simple format with <key>=<value> pairs separated by newline.
Consider the following example:
labelsTemplate: |
+ {{ range .pci.device }}vendor-{{ .class }}-{{ .device }}.present=true
+ {{ end }}
+ matchFeatures:
+ - feature: pci.device
+ matchExpressions:
+ class: {op: InRegexp, value: ["^02"]}
+ vendor: ["0fff"]
+The rule above will create individual labels feature.node.kubernetes.io/vendor-<class-id>-<device-id>.present=true for each network controller device (device class starting with 02) from vendor 0ffff.
All the matched features of each feature matcher term under matchFeatures fields are available for the template engine. Matched features can be referenced with {{ .<feature-name> }} in the template, and the available data could be described in yaml as follows:
.
+ <key-feature>:
+ - Name: <matched-key>
+ - ...
+
+ <value-feature>:
+ - Name: <matched-key>
+ Value: <matched-value>
+ - ...
+
+ <instance-feature>:
+ - <attribute-1-name>: <attribute-1-value>
+ <attribute-2-name>: <attribute-2-value>
+ ...
+ - ...
+That is, the per-feature data is a list of objects whose data fields depend on the type of the feature:
A simple example of a template utilizing name and value from an attribute feature:
labelsTemplate: |
+ {{ range .system.osrelease }}system-{{ .Name }}={{ .Value }}
+ {{ end }}
+ matchFeatures:
+ - feature: system.osRelease
+ matchExpressions:
+ ID: {op: Exists}
+ VERSION_ID.major: {op: Exists}
+NOTE In case of matchAny is specified, the template is executed separately against each individual matchFeatures field and the final set of labels will be superset of all these separate template expansions. E.g. consider the following:
- name: <name>
+ labelsTemplate: <template>
+ matchFeatures: <matcher#1>
+ matchAny:
+ - matchFeatures: <matcher#2>
+ - matchFeatures: <matcher#3>
+In the example above (assuming the overall result is a match) the template would be executed on matcher#1 as well as on matcher#2 and/or matcher#3 (depending on whether both or only one of them match). All the labels from these separate expansions would be created, i.e. the end result would be a union of all the individual expansions.
Rule templates use the Golang text/template package and all its built-in functionality (e.g. pipelines and functions) can be used. An example template taking use of the built-in len function, advertising the number of PCI network controllers from a specific vendor:
labelsTemplate: |
+ num-intel-network-controllers={{ .pci.device | len }}
+ matchFeatures:
+ - feature: pci.device
+ matchExpressions:
+ vendor: {op: In, value: ["8086"]}
+ class: {op: In, value: ["0200"]}
+
+Imaginative template pipelines are possible, but care must be taken in order to produce understandable and maintainable rule sets.
Rules support referencing the output of preceding rules. This enables sophisticated scenarios where multiple rules are combined together to for more complex heuristics than a single rule can provide. The labels and vars created by the execution of preceding rules are available as a special rule.matched feature.
Consider the following configuration:
- name: "my kernel label rule"
+ labels:
+ kernel-feature: "true"
+ matchFeatures:
+ - feature: kernel.version
+ matchExpressions:
+ major: {op: Gt, value: ["4"]}
+
+ - name: "my var rule"
+ vars:
+ nolabel-feature: "true"
+ matchFeatures:
+ - feature: cpu.cpuid
+ matchExpressions:
+ AVX512F: {op: Exists}
+ - feature: pci.device
+ matchExpressions:
+ vendor: {op: In, value: ["0fff"]}
+ device: {op: In, value: ["1234", "1235"]}
+
+ - name: "my high level feature rule"
+ labels:
+ high-level-feature: "true"
+ matchFeatures:
+ - feature: rule.matched
+ matchExpressions:
+ kernel-feature: {op: IsTrue}
+ nolabel-feature: {op: IsTrue}
+The feature.node.kubernetes.io/high-level-feature = true label depends on thw two previous rules.
Note that when referencing rules across multiple NodeFeatureRule objects attention must be paid to the ordering. NodeFeatureRule objects are processed in alphabetical order (based on their .metadata.name).
Some more configuration examples below.
Match certain CPUID features:
- name: "example cpuid rule"
+ labels:
+ my-special-cpu-feature: "true"
+ matchFeatures:
+ - feature: cpu.cpuid
+ matchExpressions:
+ AESNI: {op: Exists}
+ AVX: {op: Exists}
+Require a certain loaded kernel module and OS version:
- name: "my multi-feature rule"
+ labels:
+ my-special-multi-feature: "true"
+ matchFeatures:
+ - feature: kernel.loadedmodule
+ matchExpressions:
+ e1000: {op: Exists}
+ - feature: system.osrelease
+ matchExpressions:
+ NAME: {op: InRegexp, values: ["^openSUSE"]}
+ VERSION_ID.major: {op: Gt, values: ["14"]}
+Require a loaded kernel module and two specific PCI devices (both of which must be present):
- name: "my multi-device rule"
+ labels:
+ my-multi-device-feature: "true"
+ matchFeatures:
+ - feature: kernel.loadedmodule
+ matchExpressions:
+ my-driver-module: {op: Exists}
+ - pci.device:
+ vendor: "0fff"
+ device: "1234"
+ - pci.device:
+ vendor: "0fff"
+ device: "abcd"
+DEPRECATED: use the new rule syntax instead.
The custom source supports the legacy matchOn rule syntax for backwards-compatibility.
To aid in making the legacy rule syntax clearer, we define a general and a per rule nomenclature, keeping things as consistent as possible.
Rule :Represents a matching logic that is used to match on a feature.
+Rule Input :The input a Rule is provided. This determines how a Rule performs the match operation.
+Matcher :A composition of Rules, each Matcher may be composed of at most one instance of each Rule.
+Rules are specified under sources.custom in the nfd-worker configuration file.
sources:
+ custom:
+ - name: <feature name>
+ value: <optional feature value, defaults to "true">
+ matchOn:
+ - <Rule-1>: <Rule-1 Input>
+ [<Rule-2>: <Rule-2 Input>]
+ - <Matcher-2>
+ - ...
+ - ...
+ - <Matcher-N>
+ - <custom feature 2>
+ - ...
+ - ...
+ - <custom feature M>
+The label is constructed by adding custom- prefix to the name field, label value defaults to true if not specified in the rule spec:
feature.node.kubernetes.io/custom-<name> = <value>
+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.
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.
pciId :
+ class: [<class id>, ...]
+ vendor: [<vendor id>, ...]
+ 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.
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, device and serial. A list of Elements is provided for each Attribute.
usbId :
+ class: [<class id>, ...]
+ vendor: [<vendor id>, ...]
+ device: [<device id>, ...]
+ serial: [<serial>, ...]
+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.
Element :A kernel module
+The LoadedKMod Rule allows matching the loaded kernel modules in the system against a provided list of Elements.
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.
Element :A CPUID flag
+The Rule allows matching the available CPUID flags in the system against a provided list of Elements.
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.
Element :A Kconfig option
+The Rule allows matching the kconfig options in the system against a provided list of Elements.
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.
Element :A nodename regexp pattern
+The Rule allows matching the node's name against a provided list of Elements.
nodename: [ <nodename regexp pattern>, ... ]
+Matching is done by performing logical OR for each provided Element, i.e the Rule will match if one of the provided Elements (nodename regexp pattern) matches the node's name.
custom:
+ - name: "my.kernel.feature"
+ matchOn:
+ - loadedKMod: ["kmod1", "kmod2"]
+ - name: "my.pci.feature"
+ matchOn:
+ - pciId:
+ vendor: ["15b3"]
+ device: ["1014", "1017"]
+ - name: "my.usb.feature"
+ matchOn:
+ - usbId:
+ vendor: ["1d6b"]
+ device: ["0003"]
+ serial: ["090129a"]
+ - name: "my.combined.feature"
+ matchOn:
+ - loadedKMod : ["vendor_kmod1", "vendor_kmod2"]
+ pciId:
+ vendor: ["15b3"]
+ device: ["1014", "1017"]
+ - name: "vendor.feature.node.kubernetes.io/accumulated.feature"
+ matchOn:
+ - loadedKMod : ["some_kmod1", "some_kmod2"]
+ - pciId:
+ vendor: ["15b3"]
+ device: ["1014", "1017"]
+ - name: "my.kernel.featureneedscpu"
+ matchOn:
+ - kConfig: ["KVM_INTEL"]
+ - cpuId: ["VMX"]
+ - name: "my.kernel.modulecompiler"
+ matchOn:
+ - kConfig: ["GCC_VERSION=100101"]
+ loadedKMod: ["kmod1"]
+ - name: "profile.node.kubernetes.io/my-datacenter"
+ value: "datacenter-1"
+ matchOn:
+ - nodename: [ "node-datacenter1-rack.*-server.*" ]
+In the example above:
feature.node.kubernetes.io/custom-my.kernel.feature=true if the node has kmod1 AND kmod2 kernel modules loaded.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.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.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.vendor.feature.node.kubernetes.io/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.feature.node.kubernetes.io/custom-my.kernel.featureneedscpu=true if KVM_INTEL kernel config is enabled AND the node CPU supports VMX virtual machine extensionsfeature.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.profile.node.kubernetes.io/my-datacenter=datacenter-1 if the node's name matches the node-datacenter1-rack.*-server.* pattern, e.g. node-datacenter1-rack2-server42git 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>
+The default set of architectures enabled for mulit-arch builds are linux/amd64 and linux/arm64. If more architectures are needed one can override the IMAGE_ALL_PLATFORMS variable with a comma separated list of OS/ARCH tuples.
make image-all
+Currently docker does not support loading of manifest-lists meaning the images are not shown when executing docker images, see: buildx issue #59.
make push-all
+The resulting container image can be used in the same way on each arch by pulling e.g. node-feature-discovery:v0.11.0 without specifying the architecture. The manifest-list will take care of providing the right architecture image.
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_BUILDX_CMD | Command to build and push multi-arch images with buildx | DOCKER_CLI_EXPERIMENTAL=enabled docker buildx build –platform=${IMAGE_ALL_PLATFORMS} –progress=auto –pull |
| IMAGE_ALL_PLATFORMS | Comma seperated list of OS/ARCH tuples for mulit-arch builds | linux/amd64,linux/arm64 |
| 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 | node-feature-discovery |
| 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.11.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
+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.
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.
In order to run nfd-topology-updater 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-topology-updater
+2019/02/01 14:48:56 Node Feature Discovery Topology Updater <NFD_VERSION>
+...
+If you just want to try out feature discovery without connecting to nfd-master, pass the -no-publish flag to nfd-topology-updater.
NOTE:
NFD topology updater needs 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 template spec for up-to-date information about the required volume mounts.
PodResource API is a prerequisite for nfd-topology-updater. Preceding Kubernetes v1.23, the kubelet must be started with the following flag: --feature-gates=KubeletPodResourcesGetAllocatable=true. Starting Kubernetes v1.23, the GetAllocatableResources is enabled by default through KubeletPodResourcesGetAllocatable feature gate.
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.11.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 updates to the Node objects in the Kubernetes API server, making a "dry-run" flag for nfd-master. No Labels, Annotations or ExtendedResources of nodes are updated.
Default: false
Example:
nfd-master -no-publish
+The -featurerules-controller flag controlers the processing of NodeFeatureRule objects, effectively enabling/disabling labels from these custom labeling rules.
Default: true
Example:
nfd-master -featurerules-controller=false
+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 and profile.node.kubernetes.io label namespaces and their sub-namespaces (e.g. vendor.feature.node.kubernetes.io and sub.ns.profile.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-topology-updater -help. In a docker container:
docker run gcr.io/k8s-staging-nfd/node-feature-discovery:master nfd-topology-updater -help
+Print usage and exit.
Print version and exit.
The -server flag specifies the address of the nfd-master endpoint where to connect to.
Default: localhost:8080
Example:
nfd-topology-updater -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 topology-updater 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-topology-updater -ca-file=/opt/nfd/ca.crt -cert-file=/opt/nfd/updater.crt -key-file=/opt/nfd/updater.key
+The -cert-file is one of the three flags (together with -ca-file and -key-file) controlling mutual TLS authentication on the topology-updater 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-topology-updater -cert-file=/opt/nfd/updater.crt -key-file=/opt/nfd/updater.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 topology-updater 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-topology-updater -key-file=/opt/nfd/updater.key -cert-file=/opt/nfd/updater.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-topology-updater -server-name-override=localhost
+The -no-publish flag disables all communication with the nfd-master, making it a "dry-run" flag for nfd-topology-updater. NFD-Topology-Updater runs resource hardware topology detection normally, but no CR requests are sent to nfd-master.
Default: false
Example:
nfd-topology-updater -no-publish
+The -oneshot flag causes nfd-topology-updater to exit after one pass of resource hardware topology detection.
Default: false
Example:
nfd-topology-updater -oneshot -no-publish
+The -sleep-interval specifies the interval between resource hardware topology re-examination (and CR updates). A non-positive value implies infinite sleep interval, i.e. no re-detection is done.
Default: 60s
Example:
nfd-topology-updater -sleep-interval=1h
+The -watch-namespace specifies the namespace to ensure that resource hardware topology examination only happens for the pods running in the specified namespace. Pods that are not running in the specified namespace are not considered during resource accounting. This is particularly useful for testing/debugging purpose. A "*" value would mean that all the pods would be considered during the accounting process.
Default: "*"
Example:
nfd-topology-updater -watch-namespace=rte
+The -kubelet-config-file specifies the path to the Kubelet's configuration file.
Default: /host-var/lib/kubelet/config.yaml
Example:
nfd-topology-updater -kubelet-config-file=/var/lib/kubelet/config.yaml
+The -podresources-socket specifies the path to the Unix socket where kubelet exports a gRPC service to enable discovery of in-use CPUs and devices, and to provide metadata for them.
Default: /host-var/lib/kubelet/pod-resources/kubelet.sock
Example:
nfd-topology-updater -podresources-socket=/var/lib/kubelet/pod-resources/kubelet.sock
+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.11.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 -feature-sources flag specifies a comma-separated list of enabled feature sources. A special value all enables all sources. Prefixing a source name with - indicates that the source will be disabled instead - this is only meaningful when used in conjunction with all. This command line flag allows completely disabling the feature detection so that neither standard feature labels are generated nor the raw feature data is available for custom rule processing. Consider using the core.featureSources config file option, instead, allowing dynamic configurability.
Note: This flag takes precedence over the core.featureSources configuration file option.
Default: all
Example:
nfd-worker -feature-sources=all,-pci
+The -label-sources flag specifies a comma-separated list of enabled label sources. A special value all enables all sources. Prefixing a source name with - indicates that the source will be disabled instead - this is only meaningful when used in conjunction with all. Consider using the core.labelSources config file option, instead, allowing dynamic configurability.
Note: This flag takes precedence over the core.labelSources configuration file option.
Default: all
Example:
nfd-worker -label-sources=kernel,system,local
+DEPRECATED: use -label-sources 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
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.featureSources specifies the list of enabled feature sources. A special value all enables all sources. Prefixing a source name with - indicates that the source will be disabled instead - this is only meaningful when used in conjunction with all. This option allows completely disabling the feature detection so that neither standard feature labels are generated nor the raw feature data is available for custom rule processing.
Default: [all]
Example:
core:
+ # Enable all but cpu and local sources
+ featureSources:
+ - "all"
+ - "-cpu"
+ - "-local"
+core:
+ # Enable only cpu and local sources
+ featureSources:
+ - "cpu"
+ - "local"
+core.labelSources specifies the list of enabled label sources. A special value all enables all sources. Prefixing a source name with - indicates that the source will be disabled instead - this is only meaningful when used in conjunction with all. This configuration option affects the generation of node labels but not the actual discovery of the underlying feature data that is used e.g. in custom/NodeFeatureRule rules.
Note: Overridden by the -label-sources and -sources command line flags and the core.sources configurations option (if any of them is specified).
Default: [all]
Example:
core:
+ # Enable all but cpu and system sources
+ labelSources:
+ - "all"
+ - "-cpu"
+ - "-system"
+core:
+ # Enable only cpu and system sources
+ labelSources:
+ - "cpu"
+ - "system"
+DEPRECATED: use core.labelSources instead.
Note: core.sources takes precedence over the core.labelSources configuration file option.
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:
sources:
+ custom:
+ - name: "my custom rule"
+ labels:
+ my-custom-feature: "true"
+ matchFeatures:
+ - feature: kernel.loadedmodule
+ matchExpressions:
+ e1000e: {op: Exists}
+ - feature: pci.device
+ matchExpressions:
+ class: {op: In, value: ["0200"]}
+ vendor: {op: In, value: ["8086"]}
+