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 provides a Helm chart to manage its deployment.
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 provides a Helm chart to manage its deployment.
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 3d3023869..d089450fb 100644
--- a/master/deployment/image-variants.html
+++ b/master/deployment/image-variants.html
@@ -1 +1 @@
- Image variants · Node Feature Discovery
Image variants
NFD offers two variants of the container image. Released container images are available for x86_64 and Arm64 architectures.
Default
The default 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:bookworm-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 offers two variants of the container image. Released container images are available for x86_64 and Arm64 architectures.
Default
The default 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:bookworm-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 d0ee7d219..34494909e 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 6bea3ad6a..0a10e15ba 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 can be used to deploy 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 can be used to deploy 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. Refer to the Master Worker Topologyupdater and Topologyupdater below.
Alternatively you can clone the repository and customize the deployment by creating your own overlays. 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-job: see Worker one-shot belowmaster-worker-topologyupdater: see Master Worker Topologyupdater belowtopologyupdater: see Topology Updater belowprometheus: 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
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)
kubectl kustomize https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/default-job?ref=master | \
sed s"/NUM_NODES/$NUM_NODES/" | \
diff --git a/master/deployment/metrics.html b/master/deployment/metrics.html
index 9a5ff44a6..2bff32486 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 prometheus 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 prometheus 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.
It is recommended to specify --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 c0eba539c..7a6ea30e9 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 bcf4757ee..6513c3276 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.
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, you can run:
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.2/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.
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, you can run:
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.2/cert-manager.yaml
Alternatively, you can refer to cert-manager documentation for other installation methods such as the Helm chart they provide.
When using the Helm chart to deploy NFD, 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
Create a common openssl config file.
cat <<EOF > nfd-common.conf
diff --git a/master/deployment/uninstallation.html b/master/deployment/uninstallation.html
index 18d9f5743..54af7f7fd 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
NOTE: This is unnecessary when using the Helm chart for deployment as it will clean up the nodes when NFD is uninstalled.
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
NOTE: This is unnecessary when using the Helm chart for deployment as it will clean up the nodes when NFD is uninstalled.
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 4c674ade4..b5359dabe 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 76362984a..d422feaa1 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 ea7742b57..11a1a1b95 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 16eeb3400..79f545248 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 d89705327..596a3656c 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 1f232c46a..052ba4a16 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 bddbe82fd..504a4b71e 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 670e348d0..1f0f2d3d7 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.
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 NFD version 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.15 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 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/plugin-commandline-reference.html b/master/reference/plugin-commandline-reference.html
index be70f0cb7..fdc0c42da 100644
--- a/master/reference/plugin-commandline-reference.html
+++ b/master/reference/plugin-commandline-reference.html
@@ -1 +1 @@
- Kubectl plugin cmdline reference · Node Feature Discovery
Commandline flags of kubectl-nfd (plugin)
Table of contents
To quickly view available command line flags execute kubectl nfd -help.
-h, -help
Print usage and exit.
Validate
Validate a NodeFeatureRule file.
-f / –nodefeature-file
The --nodefeature-file flag specifies the path to the NodeFeatureRule file to validate.
Test
Test a NodeFeatureRule file against a node without applying it.
-k, –kubeconfig
The --kubeconfig flag specifies the path to the kubeconfig file to use for CLI requests.
-s, –namespace
The --namespace flag specifies the namespace to use for CLI requests. Default: default.
-n, –nodename
The --nodename flag specifies the name of the node to test the NodeFeatureRule against.
-f, –nodefeaturerule-file
The --nodefeaturerule-file flag specifies the path to the NodeFeatureRule file to test.
DryRun
Process a NodeFeatureRule file against a NodeFeature file.
-f, –nodefeaturerule-file
The --nodefeaturerule-file flag specifies the path to the NodeFeatureRule file to test.
-n, –nodefeature-file
The --nodefeature-file flag specifies the path to the NodeFeature file to test.
Node Feature Discovery master
\ No newline at end of file
+ Kubectl plugin cmdline reference · Node Feature Discovery
Commandline flags of kubectl-nfd (plugin)
Table of contents
To quickly view available command line flags execute kubectl nfd -help.
-h, -help
Print usage and exit.
Validate
Validate a NodeFeatureRule file.
-f / –nodefeature-file
The --nodefeature-file flag specifies the path to the NodeFeatureRule file to validate.
Test
Test a NodeFeatureRule file against a node without applying it.
-k, –kubeconfig
The --kubeconfig flag specifies the path to the kubeconfig file to use for CLI requests.
-s, –namespace
The --namespace flag specifies the namespace to use for CLI requests. Default: default.
-n, –nodename
The --nodename flag specifies the name of the node to test the NodeFeatureRule against.
-f, –nodefeaturerule-file
The --nodefeaturerule-file flag specifies the path to the NodeFeatureRule file to test.
DryRun
Process a NodeFeatureRule file against a NodeFeature file.
-f, –nodefeaturerule-file
The --nodefeaturerule-file flag specifies the path to the NodeFeatureRule file to test.
-n, –nodefeature-file
The --nodefeature-file flag specifies the path to the NodeFeature file to test.
Node Feature Discovery master
\ No newline at end of file
diff --git a/master/reference/topology-updater-commandline-reference.html b/master/reference/topology-updater-commandline-reference.html
index 022c5d987..d549df4a5 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 3c6b06ae0..e0d25e633 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 7fada6f5b..3845994fe 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 4dc1d0e2a..183d3070c 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 e5edfcb7d..d7a976de1 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