404
Not Found
Not Found
git clone https://github.com/kubernetes-sigs/node-feature-discovery
+cd node-feature-discovery
+See customizing the build below for altering the container image registry, for example.
make
+Optional, this example with Docker.
docker push <IMAGE_TAG>
+To use your published image from the step above instead of the k8s.gcr.io/nfd/node-feature-discovery image, edit image attribute in the spec template(s) to the new location (<registry-name>/<image-name>[:<version>]).
The yamls makefile generates deployment specs matching your locally built image. See build customization below for configurability, e.g. changing the deployment namespace.
K8S_NAMESPACE=my-ns make yamls
+kubectl apply -f nfd-master.yaml
+kubectl apply -f nfd-worker-daemonset.yaml
+Alternatively, deploying worker and master in the same pod:
K8S_NAMESPACE=my-ns make yamls
+kubectl apply -f nfd-master.yaml
+kubectl apply -f nfd-daemonset-combined.yaml
+Or worker as a one-shot job:
K8S_NAMESPACE=my-ns make yamls
+kubectl apply -f nfd-master.yaml
+NUM_NODES=$(kubectl get no -o jsonpath='{.items[*].metadata.name}' | wc -w)
+sed s"/NUM_NODES/$NUM_NODES/" nfd-worker-job.yaml | kubectl apply -f -
+You can also build the binaries locally
make build
+This will compile binaries under bin/
There are several Makefile variables that control the build process and the name of the resulting container image. The following are targeted targeted for build customization and they can be specified via environment variables or makefile overrides.
| Variable | Description | Default value |
|---|---|---|
| HOSTMOUNT_PREFIX | Prefix of system directories for feature discovery (local builds) | / (local builds) /host- (container builds) |
| IMAGE_BUILD_CMD | Command to build the image | docker build |
| IMAGE_BUILD_EXTRA_OPTS | Extra options to pass to build command | empty |
| IMAGE_PUSH_CMD | Command to push the image to remote registry | docker push |
| IMAGE_REGISTRY | Container image registry to use | k8s.gcr.io/nfd |
| IMAGE_TAG_NAME | Container image tag name | <nfd version> |
| IMAGE_EXTRA_TAG_NAMES | Additional container image tag(s) to create when building image | empty |
| K8S_NAMESPACE | nfd-master and nfd-worker namespace | kube-system |
| KUBECONFIG | Kubeconfig for running e2e-tests | empty |
| E2E_TEST_CONFIG | Parameterization file of e2e-tests (see example) | empty |
For example, to use a custom registry:
make IMAGE_REGISTRY=<my custom registry uri>
+Or to specify a build tool different from Docker, It can be done in 2 ways:
IMAGE_BUILD_CMD="buildah bud" make
+make IMAGE_BUILD_CMD="buildah bud"
+Unit tests are automatically run as part of the container image build. You can also run them manually in the source code tree by simply running:
make test
+End-to-end tests are built on top of the e2e test framework of Kubernetes, and, they required a cluster to run them on. For running the tests on your test cluster you need to specify the kubeconfig to be used:
make e2e-test KUBECONFIG=$HOME/.kube/config
+You can run NFD locally, either directly on your host OS or in containers for testing and development purposes. This may be useful e.g. for checking features-detection.
When running as a standalone container labeling is expected to fail because Kubernetes API is not available. Thus, it is recommended to use --no-publish command line flag. E.g.
$ export NFD_CONTAINER_IMAGE=gcr.io/k8s-staging-nfd/node-feature-discovery:master
+$ docker run --rm --name=nfd-test ${NFD_CONTAINER_IMAGE} nfd-master --no-publish
+2019/02/01 14:48:21 Node Feature Discovery Master <NFD_VERSION>
+2019/02/01 14:48:21 gRPC server serving on port: 8080
+Command line flags of nfd-master:
$ docker run --rm ${NFD_CONTAINER_IMAGE} nfd-master --help
+...
+Usage:
+ nfd-master [--prune] [--no-publish] [--label-whitelist=<pattern>] [--port=<port>]
+ [--ca-file=<path>] [--cert-file=<path>] [--key-file=<path>]
+ [--verify-node-name] [--extra-label-ns=<list>] [--resource-labels=<list>]
+ [--kubeconfig=<path>]
+ nfd-master -h | --help
+ nfd-master --version
+
+ Options:
+ -h --help Show this screen.
+ --version Output version and exit.
+ --prune Prune all NFD related attributes from all nodes
+ of the cluster and exit.
+ --kubeconfig=<path> Kubeconfig to use [Default: ]
+ --port=<port> Port on which to listen for connections.
+ [Default: 8080]
+ --ca-file=<path> Root certificate for verifying connections
+ [Default: ]
+ --cert-file=<path> Certificate used for authenticating connections
+ [Default: ]
+ --key-file=<path> Private key matching --cert-file
+ [Default: ]
+ --verify-node-name Verify worker node name against CN from the TLS
+ certificate. Only has effect when TLS authentication
+ has been enabled.
+ --no-publish Do not publish feature labels
+ --label-whitelist=<pattern> Regular expression to filter label names to
+ publish to the Kubernetes API server.
+ NB: the label namespace is omitted i.e. the filter
+ is only applied to the name part after '/'.
+ [Default: ]
+ --extra-label-ns=<list> Comma separated list of allowed extra label namespaces
+ [Default: ]
+ --resource-labels=<list> Comma separated list of labels to be exposed as extended resources.
+ [Default: ]
+In order to run nfd-worker as a "stand-alone" container against your standalone nfd-master you need to run them in the same network namespace:
$ docker run --rm --network=container:nfd-test ${NFD_CONTAINER_IMAGE} nfd-worker
+2019/02/01 14:48:56 Node Feature Discovery Worker <NFD_VERSION>
+...
+If you just want to try out feature discovery without connecting to nfd-master, pass the --no-publish flag to nfd-worker.
Command line flags of nfd-worker:
$ docker run --rm ${NFD_CONTAINER_IMAGE} nfd-worker --help
+...
+nfd-worker.
+
+ Usage:
+ nfd-worker [--no-publish] [--sources=<sources>] [--label-whitelist=<pattern>]
+ [--oneshot | --sleep-interval=<seconds>] [--config=<path>]
+ [--options=<config>] [--server=<server>] [--server-name-override=<name>]
+ [--ca-file=<path>] [--cert-file=<path>] [--key-file=<path>]
+ nfd-worker -h | --help
+ nfd-worker --version
+
+ Options:
+ -h --help Show this screen.
+ --version Output version and exit.
+ --config=<path> Config file to use.
+ [Default: /etc/kubernetes/node-feature-discovery/nfd-worker.conf]
+ --options=<config> Specify config options from command line. Config
+ options are specified in the same format as in the
+ config file (i.e. json or yaml). These options
+ will override settings read from the config file.
+ [Default: ]
+ --ca-file=<path> Root certificate for verifying connections
+ [Default: ]
+ --cert-file=<path> Certificate used for authenticating connections
+ [Default: ]
+ --key-file=<path> Private key matching --cert-file
+ [Default: ]
+ --server=<server> NFD server address to connecto to.
+ [Default: localhost:8080]
+ --server-name-override=<name> Name (CN) expect from server certificate, useful
+ in testing
+ [Default: ]
+ --sources=<sources> Comma separated list of feature sources.
+ [Default: cpu,custom,iommu,kernel,local,memory,network,pci,storage,system,usb]
+ --no-publish Do not publish discovered features to the
+ cluster-local Kubernetes API server.
+ --label-whitelist=<pattern> Regular expression to filter label names to
+ publish to the Kubernetes API server.
+ NB: the label namespace is omitted i.e. the filter
+ is only applied to the name part after '/'.
+ [Default: ]
+ --oneshot Label once and exit.
+ --sleep-interval=<seconds> Time to sleep between re-labeling. Non-positive
+ value implies no re-labeling (i.e. infinite
+ sleep). [Default: 60s]
+NOTE Some feature sources need certain directories and/or files from the host mounted inside the NFD container. Thus, you need to provide Docker with the correct --volume options in order for them to work correctly when run stand-alone directly with docker run. See the template spec for up-to-date information about the required volume mounts.
All documentation resides under the docs directory in the source tree. It is designed to be served as a html site by GitHub Pages.
Building the documentation is containerized in order to fix the build environment. The recommended way for developing documentation is to run:
make site-serve
+This will build the documentation in a container and serve it under localhost:4000/ making it easy to verify the results. Any changes made to the docs/ will automatically re-trigger a rebuild and are reflected in the served content and can be inspected with a simple browser refresh.
In order to just build the html documentation run:
make site-build
+This will generate html documentation under docs/_site/.
Advanced topics and reference.
To quickly view available command line flags execute nfd-master --help. In a docker container:
docker run gcr.io/k8s-staging-nfd/node-feature-discovery:master nfd-master --help
+Print usage and exit.
Print version and exit.
The --prune flag is a sub-command like option for cleaning up the cluster. It causes nfd-master to remove all NFD related labels, annotations and extended resources from all Node objects of the cluster and exit.
The --port flag specifies the TCP port that nfd-master listens for incoming requests.
Default: 8080
Example:
nfd-master --port=443
+The --ca-file is one of the three flags (together with --cert-file and --key-file) controlling master-worker mutual TLS authentication on the nfd-master side. This flag specifies the TLS root certificate that is used for authenticating incoming connections. NFD-Worker side needs to have matching key and cert files configured in order for the incoming requests to be accepted.
Default: empty
Note: Must be specified together with --cert-file and --key-file
Example:
nfd-master --ca-file=/opt/nfd/ca.crt --cert-file=/opt/nfd/master.crt --key-file=/opt/nfd/master.key
+The --cert-file is one of the three flags (together with --ca-file and --key-file) controlling master-worker mutual TLS authentication on the nfd-master side. This flag specifies the TLS certificate presented for authenticating outgoing traffic towards nfd-worker.
Default: empty
Note: Must be specified together with --ca-file and --key-file
Example:
nfd-master --cert-file=/opt/nfd/master.crt --key-file=/opt/nfd/master.key --ca-file=/opt/nfd/ca.crt
+The --key-file is one of the three flags (together with --ca-file and --cert-file) controlling master-worker mutual TLS authentication on the nfd-master side. This flag specifies the private key corresponding the given certificate file (--cert-file) that is used for authenticating outgoing traffic.
Default: empty
Note: Must be specified together with --cert-file and --ca-file
Example:
nfd-master --key-file=/opt/nfd/master.key --cert-file=/opt/nfd/master.crt --ca-file=/opt/nfd/ca.crt
+The --verify-node-name flag controls the NodeName based authorization of incoming requests and only has effect when mTLS authentication has been enabled (with --ca-file, --cert-file and --key-file). If enabled, the worker node name of the incoming must match with the CN in its TLS certificate. Thus, workers are only able to label the node they are running on (or the node whose certificate they present), and, each worker must have an individual certificate.
Node Name based authorization is disabled by default and thus it is possible for all nfd-worker pods in the cluster to use one shared certificate, making NFD deployment much easier.
Default: false
Example:
nfd-master --verify-node-name --ca-file=/opt/nfd/ca.crt \
+ --cert-file=/opt/nfd/master.crt --key-file=/opt/nfd/master.key
+The --no-publish flag disables all communication with the Kubernetes API server, making a "dry-run" flag for nfd-master. No Labels, Annotations or ExtendedResources (or any other properties of any Kubernetes API objects) are modified.
Default: false
Example:
nfd-master --no-publish
+The --label-whitelist specifies a regular expression for filtering feature labels based on their name. Each label must match against the given reqular expression in order to be published.
Note: The regular expression is only matches against the "basename" part of the label, i.e. to the part of the name after ‘/'. The label namespace is omitted.
Default: empty
Example:
nfd-master --label-whitelist='.*cpuid\.'
+The --extra-label-ns flag specifies a comma-separated list of allowed feature label namespaces. By default, nfd-master only allows creating labels in the default feature.node.kubernetes.io label namespace. This option can be used to allow vendor-specific namespaces for custom labels from the local and custom feature sources.
The same namespace control and this flag applies Extended Resources (created with --resource-labels), too.
Default: empty
Example:
nfd-master --extra-label-ns=vendor-1.com,vendor-2.io
+The --resource-labels flag specifies a comma-separated list of features to be advertised as extended resources instead of labels. Features that have integer values can be published as Extended Resources by listing them in this flag.
Default: empty
Example:
nfd-master --resource-labels=vendor-1.com/feature-1,vendor-2.io/feature-2
+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
+Print usage and exit.
Print version and exit.
The --config flag specifies the path of the nfd-worker configuration file to use.
Default: /etc/kubernetes/node-feature-discovery/nfd-worker.conf
Example:
nfd-worker --config=/opt/nfd/worker.conf
+The --options flag may be used to specify and override configuration file options directly from the command line. The required format is the same as in the config file i.e. JSON or YAML. Configuration options specified via this flag will override those from the configuration file:
Default: empty
Example:
nfd-worker --options='{"sources":{"cpu":{"cpuid":{"attributeWhitelist":["AVX","AVX2"]}}}}'
+The --server flag specifies the address of the nfd-master endpoint where to connect to.
Default: localhost:8080
Example:
nfd-worker --server=nfd-master.nfd.svc.cluster.local:443
+The --ca-file is one of the three flags (together with --cert-file and --key-file) controlling the mutual TLS authentication on the worker side. This flag specifies the TLS root certificate that is used for verifying the authenticity of nfd-master.
Default: empty
Note: Must be specified together with --cert-file and --key-file
Example:
nfd-worker --ca-file=/opt/nfd/ca.crt --cert-file=/opt/nfd/worker.crt --key-file=/opt/nfd/worker.key
+The --cert-file is one of the three flags (together with --ca-file and --key-file) controlling mutual TLS authentication on the worker side. This flag specifies the TLS certificate presented for authenticating outgoing requests.
Default: empty
Note: Must be specified together with --ca-file and --key-file
Example:
nfd-workerr --cert-file=/opt/nfd/worker.crt --key-file=/opt/nfd/worker.key --ca-file=/opt/nfd/ca.crt
+The --key-file is one of the three flags (together with --ca-file and --cert-file) controlling the mutual TLS authentication on the worker side. This flag specifies the private key corresponding the given certificate file (--cert-file) that is used for authenticating outgoing requests.
Default: empty
Note: Must be specified together with --cert-file and --ca-file
Example:
nfd-worker --key-file=/opt/nfd/worker.key --cert-file=/opt/nfd/worker.crt --ca-file=/opt/nfd/ca.crt
+The --server-name-override flag specifies the common name (CN) which to expect from the nfd-master TLS certificate. This flag is mostly intended for development and debugging purposes.
Default: empty
Example:
nfd-worker --server-name-override=localhost
+The --sources flag specifies a comma-separated list of enabled feature sources.
Default: cpu,custom,iommu,kernel,local,memory,network,pci,storage,system,usb
Example:
nfd-worker --sources=kernel,system,local
+The --no-publish flag disables all communication with the nfd-master, making it a "dry-run" flag for nfd-worker. NFD-Worker runs feature detection normally, but no labeling requests are sent to nfd-master.
Default: false
Example:
nfd-worker --no-publish
+The --label-whitelist specifies a regular expression for filtering feature labels based on their name. Each label must match against the given reqular expression in order to be published.
Note: The regular expression is only matches against the "basename" part of the label, i.e. to the part of the name after ‘/'. The label namespace is omitted.
Default: empty
Example:
nfd-worker --label-whitelist='.*cpuid\.'
+The --oneshot flag causes nfd-worker to exit after one pass of feature detection.
Default: false
Example:
nfd-worker --oneshot --no-publish
+The --sleep-interval specifies the interval between feature re-detection (and node re-labeling). A non-positive value implies infinite sleep interval, i.e. no re-detection or re-labeling is done.
Default: 60s
Example:
nfd-worker --sleep-interval=1h
+