Commandline flags of nfd-master

Table of contents

  1. -h, -help
  2. -version
  3. -feature-gates
  4. -prune
  5. -port
  6. -metrics
  7. -instance
  8. -ca-file
  9. -cert-file
  10. -key-file
  11. -verify-node-name
  12. -enable-nodefeature-api
  13. -enable-leader-election
  14. -enable-taints
  15. -no-publish
  16. -crd-controller
  17. -featurerules-controller
  18. -label-whitelist
  19. -extra-label-ns
  20. -deny-label-ns
  21. -resource-labels
  22. -config
  23. -options
  24. -nfd-api-parallelism
  25. Logging
  26. -resync-period

To quickly view available command line flags execute nfd-master -help. In a docker container:

docker run registry.k8s.io/nfd/node-feature-discovery:v0.16.6 nfd-master -help

-h, -help

Print usage and exit.

-version

Print version and exit.

-feature-gates

The -feature-gates flag is used to enable or disable non GA features. The list of available feature gates can be found in the feature gates documentation.

Example:

nfd-master -feature-gates NodeFeatureAPI=false

-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

-ca-file

NOTE the gRPC API is deprecated and will be removed in a future release. and this flag will be removed as well.

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 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

-cert-file

NOTE the gRPC API is deprecated and will be removed in a future release. and this flag will be removed as well.

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

-key-file

NOTE the gRPC API is deprecated and will be removed in a future release. and this flag will be removed as well.

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

-verify-node-name

NOTE the gRPC API is deprecated and will be removed in a future release. and this flag will be removed as well.

The -verify-node-name flag controls the NodeName based authorization of incoming requests and only has effect when mTLS authentication has been enabled (with -ca-file, -cert-file and -key-file). If enabled, the worker node name of the incoming must match with the CN or a SAN in its TLS certificate. Thus, workers are only able to label the node they are running on (or the node whose certificate they present).

Node Name based authorization is disabled by default.

Default: false

Example:

nfd-master -verify-node-name -ca-file=/opt/nfd/ca.crt \
    -cert-file=/opt/nfd/master.crt -key-file=/opt/nfd/master.key

-enable-nodefeature-api

DEPRECATED: will be removed in NFD v0.17. Use' -feature-gates NodeFeatureAPI instead.

NOTE the gRPC API is deprecated and will be removed in a future release.

The -enable-nodefeature-api flag enables/disables the NodeFeature CRD API for receiving feature requests. This will also automatically disable/enable the gRPC interface.

Default: true

Example:

nfd-master -enable-nodefeature-api=false

-enable-leader-election

The -enable-leader-election flag enables leader election for NFD-Master. It is advised to turn on this flag when running more than one instance of NFD-Master.

Does not have effect if the NodeFeatureAPI feature gate is disabled.

Default: false

nfd-master -enable-leader-election

-enable-taints

The -enable-taints flag enables/disables node tainting feature of NFD.

Default: false

Example:

nfd-master -enable-taints=true

-no-publish

The -no-publish flag disables updates to the Node objects in the Kubernetes API server, making a "dry-run" flag for nfd-master. No Labels, Annotations or ExtendedResources of nodes are updated.

Default: false

Example:

nfd-master -no-publish

-crd-controller

NOTE This flag will be removed in a future release at the same time with the deprecated gRPC API.

The -crd-controller flag specifies whether the NFD CRD API controller is enabled or not. The controller is responsible for processing NodeFeature and NodeFeatureRule objects.

Default: true

Example:

nfd-master -crd-controller=false

-featurerules-controller

DEPRECATED: use -crd-controller instead.

-label-whitelist

The -label-whitelist specifies a regular expression for filtering feature labels based on their name. Each label must match against the given regular expression or it will not 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\.'

-extra-label-ns

The -extra-label-ns flag specifies a comma-separated 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 deny-label-ns flag.

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

-deny-label-ns

The -deny-label-ns flag specifies a comma-separated 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. For example, nfd-master -deny-label-ns="" would still disallow kubernetes.io and *.kubernetes.io. 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:

nfd-master -deny-label-ns=*.vendor.com,vendor-2.io

-resource-labels

DEPRECATED: NodeFeatureRule should be used for managing extended resources in NFD.

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

-config

The -config flag specifies the path of the nfd-master configuration file to use.

Default: /etc/kubernetes/node-feature-discovery/nfd-master.conf

Example:

nfd-master -config=/opt/nfd/master.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-master -options='{"noPublish": true}'

-nfd-api-parallelism

The -nfd-api-parallelism flag can be used to specify the maximum number of concurrent node updates.

Does not have effect if the NodeFeatureAPI feature gate is disabled.

Default: 10

Example:

nfd-master -nfd-api-parallelism=1

Logging

The following logging-related flags are inherited from the klog package.

-add_dir_header

If true, adds the file directory to the header of the log messages.

Default: false

-alsologtostderr

Log to standard error as well as files.

Default: false

-log_backtrace_at

When logging hits line file:N, emit a stack trace.

Default: empty

-log_dir

If non-empty, write log files in this directory.

Default: empty

-log_file

If non-empty, use this log file.

Default: empty

-log_file_max_size

Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited.

Default: 1800

-logtostderr

Log to standard error instead of files

Default: true

-skip_headers

If true, avoid header prefixes in the log messages.

Default: false

-skip_log_headers

If true, avoid headers when opening log files.

Default: false

-stderrthreshold

Logs at or above this threshold go to stderr.

Default: 2

-v

Number for the log level verbosity.

Default: 0

-vmodule

Comma-separated list of pattern=N settings for file-filtered logging.

Default: empty

-resync-period

The -resync-period flag specifies the NFD API controller resync period. The resync means nfd-master replaying all NodeFeature and NodeFeatureRule objects, thus effectively re-syncing all nodes in the cluster (i.e. ensuring labels, annotations, extended resources and taints are in place).

Does not have effect if the NodeFeatureAPI feature gate is disabled.

Default: 1 hour.

Example:

nfd-master -resync-period=2h