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/master/deployment/image-variants.html b/master/deployment/image-variants.html
index ff6764406..616ce4439 100644
--- a/master/deployment/image-variants.html
+++ b/master/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 scratch and only supports running statically linked binaries.
For backwards compatibility a container image tag with suffix -minimal (e.g. gcr.io/k8s-staging-nfd/node-feature-discovery:master-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. gcr.io/k8s-staging-nfd/node-feature-discovery:master-full).
Node Feature Discovery master
\ 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 scratch and only supports running statically linked binaries.
For backwards compatibility a container image tag with suffix -minimal (e.g. gcr.io/k8s-staging-nfd/node-feature-discovery:master-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. gcr.io/k8s-staging-nfd/node-feature-discovery:master-full).
Node Feature Discovery master
\ No newline at end of file
diff --git a/master/deployment/index.html b/master/deployment/index.html
index f0b793a4d..d35c99551 100644
--- a/master/deployment/index.html
+++ b/master/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 master
\ 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 master
\ No newline at end of file
diff --git a/master/deployment/kustomize.html b/master/deployment/kustomize.html
index 9368a2801..3e9b0c36a 100644
--- a/master/deployment/kustomize.html
+++ b/master/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=master
+ 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=master
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=master
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/master/deployment/metrics.html b/master/deployment/metrics.html
index 7d834dfc8..ea1b0e835 100644
--- a/master/deployment/metrics.html
+++ b/master/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_gc_build_infoGauge Version from which nfd-gc 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. nfd_gc_objects_deleted_totalCounter Number of NodeFeature and NodeResourceTopology objects garbage collected. nfd_gc_object_delete_failures_totalCounter Number of errors in deleting NodeFeature and NodeResourceTopology objects.
Kustomize
To deploy NFD with metrics enabled using kustomize, you can use the Metrics Overlay.
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_gc_build_infoGauge Version from which nfd-gc 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. nfd_gc_objects_deleted_totalCounter Number of NodeFeature and NodeResourceTopology objects garbage collected. nfd_gc_object_delete_failures_totalCounter Number of errors in deleting NodeFeature and NodeResourceTopology objects.
Kustomize
To deploy NFD with metrics enabled using kustomize, you can use the Metrics Overlay.
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.
Grafana dashboard
NFD contains an example Grafana dashboard. You can import examples/grafana-dashboard.json to your Grafana instance to visualize the NFD metrics.
Node Feature Discovery master
\ No newline at end of file
diff --git a/master/deployment/operator.html b/master/deployment/operator.html
index 605ea9a06..dda6ec1f1 100644
--- a/master/deployment/operator.html
+++ b/master/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/master/deployment/tls.html b/master/deployment/tls.html
index fdefcb04f..578a3a76d 100644
--- a/master/deployment/tls.html
+++ b/master/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/master/deployment/uninstallation.html b/master/deployment/uninstallation.html
index 545f63362..dedd507c4 100644
--- a/master/deployment/uninstallation.html
+++ b/master/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=master
+ 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=master
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=master
NOTE: You must run prune before removing the RBAC rules (serviceaccount, clusterrole and clusterrolebinding).
Node Feature Discovery master
\ No newline at end of file
diff --git a/master/developer-guide/index.html b/master/developer-guide/index.html
index 89885736f..8e3c2aef8 100644
--- a/master/developer-guide/index.html
+++ b/master/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/master/get-started/index.html b/master/get-started/index.html
index 81cb0f81c..448abc458 100644
--- a/master/get-started/index.html
+++ b/master/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=master
+ 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=master
namespace/node-feature-discovery created
serviceaccount/nfd-master created
clusterrole.rbac.authorization.k8s.io/nfd-master created
diff --git a/master/get-started/introduction.html b/master/get-started/introduction.html
index a4b47f42f..e1dd15654 100644
--- a/master/get-started/introduction.html
+++ b/master/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, annotations 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, annotations 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/master/get-started/quick-start.html b/master/get-started/quick-start.html
index 2a201928a..86efd614c 100644
--- a/master/get-started/quick-start.html
+++ b/master/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=master
+ 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=master
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/master/reference/gc-commandline-reference.html b/master/reference/gc-commandline-reference.html
index fbabad610..7a73c78a5 100644
--- a/master/reference/gc-commandline-reference.html
+++ b/master/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 gcr.io/k8s-staging-nfd/node-feature-discovery:master \
+ 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 gcr.io/k8s-staging-nfd/node-feature-discovery:master \
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 master
\ No newline at end of file
diff --git a/master/reference/index.html b/master/reference/index.html
index a72156a87..844d31995 100644
--- a/master/reference/index.html
+++ b/master/reference/index.html
@@ -1 +1 @@
- Reference · Node Feature Discovery
Reference
Command line and configuration reference.
Node Feature Discovery master
\ No newline at end of file
+ Reference · Node Feature Discovery
Reference
Command line and configuration reference.
Node Feature Discovery master
\ No newline at end of file
diff --git a/master/reference/master-commandline-reference.html b/master/reference/master-commandline-reference.html
index bacc66fb2..0af6d8d64 100644
--- a/master/reference/master-commandline-reference.html
+++ b/master/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 gcr.io/k8s-staging-nfd/node-feature-discovery:master 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 gcr.io/k8s-staging-nfd/node-feature-discovery:master 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/master/reference/master-configuration-reference.html b/master/reference/master-configuration-reference.html
index 0383cce4e..27a53775d 100644
--- a/master/reference/master-configuration-reference.html
+++ b/master/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
- autoDefaultNs
- 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
- autoDefaultNs
- 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"]
autoDefaultNs
The autoDefaultNs option controls the automatic prefixing of names. When set to true (the default in master) nfd-master automatically adds the default feature.node.kubernetes.io/ prefix to unprefixed labels, annotations and extended resources - this is also the default behavior in NFD v0.13 and earlier. When the option is set to false, no prefix will be prepended to unprefixed names, effectively causing them to be filtered out (as NFD does not currently allow unprefixed names of labels, annotations or extended resources). The default will be changed to false in a future release.
For example, with the autoDefaultNs set to true, a NodeFeatureRule with
labels:
diff --git a/master/reference/topology-updater-commandline-reference.html b/master/reference/topology-updater-commandline-reference.html
index 8034c035c..83b7937e2 100644
--- a/master/reference/topology-updater-commandline-reference.html
+++ b/master/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 gcr.io/k8s-staging-nfd/node-feature-discovery:master \
+ 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 gcr.io/k8s-staging-nfd/node-feature-discovery:master \
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/master/reference/topology-updater-configuration-reference.html b/master/reference/topology-updater-configuration-reference.html
index b40792e68..c0244dd23 100644
--- a/master/reference/topology-updater-configuration-reference.html
+++ b/master/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/master/reference/versions.html b/master/reference/versions.html
index bed473ca8..33aa51512 100644
--- a/master/reference/versions.html
+++ b/master/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 master
\ 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 master
\ No newline at end of file
diff --git a/master/reference/worker-commandline-reference.html b/master/reference/worker-commandline-reference.html
index 8dea4bea3..fef5a7859 100644
--- a/master/reference/worker-commandline-reference.html
+++ b/master/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 gcr.io/k8s-staging-nfd/node-feature-discovery:master 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 gcr.io/k8s-staging-nfd/node-feature-discovery:master 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/master/reference/worker-configuration-reference.html b/master/reference/worker-configuration-reference.html
index ec1e81d66..8da14ffb7 100644
--- a/master/reference/worker-configuration-reference.html
+++ b/master/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