ab62172a8d
Prior to this feature, NFD consisted of only software components namely nfd-master and nfd-worker. We have introduced another software component called nfd-topology-updater. NFD-Topology-Updater is a daemon responsible for examining allocated resources on a worker node to account for allocatable resources on a per-zone basis (where a zone can be a NUMA node). It then communicates the information to nfd-master which does the CRD creation corresponding to all the nodes in the cluster. One instance of nfd-topology-updater is supposed to be running on each node of the cluster. Signed-off-by: Swati Sehgal <swsehgal@redhat.com>
5.2 KiB
| title | layout | sort |
|---|---|---|
| Quick start | default | 2 |
Quick start
Minimal steps to deploy latest released version of NFD in your cluster.
Installation
Deploy with kustomize -- creates a new namespace, service and required RBAC rules and deploys nfd-master and nfd-worker daemons.
kubectl apply -k https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/default?ref={{ site.release }}
Verify
Wait until NFD master and NFD worker are running.
$ kubectl -n node-feature-discovery get ds,deploy
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/nfd-worker 2 2 2 2 2 <none> 10s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nfd-master 1/1 1 1 17s
Check that NFD feature labels have been created
$ kubectl get no -o json | jq .items[].metadata.labels
{
"beta.kubernetes.io/arch": "amd64",
"beta.kubernetes.io/os": "linux",
"feature.node.kubernetes.io/cpu-cpuid.ADX": "true",
"feature.node.kubernetes.io/cpu-cpuid.AESNI": "true",
"feature.node.kubernetes.io/cpu-cpuid.AVX": "true",
...
Use node labels
Create a pod targeting a distinguishing feature (select a valid feature from the list printed on the previous step)
$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: feature-dependent-pod
spec:
containers:
- image: k8s.gcr.io/pause
name: pause
nodeSelector:
# Select a valid feature
feature.node.kubernetes.io/cpu-cpuid.AESNI: 'true'
EOF
pod/feature-dependent-pod created
See that the pod is running on a desired node
$ kubectl get po feature-dependent-pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
feature-dependent-pod 1/1 Running 0 23s 10.36.0.4 node-2 <none> <none>
Additional Optional Installation Steps
In order to deploy nfd-master and nfd-topology-updater daemons
use topologyupdater overlay.
Deploy with kustomize -- creates a new namespace, service and required RBAC rules and nfd-master and nfd-topology-updater daemons.
kubectl apply -k https://github.com/kubernetes-sigs/node-feature-discovery/deployment/overlays/topologyupdater?ref={{ site.release }}
NOTE:
PodResource API is a prerequisite for nfd-topology-updater.
Preceding Kubernetes v1.23, the kubelet must be started with the following flag:
--feature-gates=KubeletPodResourcesGetAllocatable=true
Starting Kubernetes v1.23, the GetAllocatableResources is enabled by default
through KubeletPodResourcesGetAllocatable feature gate.
Verify
Wait until NFD master and NFD topologyupdater are running.
$ kubectl -n node-feature-discovery get ds,deploy
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/nfd-topology-updater 2 2 2 2 2 <none> 5s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nfd-master 1/1 1 1 17s
Check that the NodeResourceTopology CR instances are created
$ kubectl get noderesourcetopologies.topology.node.k8s.io
NAME AGE
kind-control-plane 23s
kind-worker 23s
Show the CR instances
$ kubectl describe noderesourcetopologies.topology.node.k8s.io kind-control-plane
Name: kind-control-plane
Namespace: default
Labels: <none>
Annotations: <none>
API Version: topology.node.k8s.io/v1alpha1
Kind: NodeResourceTopology
...
Topology Policies:
SingleNUMANodeContainerLevel
Zones:
Name: node-0
Costs:
node-0: 10
node-1: 20
Resources:
Name: Cpu
Allocatable: 3
Capacity: 3
Available: 3
Name: vendor/nic1
Allocatable: 2
Capacity: 2
Available: 2
Name: vendor/nic2
Allocatable: 2
Capacity: 2
Available: 2
Type: Node
Name: node-1
Costs:
node-0: 20
node-1: 10
Resources:
Name: Cpu
Allocatable: 4
Capacity: 4
Available: 4
Name: vendor/nic1
Allocatable: 2
Capacity: 2
Available: 2
Name: vendor/nic2
Allocatable: 2
Capacity: 2
Available: 2
Type: Node
Events: <none>
The CR instances created can be used to gain insight into the allocatable resources along with the granularity of those resources at a per-zone level (represented by node-0 and node-1 in the above example) or can be used by an external entity (e.g. topology-aware scheduler plugin) to take an action based on the gathered information.