mirrors/node-feature-discovery
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/node-feature-discovery.git synced 2024-12-14 11:57:51 +00:00
Code Activity
node-feature-discovery/nfd-worker-daemonset.yaml.template

50 lines
1.2 KiB
Text
Raw Normal View History

Convert templates and examples from json to yaml (#108) 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.
2018-09-27 11:54:45 +00:00
apiVersion: apps/v1
kind: DaemonSet
metadata:
labels:
Split NFD into client and server 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.
2019-01-11 13:55:28 +00:00
app: nfd-worker
name: nfd-worker
Convert templates and examples from json to yaml (#108) 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.
2018-09-27 11:54:45 +00:00
spec:
selector:
matchLabels:
Split NFD into client and server 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.
2019-01-11 13:55:28 +00:00
app: nfd-worker
Convert templates and examples from json to yaml (#108) 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.
2018-09-27 11:54:45 +00:00
template:
metadata:
labels:
Split NFD into client and server 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.
2019-01-11 13:55:28 +00:00
app: nfd-worker
Convert templates and examples from json to yaml (#108) 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.
2018-09-27 11:54:45 +00:00
spec:
hostNetwork: true
Implement TLS server authentication 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.
2019-01-29 14:21:48 +00:00
dnsPolicy: ClusterFirstWithHostNet
Convert templates and examples from json to yaml (#108) 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.
2018-09-27 11:54:45 +00:00
containers:
- env:
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
image: quay.io/kubernetes_incubator/node-feature-discovery:v0.3.0
Split NFD into client and server 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.
2019-01-11 13:55:28 +00:00
name: nfd-worker
command:
- "nfd-worker"
Convert templates and examples from json to yaml (#108) 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.
2018-09-27 11:54:45 +00:00
args:
- "--sleep-interval=60s"
Implement TLS server authentication 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.
2019-01-29 14:21:48 +00:00
- "--server=nfd-master:8080"
Convert templates and examples from json to yaml (#108) 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.
2018-09-27 11:54:45 +00:00
volumeMounts:
Implement kernel config detection This implementation only detects kconfig options ("NO_HZ", "NO_HZ_IDLE", "NO_HZ_FULL" and "PREEMPT"). The corresponding node labels will be node.alpha.kubernetes-incubator.io/nfd-kernel-config.<option name> Currently, only bool and tristate (i.e. '=y' or '=m') kernel config options are supported. Other kconfig types (e.g. string or int) are simply ignored. If the kconfig flag is set to '=y' or '=m', the corresponding node label will be present and it's value will be 'true'.
2018-07-05 13:29:38 +00:00
- name: host-boot
mountPath: "/host-boot"
readOnly: true
Implement OS release detection 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.
2018-07-10 09:00:02 +00:00
- name: host-os-release
mountPath: "/host-etc/os-release"
readOnly: true
Convert templates and examples from json to yaml (#108) 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.
2018-09-27 11:54:45 +00:00
- name: host-sys
mountPath: "/host-sys"
volumes:
Implement kernel config detection This implementation only detects kconfig options ("NO_HZ", "NO_HZ_IDLE", "NO_HZ_FULL" and "PREEMPT"). The corresponding node labels will be node.alpha.kubernetes-incubator.io/nfd-kernel-config.<option name> Currently, only bool and tristate (i.e. '=y' or '=m') kernel config options are supported. Other kconfig types (e.g. string or int) are simply ignored. If the kconfig flag is set to '=y' or '=m', the corresponding node label will be present and it's value will be 'true'.
2018-07-05 13:29:38 +00:00
- name: host-boot
hostPath:
path: "/boot"
Implement OS release detection 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.
2018-07-10 09:00:02 +00:00
- name: host-os-release
hostPath:
path: "/etc/os-release"
Convert templates and examples from json to yaml (#108) 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.
2018-09-27 11:54:45 +00:00
- name: host-sys
hostPath:
path: "/sys"
Copy permalink