Detect of the Intel SST-BF (Speed Select Technology - Base Frequency)
has been enabled.
Adds one new feature label:
feature.node.kubernetes.io/cpu-power.sst_bf.enabled=true
Based on a patch from kuralamudhan.ramakrishnan@intel.com
Make NodeName based authorization of the workers optional (off by
default). This makes it possible for all nfd-worker pods in the cluster
to use one shared secret, making NFD deployment much easier. However,
this also opens a way for nfd-workers to label other nodes (than what it
is running on), too.
Command line option for overriding the Common Name (CN) expected from
the nfd-master TLS certificate. This can be especially handy in
testing/development.
Implement TLS client certificate authentication. It is enabled by
specifying --ca-file, --key-file and --cert-file, on both the nfd-master
and nfd-worker side. When enabled, nfd-master verifies that the client
(worker) presents a valid certificate signed by the root certificate
(--ca-file). In addition, nfd-master does authorization based on the Common Name
(CN) of the client certificate: CN must match the node name specified in
the labeling request. This ensures (assuming that the worker
certificates are correctly deployed) that nfd-worker is only able to label
the node it is running on, i.e. prevents it from labeling other nodes.
Add support for TLS authentication. When enabled, nfd-worker verifies
that nfd-master has a valid certificate, i.e. signed by the given root
certificate and its Common Name (CN) matches the DNS name of the
nfd-master service being used. TLS authentication is enabled by
specifying --key-file and --cert-file on nfd-master, and, --ca-file on
nfd-worker.
Refactor NFD into a simple server-client system. Labeling is now done by
a separate 'nfd-master' server. It is a simple service with small
codebase, designed for easy isolation. The feature discovery part is
implemented in a 'nfd-worker' client which sends labeling requests to
nfd-server, thus, requiring no access/permissions to the Kubernetes API
itself.
Client-server communication is implemented by using gRPC. The protocol
currently consists of only one request, i.e. the labeling request.
The spec templates are converted to the new scheme. The nfd-master
server can be deployed using the nfd-master.yaml.template which now also
contains the necessary RBAC configuration. NFD workers can be deployed
by using the nfd-worker-daemonset.yaml.template or
nfd-worker-job.yaml.template (most easily used with the label-nodes.sh
script).
Only nfd-worker currently support config file or options. The (default)
NFD config file is renamed to nfd-worker.conf.
Glide is not actively developed anymore, and, its documentation
recommends migrating to dep. Also, dep is widely used in other k8s
projects.
Migrating to dep dramatically reduces the size of the populated vendor/
directory from 75MB down to about 20MB.
Add a new Makefile target for regenerating these files. Also, add a
note that the files are auto-generated, including instructions how to
re-generate them.
Renames the mock files, using the defaults provided by the mockery tool,
in order to make their generation easier.
The aim here is to add another way to specify labels using the local
source by reading files in a specific directory. That avoids us to
execute a hook when we just need to get the content of a file.
See https://github.com/kubernetes-sigs/node-feature-discovery/issues/226
Signed-off-by: Jordan Jacobelli <jjacobelli@nvidia.com>
Get rid of the dependency on intel-cmt-cat library and rdt helper
binaries written in C. Significantly simplifies the build procedure.
Implements minimal support (in assembler) for getting the raw data from
the CPUID instruction. Also, implement a stub so that the code works on
other architectures than amd64, too.
Discover other than bool or tristate kconfig options, too. For bool and
tristate the node label is still binary (i.e. set to "true" if the
kconfig option has been enabled). For other kconfig types (e.g. string
or int) the value of the label directly corresponds to the value of the
kconfig flag, e.g. "32", "elf64-x86-64" etc.
Add two new attributes 'VERSION_ID.major' and 'VERSION_ID.minor' to the
os_release feature. These represent the first two components of
the OS version (version components are assumed to be separated by a
dot). E.g. if VERSION_ID would be 1.2.rc3 major and minor versions would
be 1 and 2, respectively:
feature.node.kubernetes.io/system-os_release.VERSION_ID=1.2.rc3
feature.node.kubernetes.io/system-os_release.VERSION_ID.major=1
feature.node.kubernetes.io/system-os_release.VERSION_ID.minor=2
The version components must be purely numerical in order for them to be
advertised. This way they can be fully (and reliably) utilized in
nodeAffinity, including relative (Gt and Lt) operators.
Remove the 'selinux' feature source and move the functionality under the
'kernel' feature source. The selinux feature label is changed to
feature.node.kubernetes.io/selinux.enabled
The selinux feature source was rather narrow in scope, and, the sole
feature it advertised naturally falls under the kernel feature source.
Currently, it only detects one feature, i.e. hardware multithreading
(such as Intel hyper-threading technology). The corresponding feature
label is:
feature.node.kubernetes.io/cpu-hardware_multithreading=true
However, this (architecture/platform dependent) feature is not detected
directly, and, the heuristics can be mislead. Detection works by
checking the thread siblings of each logical (and online) cpu in the
system. If any cpu has any thread siblings the feature label is set to
true. Thus, hardware multithreading could be effectively disabled e.g.
by putting all sibling cpus offline (even if the technology would be
enabled in hardware).
Implement new 'system' feature source. It now detects OS release
information from the os-release file, assumed to be available at
/host-etc/os-release. It currently creates two labels (assuming that the
corresponding fields are found in the os-release file), with example
values:
feature.node.kubernetes.io/system-os_release.ID=opensuse
feature.node.kubernetes.io/system-os_release.VERSION_ID=42.3
Also, update the template spec to mount /etc/os-release file from the
host inside the container.
Change links in README.md and RELEASE.md to point to the new repo
location under kubernetes-sigs. Also, remove some outdated references to
kubernetes incubator project.
