Use pod anti-affinity to explicitly indicate that pods should be
scheduled on separate nodes. And, remove the obscure and non-obvious
ports definition whose only purpose was to reach the same effect.
- Create default yamls for deploying master and worker.
- Use kube-system namespace by default.
- Configurable namespace:
make IMAGE_REGISTRY=myhost:5000 K8S_NAMESPACE=my-nfd-devel
Also, slightly adjust the deployment instructions in README to point out
that the templates should now be usable as is to run the latest released
version of NFD.
Point to the latest release in the README, and, point out that a
user-built custom image is required to run the latest development
version. Update the deployment instructions to reflect the need to
specify the container image when using the deployment spec template(s).
Also, update the Job deployment script to set a user-defined container
image.
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.
Convert resource templates from json to yaml
Yaml is easier and less error prone to modify by hand. It also allows
comments which can be especially useful in the templates.
Counting nodes in Ready state was too fragile, matching
entries like:
Ready,SchedulingDisabled
NotReady
By requiring whitespace on both side, we accept only clean Ready.
A "newbie style" deployment attempt was made on a recent
cluster, and some added notes in README and in label-nodes.sh
could help someone who just started with node-feature-discovery.
Correcting also description of label-nodes.sh which does not
deal with unlabeled nodes as was promised in README.