404
Not Found
Not Found
Not Found
You can reach us via the following channels:
This is a SIG-node subproject, hosted under the Kubernetes SIGs organization in Github. The project was established in 2016 and was migrated to Kubernetes SIGs in 2018.
This is open source software released under the Apache 2.0 License.
You can reach us via the following channels:
This is a SIG-node subproject, hosted under the Kubernetes SIGs organization in Github. The project was established in 2016 and was migrated to Kubernetes SIGs in 2018.
This is open source software released under the Apache 2.0 License.
Node Feature Discovery Helm chart allow to easily deploy and manage NFD.
NOTE: NFD is not ideal for other Helm charts to depend on as that may result in multiple parallel NFD deployments in the same cluster which is not fully supported by the NFD Helm chart.
Helm package manager should be installed.
To install the latest stable version:
export NFD_NS=node-feature-discovery
+ Helm · Node Feature Discovery
Deployment with Helm
Table of contents
Node Feature Discovery Helm chart allow to easily deploy and manage NFD.
NOTE: NFD is not ideal for other Helm charts to depend on as that may result in multiple parallel NFD deployments in the same cluster which is not fully supported by the NFD Helm chart.
Prerequisites
Helm package manager should be installed.
Deployment
To install the latest stable version:
export NFD_NS=node-feature-discovery
helm repo add nfd https://kubernetes-sigs.github.io/node-feature-discovery/charts
helm repo update
helm install nfd/node-feature-discovery --namespace $NFD_NS --create-namespace --generate-name
diff --git a/v0.14/deployment/image-variants.html b/v0.14/deployment/image-variants.html
index 8debbfb8ed..d9265bf7ed 100644
--- a/v0.14/deployment/image-variants.html
+++ b/v0.14/deployment/image-variants.html
@@ -1 +1 @@
- Image variants · Node Feature Discovery
Image variants
NFD currently offers two variants of the container image. The "minimal" variant is currently deployed by default. Released container images are available for x86_64 and Arm64 architectures.
Minimal
This is a minimal image based on gcr.io/distroless/base and only supports running statically linked binaries.
For backwards compatibility a container image tag with suffix -minimal (e.g. registry.k8s.io/nfd/node-feature-discovery:v0.14.2-minimal) is provided.
Full
This image is based on debian:bullseye-slim and contains a full Linux system for running shell-based nfd-worker hooks and doing live debugging and diagnosis of the NFD images.
The container image tag has suffix -full (e.g. registry.k8s.io/nfd/node-feature-discovery:v0.14.2-full).
Node Feature Discovery v0.14
\ No newline at end of file
+ Image variants · Node Feature Discovery
Image variants
NFD currently offers two variants of the container image. The "minimal" variant is currently deployed by default. Released container images are available for x86_64 and Arm64 architectures.
Minimal
This is a minimal image based on gcr.io/distroless/base and only supports running statically linked binaries.
For backwards compatibility a container image tag with suffix -minimal (e.g. registry.k8s.io/nfd/node-feature-discovery:v0.14.2-minimal) is provided.
Full
This image is based on debian:bullseye-slim and contains a full Linux system for running shell-based nfd-worker hooks and doing live debugging and diagnosis of the NFD images.
The container image tag has suffix -full (e.g. registry.k8s.io/nfd/node-feature-discovery:v0.14.2-full).
Node Feature Discovery v0.14
\ No newline at end of file
diff --git a/v0.14/deployment/index.html b/v0.14/deployment/index.html
index 3a654ae239..5b3562a579 100644
--- a/v0.14/deployment/index.html
+++ b/v0.14/deployment/index.html
@@ -1 +1 @@
- Deployment · Node Feature Discovery
Deployment
Node Feature Discovery can be deployed on any recent version of Kubernetes (v1.21+).
See Image variants for description of the different NFD container images available.
Using Kustomize provides straightforward deployment with kubectl integration and declarative customization.
Using Helm provides easy management of NFD deployments with nice configuration management and easy upgrades.
Using Operator provides deployment and configuration management via CRDs.
Node Feature Discovery v0.14
\ No newline at end of file
+ Deployment · Node Feature Discovery
Deployment
Node Feature Discovery can be deployed on any recent version of Kubernetes (v1.21+).
See Image variants for description of the different NFD container images available.
Using Kustomize provides straightforward deployment with kubectl integration and declarative customization.
Using Helm provides easy management of NFD deployments with nice configuration management and easy upgrades.
Using Operator provides deployment and configuration management via CRDs.
Node Feature Discovery v0.14
\ No newline at end of file
diff --git a/v0.14/deployment/kustomize.html b/v0.14/deployment/kustomize.html
index bc63710aa9..8dd4cb7dfe 100644
--- a/v0.14/deployment/kustomize.html
+++ b/v0.14/deployment/kustomize.html
@@ -1,4 +1,4 @@
- Kustomize · Node Feature Discovery
Deployment with Kustomize
Table of contents
Kustomize provides easy deployment of NFD. Customization of the deployment is done by maintaining declarative overlays on top of the base overlays in NFD.
To follow the deployment instructions here, kubectl v1.21 or later is required.
The kustomize overlays provided in the repo can be used directly:
kubectl apply -k https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/default?ref=v0.14.2
+ Kustomize · Node Feature Discovery
Deployment with Kustomize
Table of contents
Kustomize provides easy deployment of NFD. Customization of the deployment is done by maintaining declarative overlays on top of the base overlays in NFD.
To follow the deployment instructions here, kubectl v1.21 or later is required.
The kustomize overlays provided in the repo can be used directly:
kubectl apply -k https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/default?ref=v0.14.2
This will required RBAC rules and deploy nfd-master (as a deployment) and nfd-worker (as daemonset) in the node-feature-discovery namespace.
NOTE: nfd-topology-updater is not deployed as part of the default overlay. Please refer to the Master Worker Topologyupdater and Topologyupdater below.
Alternatively you can clone the repository and customize the deployment by creating your own overlays. For example, to deploy the minimal image. See kustomize for more information about managing deployment configurations.
Overlays
The NFD repository hosts a set of overlays for different usages and deployment scenarios under deployment/overlays
default: default deployment of nfd-worker as a daemonset, described abovedefault-combined see Master-worker pod belowdefault-job: see Worker one-shot belowmaster-worker-topologyupdater: see Master Worker Topologyupdater belowtopologyupdater: see Topology Updater belowMetrics: see Metrics belowprune: clean up the cluster after uninstallation, see Removing feature labelssamples/cert-manager: an example for supplementing the default deployment with cert-manager for TLS authentication, see Automated TLS certificate management using cert-manager for detailssamples/custom-rules: an example for spicing up the default deployment with a separately managed configmap of custom labeling rules, see Custom feature source for more information about custom node labels
Master-worker pod
You can also run nfd-master and nfd-worker inside the same pod
kubectl apply -k https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/default-combined?ref=v0.14.2
This creates a DaemonSet that runs nfd-worker and nfd-master in the same Pod. In this case no nfd-master is run on the master node(s), but, the worker nodes are able to label themselves which may be desirable e.g. in single-node setups.
NOTE: nfd-topology-updater is not deployed by the default-combined overlay. To enable nfd-topology-updater in this scenario,the users must customize the deployment themselves.
Worker one-shot
Feature discovery can alternatively be configured as a one-shot job. The default-job overlay may be used to achieve this:
NUM_NODES=$(kubectl get no -o jsonpath='{.items[*].metadata.name}' | wc -w)
diff --git a/v0.14/deployment/metrics.html b/v0.14/deployment/metrics.html
index b3c4e83f81..a5cb755e53 100644
--- a/v0.14/deployment/metrics.html
+++ b/v0.14/deployment/metrics.html
@@ -1,2 +1,2 @@
- Metrics · Node Feature Discovery
Metrics
Metrics are configured to be exposed using prometheus operator API's by default. If you want to expose metrics using the prometheus operator API's you need to install the prometheus operator in your cluster. By default NFD Master and Worker expose metrics on port 8081.
The exposed metrics are
Metric Type Description nfd_master_build_infoGauge Version from which nfd-master was built nfd_worker_build_infoGauge Version from which nfd-worker was built nfd_topology_updater_build_infoGauge Version from which nfd-topology-updater was built nfd_node_update_requests_totalCounter Number of node update requests received by the master over gRPC nfd_node_updates_totalCounter Number of nodes updated nfd_node_update_failures_totalCounter Number of nodes update failures nfd_node_labels_rejected_totalCounter Number of nodes labels rejected by nfd-master nfd_node_extendedresources_rejected_totalCounter Number of nodes extended resources rejected by nfd-master nfd_node_taints_rejected_totalCounter Number of nodes taints rejected by nfd-master nfd_nodefeaturerule_processing_duration_secondsHistogram Time taken to process NodeFeatureRule objects nfd_nodefeaturerule_processing_errors_totalCounter Number or errors encountered while processing NodeFeatureRule objects nfd_feature_discovery_duration_secondsHistogram Time taken to discover features on a node nfd_topology_updater_scan_errors_totalCounter Number of errors in scanning resource allocation of pods.
Via Kustomize
To deploy NFD with metrics enabled using kustomize, you can use the Metrics Overlay.
Via Helm
By default metrics are enabled when deploying NFD via Helm. To enable Prometheus to scrape metrics from NFD, you need to pass the following values to Helm:
--set prometheus.enable=true
+ Metrics · Node Feature Discovery
Metrics
Metrics are configured to be exposed using prometheus operator API's by default. If you want to expose metrics using the prometheus operator API's you need to install the prometheus operator in your cluster. By default NFD Master and Worker expose metrics on port 8081.
The exposed metrics are
Metric Type Description nfd_master_build_infoGauge Version from which nfd-master was built nfd_worker_build_infoGauge Version from which nfd-worker was built nfd_topology_updater_build_infoGauge Version from which nfd-topology-updater was built nfd_node_update_requests_totalCounter Number of node update requests received by the master over gRPC nfd_node_updates_totalCounter Number of nodes updated nfd_node_update_failures_totalCounter Number of nodes update failures nfd_node_labels_rejected_totalCounter Number of nodes labels rejected by nfd-master nfd_node_extendedresources_rejected_totalCounter Number of nodes extended resources rejected by nfd-master nfd_node_taints_rejected_totalCounter Number of nodes taints rejected by nfd-master nfd_nodefeaturerule_processing_duration_secondsHistogram Time taken to process NodeFeatureRule objects nfd_nodefeaturerule_processing_errors_totalCounter Number or errors encountered while processing NodeFeatureRule objects nfd_feature_discovery_duration_secondsHistogram Time taken to discover features on a node nfd_topology_updater_scan_errors_totalCounter Number of errors in scanning resource allocation of pods.
Via Kustomize
To deploy NFD with metrics enabled using kustomize, you can use the Metrics Overlay.
Via Helm
By default metrics are enabled when deploying NFD via Helm. To enable Prometheus to scrape metrics from NFD, you need to pass the following values to Helm:
--set prometheus.enable=true
For more info on Helm deployment, see Helm.
We recommend setting --set prometheus.prometheusSpec.podMonitorSelectorNilUsesHelmValues=false when deploying prometheus-operator via Helm to enable the prometheus-operator to scrape metrics from any PodMonitor.
or setting labels on the PodMonitor via the helm parameter prometheus.labels to control which Prometheus instances will scrape this PodMonitor.
Node Feature Discovery v0.14
\ No newline at end of file
diff --git a/v0.14/deployment/operator.html b/v0.14/deployment/operator.html
index c37ec49377..eaac84decc 100644
--- a/v0.14/deployment/operator.html
+++ b/v0.14/deployment/operator.html
@@ -1,4 +1,4 @@
- NFD Operator · Node Feature Discovery
Deployment with NFD Operator
Table of contents
The Node Feature Discovery Operator automates installation, configuration and updates of NFD using a specific NodeFeatureDiscovery custom resource. This also provides good support for managing NFD as a dependency of other operators.
Deployment
Deployment using the Node Feature Discovery Operator is recommended to be done via operatorhub.io.
- You need to have OLM installed. If you don't, take a look at the latest release for detailed instructions.
-
Install the operator:
kubectl create -f https://operatorhub.io/install/nfd-operator.yaml
+ NFD Operator · Node Feature Discovery
Deployment with NFD Operator
Table of contents
The Node Feature Discovery Operator automates installation, configuration and updates of NFD using a specific NodeFeatureDiscovery custom resource. This also provides good support for managing NFD as a dependency of other operators.
Deployment
Deployment using the Node Feature Discovery Operator is recommended to be done via operatorhub.io.
- You need to have OLM installed. If you don't, take a look at the latest release for detailed instructions.
-
Install the operator:
kubectl create -f https://operatorhub.io/install/nfd-operator.yaml
-
Create NodeFeatureDiscovery object (in nfd namespace here):
cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
diff --git a/v0.14/deployment/tls.html b/v0.14/deployment/tls.html
index 1c682de0b8..8ef5cf9e5f 100644
--- a/v0.14/deployment/tls.html
+++ b/v0.14/deployment/tls.html
@@ -1,4 +1,4 @@
- TLS authentication · Node Feature Discovery
Communication security with TLS
Table of contents
DEPRECATED: this section only applies when the gRPC API is used, i.e. when the NodeFeature API is disabled via the -enable-nodefeature-api=false flag on both nfd-master and nfd-worker. The gRPC API is deprecated and will be removed in a future release.
NFD supports mutual TLS authentication between the nfd-master and nfd-worker instances. That is, nfd-worker and nfd-master both verify that the other end presents a valid certificate.
TLS authentication is enabled by specifying -ca-file, -key-file and -cert-file args, on both the nfd-master and nfd-worker instances. The template specs provided with NFD contain (commented out) example configuration for enabling TLS authentication.
The Common Name (CN) of the nfd-master certificate must match the DNS name of the nfd-master Service of the cluster. By default, nfd-master only check that the nfd-worker has been signed by the specified root certificate (-ca-file).
Additional hardening can be enabled by specifying -verify-node-name in nfd-master args, in which case nfd-master verifies that the NodeName presented by nfd-worker matches the Common Name (CN) or a Subject Alternative Name (SAN) of its certificate. Note that -verify-node-name complicates certificate management and is not yet supported in the helm or kustomize deployment methods.
Automated TLS certificate management using cert-manager
cert-manager can be used to automate certificate management between nfd-master and the nfd-worker pods.
The NFD source code repository contains an example kustomize overlay and helm chart that can be used to deploy NFD with cert-manager supplied certificates enabled.
To install cert-manager itself can be done as easily as this, below, or you can refer to their documentation for other installation methods such as the helm chart they provide.
kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.yaml
+ TLS authentication · Node Feature Discovery
Communication security with TLS
Table of contents
DEPRECATED: this section only applies when the gRPC API is used, i.e. when the NodeFeature API is disabled via the -enable-nodefeature-api=false flag on both nfd-master and nfd-worker. The gRPC API is deprecated and will be removed in a future release.
NFD supports mutual TLS authentication between the nfd-master and nfd-worker instances. That is, nfd-worker and nfd-master both verify that the other end presents a valid certificate.
TLS authentication is enabled by specifying -ca-file, -key-file and -cert-file args, on both the nfd-master and nfd-worker instances. The template specs provided with NFD contain (commented out) example configuration for enabling TLS authentication.
The Common Name (CN) of the nfd-master certificate must match the DNS name of the nfd-master Service of the cluster. By default, nfd-master only check that the nfd-worker has been signed by the specified root certificate (-ca-file).
Additional hardening can be enabled by specifying -verify-node-name in nfd-master args, in which case nfd-master verifies that the NodeName presented by nfd-worker matches the Common Name (CN) or a Subject Alternative Name (SAN) of its certificate. Note that -verify-node-name complicates certificate management and is not yet supported in the helm or kustomize deployment methods.
Automated TLS certificate management using cert-manager
cert-manager can be used to automate certificate management between nfd-master and the nfd-worker pods.
The NFD source code repository contains an example kustomize overlay and helm chart that can be used to deploy NFD with cert-manager supplied certificates enabled.
To install cert-manager itself can be done as easily as this, below, or you can refer to their documentation for other installation methods such as the helm chart they provide.
kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.yaml
To use the kustomize overlay to install node-feature-discovery with TLS enabled, you may use the following:
kubectl apply -k deployment/overlays/samples/cert-manager
To make use of the helm chart, override values.yaml to enable both the tls.enabled and tls.certManager options. Note that if you do not enable tls.certManager, helm will successfully install the application, but deployment will wait until certificates are manually created, as demonstrated below.
See the sample installation commands in the Helm Deployment and Configuration sections above for how to either override individual values, or provide a yaml file with which to override default values.
Manual TLS certificate management
If you do not with to make use of cert-manager, the certificates can be manually created and stored as secrets within the NFD namespace.
Create a CA certificate
openssl req -x509 -newkey rsa:4096 -keyout ca.key -nodes \
-subj "/CN=nfd-ca" -days 10000 -out ca.crt
diff --git a/v0.14/deployment/uninstallation.html b/v0.14/deployment/uninstallation.html
index dbcf5edd39..5cbf5effa4 100644
--- a/v0.14/deployment/uninstallation.html
+++ b/v0.14/deployment/uninstallation.html
@@ -1,4 +1,4 @@
- Uninstallation · Node Feature Discovery
Uninstallation
Follow the uninstallation instructions of the deployment method used (kustomize, helm or operator).
Removing feature labels
NFD-Master has a special -prune command line flag for removing all nfd-related node labels, annotations, extended resources and taints from the cluster.
kubectl apply -k https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/prune?ref=v0.14.2
+ Uninstallation · Node Feature Discovery
Uninstallation
Follow the uninstallation instructions of the deployment method used (kustomize, helm or operator).
Removing feature labels
NFD-Master has a special -prune command line flag for removing all nfd-related node labels, annotations, extended resources and taints from the cluster.
kubectl apply -k https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/prune?ref=v0.14.2
kubectl -n node-feature-discovery wait job.batch/nfd-master --for=condition=complete && \
kubectl delete -k https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/prune?ref=v0.14.2
NOTE: You must run prune before removing the RBAC rules (serviceaccount, clusterrole and clusterrolebinding).
Node Feature Discovery v0.14
\ No newline at end of file
diff --git a/v0.14/developer-guide/index.html b/v0.14/developer-guide/index.html
index 49acf65ab7..de1d21335b 100644
--- a/v0.14/developer-guide/index.html
+++ b/v0.14/developer-guide/index.html
@@ -1,4 +1,4 @@
- Developer guide · Node Feature Discovery
Developer guide
Table of contents
Building from source
Download the source code
git clone https://github.com/kubernetes-sigs/node-feature-discovery
+ Developer guide · Node Feature Discovery
Developer guide
Table of contents
Building from source
Download the source code
git clone https://github.com/kubernetes-sigs/node-feature-discovery
cd node-feature-discovery
Docker build
Build the container image
See customizing the build below for altering the container image registry, for example.
make
Push the container image
Optional, this example with Docker.
docker push <IMAGE_TAG>
diff --git a/v0.14/get-started/index.html b/v0.14/get-started/index.html
index 09f1f87bef..aa71c28b79 100644
--- a/v0.14/get-started/index.html
+++ b/v0.14/get-started/index.html
@@ -1,4 +1,4 @@
- Get started · Node Feature Discovery
Node Feature Discovery
Welcome to Node Feature Discovery – a Kubernetes add-on for detecting hardware features and system configuration!
Continue to:
-
Introduction for more details on the project.
-
Quick start for quick step-by-step instructions on how to get NFD running on your cluster.
Quick-start – the short-short version
$ kubectl apply -k https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/default?ref=v0.14.2
+ Get started · Node Feature Discovery
Node Feature Discovery
Welcome to Node Feature Discovery – a Kubernetes add-on for detecting hardware features and system configuration!
Continue to:
-
Introduction for more details on the project.
-
Quick start for quick step-by-step instructions on how to get NFD running on your cluster.
Quick-start – the short-short version
$ kubectl apply -k https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/default?ref=v0.14.2
namespace/node-feature-discovery created
serviceaccount/nfd-master created
clusterrole.rbac.authorization.k8s.io/nfd-master created
diff --git a/v0.14/get-started/introduction.html b/v0.14/get-started/introduction.html
index c8aab4265e..ffcafd8e5f 100644
--- a/v0.14/get-started/introduction.html
+++ b/v0.14/get-started/introduction.html
@@ -1,4 +1,4 @@
- Introduction · Node Feature Discovery
Introduction
Table of contents
- NFD-Master
- NFD-Worker
- NFD-Topology-Updater
- NFD-GC
- Feature Discovery
- Node annotations
- Custom resources
This software enables node feature discovery for Kubernetes. It detects hardware features available on each node in a Kubernetes cluster, and advertises those features using node labels and optionally node extended resources and node taints. Node Feature Discovery is compatible with any recent version of Kubernetes (v1.21+).
NFD consists of four software components:
- nfd-master
- nfd-worker
- nfd-topology-updater
- nfd-gc
NFD-Master
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 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,
NFD-Topology-Updater
NFD-Topology-Updater is a daemon responsible for examining allocated resources on a worker node to account for resources available to be allocated to new pod on a per-zone basis (where a zone can be a NUMA node). It then creates or updates a NodeResourceTopology custom resource object specific to this node. One instance of nfd-topology-updater is supposed to be running on each node of the cluster.
NFD-GC
NFD-GC is a daemon responsible for cleaning obsolete NodeFeature and NodeResourceTopology objects.
One instance of nfd-gc is supposed to be running in the cluster.
Feature Discovery
Feature discovery is divided into domain-specific feature sources:
- CPU
- Kernel
- Memory
- Network
- PCI
- Storage
- System
- USB
- Custom (rule-based custom features)
- Local (hooks for user-specific features)
Each feature source is responsible for detecting a set of features which. in turn, are turned into node feature labels. Feature labels are prefixed with feature.node.kubernetes.io/ and also contain the name of the feature source. Non-standard user-specific feature labels can be created with the local and custom feature sources.
An overview of the default feature labels:
{
+ Introduction · Node Feature Discovery
Introduction
Table of contents
- NFD-Master
- NFD-Worker
- NFD-Topology-Updater
- NFD-GC
- Feature Discovery
- Node annotations
- Custom resources
This software enables node feature discovery for Kubernetes. It detects hardware features available on each node in a Kubernetes cluster, and advertises those features using node labels and optionally node extended resources and node taints. Node Feature Discovery is compatible with any recent version of Kubernetes (v1.21+).
NFD consists of four software components:
- nfd-master
- nfd-worker
- nfd-topology-updater
- nfd-gc
NFD-Master
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 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,
NFD-Topology-Updater
NFD-Topology-Updater is a daemon responsible for examining allocated resources on a worker node to account for resources available to be allocated to new pod on a per-zone basis (where a zone can be a NUMA node). It then creates or updates a NodeResourceTopology custom resource object specific to this node. One instance of nfd-topology-updater is supposed to be running on each node of the cluster.
NFD-GC
NFD-GC is a daemon responsible for cleaning obsolete NodeFeature and NodeResourceTopology objects.
One instance of nfd-gc is supposed to be running in the cluster.
Feature Discovery
Feature discovery is divided into domain-specific feature sources:
- CPU
- Kernel
- Memory
- Network
- PCI
- Storage
- System
- USB
- Custom (rule-based custom features)
- Local (hooks for user-specific features)
Each feature source is responsible for detecting a set of features which. in turn, are turned into node feature labels. Feature labels are prefixed with feature.node.kubernetes.io/ and also contain the name of the feature source. Non-standard user-specific feature labels can be created with the local and custom feature sources.
An overview of the default feature labels:
{
"feature.node.kubernetes.io/cpu-<feature-name>": "true",
"feature.node.kubernetes.io/custom-<feature-name>": "true",
"feature.node.kubernetes.io/kernel-<feature name>": "<feature value>",
diff --git a/v0.14/get-started/quick-start.html b/v0.14/get-started/quick-start.html
index 9524c73439..6750ad44e0 100644
--- a/v0.14/get-started/quick-start.html
+++ b/v0.14/get-started/quick-start.html
@@ -1,4 +1,4 @@
- Quick start · Node Feature Discovery
Quick start
Minimal steps to deploy latest released version of NFD in your cluster.
Installation
Deploy with kustomize – creates a new namespace, service and required RBAC rules and deploys nfd-master and nfd-worker daemons.
kubectl apply -k https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/default?ref=v0.14.2
+ Quick start · Node Feature Discovery
Quick start
Minimal steps to deploy latest released version of NFD in your cluster.
Installation
Deploy with kustomize – creates a new namespace, service and required RBAC rules and deploys nfd-master and nfd-worker daemons.
kubectl apply -k https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/default?ref=v0.14.2
Verify
Wait until NFD master and NFD worker are running.
$ kubectl -n node-feature-discovery get ds,deploy
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/nfd-worker 2 2 2 2 2 <none> 10s
diff --git a/v0.14/reference/gc-commandline-reference.html b/v0.14/reference/gc-commandline-reference.html
index f1e66710f2..7c529184e1 100644
--- a/v0.14/reference/gc-commandline-reference.html
+++ b/v0.14/reference/gc-commandline-reference.html
@@ -1,4 +1,4 @@
- Garbage Collector Cmdline Reference · Node Feature Discovery
NFD-GC Commandline Flags
Table of Contents
To quickly view available command line flags execute nfd-gc -help. In a docker container:
docker run registry.k8s.io/nfd/node-feature-discovery:v0.14.2 \
+ Garbage Collector Cmdline Reference · Node Feature Discovery
NFD-GC Commandline Flags
Table of Contents
To quickly view available command line flags execute nfd-gc -help. In a docker container:
docker run registry.k8s.io/nfd/node-feature-discovery:v0.14.2 \
nfd-gc -help
-h, -help
Print usage and exit.
-version
Print version and exit.
-gc-interval
The -gc-interval specifies the interval between periodic garbage collector runs.
Default: 1h
Example:
nfd-gc -gc-interval=1h
Node Feature Discovery v0.14
\ No newline at end of file
diff --git a/v0.14/reference/index.html b/v0.14/reference/index.html
index 618041bea9..abf01986ef 100644
--- a/v0.14/reference/index.html
+++ b/v0.14/reference/index.html
@@ -1 +1 @@
- Reference · Node Feature Discovery
Reference
Command line and configuration reference.
Node Feature Discovery v0.14
\ No newline at end of file
+ Reference · Node Feature Discovery
Reference
Command line and configuration reference.
Node Feature Discovery v0.14
\ No newline at end of file
diff --git a/v0.14/reference/master-commandline-reference.html b/v0.14/reference/master-commandline-reference.html
index 39b876e4a6..a13257d02f 100644
--- a/v0.14/reference/master-commandline-reference.html
+++ b/v0.14/reference/master-commandline-reference.html
@@ -1,4 +1,4 @@
- Master cmdline reference · Node Feature Discovery
Commandline flags of nfd-master
Table of contents
- -h, -help
- -version
- -prune
- -port
- -metrics
- -instance
- -ca-file
- -cert-file
- -key-file
- -verify-node-name
- -enable-nodefeature-api
- -enable-leader-election
- -enable-taints
- -no-publish
- -crd-controller
- -featurerules-controller
- -label-whitelist
- -extra-label-ns
- -deny-label-ns
- -resource-labels
- -config
- -options
- -nfd-api-parallelism
- Logging
- -resync-period
To quickly view available command line flags execute nfd-master -help. In a docker container:
docker run registry.k8s.io/nfd/node-feature-discovery:v0.14.2 nfd-master -help
+ Master cmdline reference · Node Feature Discovery
Commandline flags of nfd-master
Table of contents
- -h, -help
- -version
- -prune
- -port
- -metrics
- -instance
- -ca-file
- -cert-file
- -key-file
- -verify-node-name
- -enable-nodefeature-api
- -enable-leader-election
- -enable-taints
- -no-publish
- -crd-controller
- -featurerules-controller
- -label-whitelist
- -extra-label-ns
- -deny-label-ns
- -resource-labels
- -config
- -options
- -nfd-api-parallelism
- Logging
- -resync-period
To quickly view available command line flags execute nfd-master -help. In a docker container:
docker run registry.k8s.io/nfd/node-feature-discovery:v0.14.2 nfd-master -help
-h, -help
Print usage and exit.
-version
Print version and exit.
-prune
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.
-port
The -port flag specifies the TCP port that nfd-master listens for incoming requests.
Default: 8080
Example:
nfd-master -port=443
-metrics
The -metrics flag specifies the port on which to expose Prometheus metrics. Setting this to 0 disables the metrics server on nfd-master.
Default: 8081
Example:
nfd-master -metrics=12345
-instance
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
diff --git a/v0.14/reference/master-configuration-reference.html b/v0.14/reference/master-configuration-reference.html
index 8a46291660..f3e3426d08 100644
--- a/v0.14/reference/master-configuration-reference.html
+++ b/v0.14/reference/master-configuration-reference.html
@@ -1,4 +1,4 @@
- Master config reference · Node Feature Discovery
Configuration file reference of nfd-master
Table of contents
- noPublish
- extraLabelNs
- denyLabelNs
- resourceLabels
- enableTaints
- labelWhiteList
- resyncPeriod
- leaderElection
- nfdApiParallelism
- klog
See the sample configuration file for a full example configuration.
noPublish
noPublish option disables updates to the Node objects in the Kubernetes API server, making a "dry-run" flag for nfd-master. No Labels, Annotations, Taints or ExtendedResources of nodes are updated.
Default: false
Example:
noPublish: true
+ Master config reference · Node Feature Discovery
Configuration file reference of nfd-master
Table of contents
- noPublish
- extraLabelNs
- denyLabelNs
- resourceLabels
- enableTaints
- labelWhiteList
- resyncPeriod
- leaderElection
- nfdApiParallelism
- klog
See the sample configuration file for a full example configuration.
noPublish
noPublish option disables updates to the Node objects in the Kubernetes API server, making a "dry-run" flag for nfd-master. No Labels, Annotations, Taints or ExtendedResources of nodes are updated.
Default: false
Example:
noPublish: true
extraLabelNs
extraLabelNs specifies a list of allowed feature label namespaces. This option can be used to allow other vendor or application specific namespaces for custom labels from the local and custom feature sources, even though these labels were denied using the denyLabelNs parameter.
The same namespace control and this option applies to Extended Resources (created with resourceLabels), too.
Default: empty
Example:
extraLabelNs: ["added.ns.io","added.kubernets.io"]
denyLabelNs
denyLabelNs specifies a list of excluded label namespaces. By default, nfd-master allows creating labels in all namespaces, excluding kubernetes.io namespace and its sub-namespaces (i.e. *.kubernetes.io). However, you should note that kubernetes.io and its sub-namespaces are always denied. This option can be used to exclude some vendors or application specific namespaces. Note that the namespaces feature.node.kubernetes.io and profile.node.kubernetes.io and their sub-namespaces are always allowed and cannot be denied.
Default: empty
Example:
denyLabelNs: ["denied.ns.io","denied.kubernetes.io"]
resourceLabels
DEPRECATED: NodeFeatureRule should be used for managing extended resources in NFD.
The resourceLabels option specifies a 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 option.
Default: empty
Example:
resourceLabels: ["vendor-1.com/feature-1","vendor-2.io/feature-2"]
diff --git a/v0.14/reference/topology-updater-commandline-reference.html b/v0.14/reference/topology-updater-commandline-reference.html
index f58a9fe399..1d330022d8 100644
--- a/v0.14/reference/topology-updater-commandline-reference.html
+++ b/v0.14/reference/topology-updater-commandline-reference.html
@@ -1,4 +1,4 @@
- Topology Updater Cmdline Reference · Node Feature Discovery
NFD-Topology-Updater Commandline Flags
Table of Contents
- -h, -help
- -version
- -config
- -no-publish
- -oneshot
- -metrics
- -sleep-interval
- -watch-namespace
- -kubelet-config-uri
- -api-auth-token-file
- -podresources-socket
- -pods-fingerprint
- -kubelet-state-dir
To quickly view available command line flags execute nfd-topology-updater -help. In a docker container:
docker run registry.k8s.io/nfd/node-feature-discovery:v0.14.2 \
+ Topology Updater Cmdline Reference · Node Feature Discovery
NFD-Topology-Updater Commandline Flags
Table of Contents
- -h, -help
- -version
- -config
- -no-publish
- -oneshot
- -metrics
- -sleep-interval
- -watch-namespace
- -kubelet-config-uri
- -api-auth-token-file
- -podresources-socket
- -pods-fingerprint
- -kubelet-state-dir
To quickly view available command line flags execute nfd-topology-updater -help. In a docker container:
docker run registry.k8s.io/nfd/node-feature-discovery:v0.14.2 \
nfd-topology-updater -help
-h, -help
Print usage and exit.
-version
Print version and exit.
-config
The -config flag specifies the path of the nfd-topology-updater configuration file to use.
Default: /etc/kubernetes/node-feature-discovery/nfd-topology-updater.conf
Example:
nfd-topology-updater -config=/opt/nfd/nfd-topology-updater.conf
-no-publish
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
diff --git a/v0.14/reference/topology-updater-configuration-reference.html b/v0.14/reference/topology-updater-configuration-reference.html
index 2145c96711..4aa749f8db 100644
--- a/v0.14/reference/topology-updater-configuration-reference.html
+++ b/v0.14/reference/topology-updater-configuration-reference.html
@@ -1,4 +1,4 @@
- Topology-Updater config reference · Node Feature Discovery
Configuration file reference of nfd-topology-updater
Table of contents
See the sample configuration file for a full example configuration.
excludeList
The excludeList specifies a key-value map of allocated resources that should not be examined by the topology-updater agent per node. Each key is a node name with a value as a list of resources that should not be examined by the agent for that specific node.
Default: empty
Example:
excludeList:
+ Topology-Updater config reference · Node Feature Discovery
Configuration file reference of nfd-topology-updater
Table of contents
See the sample configuration file for a full example configuration.
excludeList
The excludeList specifies a key-value map of allocated resources that should not be examined by the topology-updater agent per node. Each key is a node name with a value as a list of resources that should not be examined by the agent for that specific node.
Default: empty
Example:
excludeList:
nodeA: [hugepages-2Mi]
nodeB: [memory]
nodeC: [cpu, hugepages-2Mi]
diff --git a/v0.14/reference/versions.html b/v0.14/reference/versions.html
index 0aff2f0fab..a0dcdc738a 100644
--- a/v0.14/reference/versions.html
+++ b/v0.14/reference/versions.html
@@ -1 +1 @@
- Versions · Node Feature Discovery
Versions and deprecation
Supported versions
Node Feature Discovery follows semantic versioning where the version number consists of three components, i.e. MAJOR.MINOR.PATCH.
The most recent two minor releases (or release branches) of Node Feature Discovery are supported. That is, with X being the latest release, X and X-1 are supported and X-1 reaches end-of-life when X+1 is released.
Deprecation policy
Feature labels
Built-in feature labels and features are supported for 2 releases after being deprecated, at minimum. That is, if a feature label is deprecated in version X, it will be supported in X+1 and X+2 and may be dropped in X+3.
Configuration options
Command-line flags and configuration file options are supported for 1 more release after being deprecated, at minimum. That is, if option/flag is deprecated in version X, it will be supported in X+1 and may be removed in X+2.
The same policy (support for 1 release after deprecation) also applies to Helm chart parameters.
Node Feature Discovery v0.14
\ No newline at end of file
+ Versions · Node Feature Discovery
Versions and deprecation
Supported versions
Node Feature Discovery follows semantic versioning where the version number consists of three components, i.e. MAJOR.MINOR.PATCH.
The most recent two minor releases (or release branches) of Node Feature Discovery are supported. That is, with X being the latest release, X and X-1 are supported and X-1 reaches end-of-life when X+1 is released.
Deprecation policy
Feature labels
Built-in feature labels and features are supported for 2 releases after being deprecated, at minimum. That is, if a feature label is deprecated in version X, it will be supported in X+1 and X+2 and may be dropped in X+3.
Configuration options
Command-line flags and configuration file options are supported for 1 more release after being deprecated, at minimum. That is, if option/flag is deprecated in version X, it will be supported in X+1 and may be removed in X+2.
The same policy (support for 1 release after deprecation) also applies to Helm chart parameters.
Node Feature Discovery v0.14
\ No newline at end of file
diff --git a/v0.14/reference/worker-commandline-reference.html b/v0.14/reference/worker-commandline-reference.html
index 5efcafda80..eae66f9298 100644
--- a/v0.14/reference/worker-commandline-reference.html
+++ b/v0.14/reference/worker-commandline-reference.html
@@ -1,4 +1,4 @@
- Worker cmdline reference · Node Feature Discovery
Commandline flags of nfd-worker
Table of contents
- -h, -help
- -version
- -config
- -options
- -server
- -ca-file
- -cert-file
- -key-file
- -kubeconfig
- -server-name-override
- -feature-sources
- -label-sources
- -enable-nodefeature-api
- -metrics
- -no-publish
- -oneshot
- Logging
To quickly view available command line flags execute nfd-worker -help. In a docker container:
docker run registry.k8s.io/nfd/node-feature-discovery:v0.14.2 nfd-worker -help
+ Worker cmdline reference · Node Feature Discovery
Commandline flags of nfd-worker
Table of contents
- -h, -help
- -version
- -config
- -options
- -server
- -ca-file
- -cert-file
- -key-file
- -kubeconfig
- -server-name-override
- -feature-sources
- -label-sources
- -enable-nodefeature-api
- -metrics
- -no-publish
- -oneshot
- Logging
To quickly view available command line flags execute nfd-worker -help. In a docker container:
docker run registry.k8s.io/nfd/node-feature-discovery:v0.14.2 nfd-worker -help
-h, -help
Print usage and exit.
-version
Print version and exit.
-config
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
-options
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"]}}}}'
-server
NOTE the gRPC API is deprecated and will be removed in a future release. and this flag will be removed as well.
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
diff --git a/v0.14/reference/worker-configuration-reference.html b/v0.14/reference/worker-configuration-reference.html
index 543b39737a..ff47c0b57b 100644
--- a/v0.14/reference/worker-configuration-reference.html
+++ b/v0.14/reference/worker-configuration-reference.html
@@ -1,4 +1,4 @@
- Worker config reference · Node Feature Discovery
Configuration file reference of nfd-worker
Table of contents
See the sample configuration file for a full example configuration.
core
The core section contains common configuration settings that are not specific to any particular feature source.
core.sleepInterval
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.
Default: 60s
Example:
core:
+ Worker config reference · Node Feature Discovery