apiVersion: v1
kind: Namespace
metadata:
name: openshift-nfd
labels:
name: openshift-nfd
openshift.io/cluster-monitoring: "true"
了解节点功能发现 (NFD) 运算符以及如何使用它通过编排节点功能发现(一种用于检测硬件功能和系统配置的 Kubernetes 附加组件)来公开节点级信息。
节点功能发现运算符 (NFD) 通过使用特定于硬件的信息标记节点来管理 OpenShift Container Platform 集群中硬件功能和配置的检测。NFD 使用节点特定的属性(例如 PCI 卡、内核、操作系统版本等)标记主机。
通过搜索“节点功能发现”可以在 Operator Hub 中找到 NFD 运算符。
节点功能发现 (NFD) 运算符编排运行 NFD 守护程序集所需的所有资源。作为集群管理员,您可以使用 OpenShift Container Platform CLI 或 Web 控制台安装 NFD 运算符。
作为集群管理员,您可以使用 CLI 安装 NFD 运算符。
一个 OpenShift Container Platform 集群
安装 OpenShift CLI (oc
)。
以具有 cluster-admin
权限的用户身份登录。
为 NFD 运算符创建一个命名空间。
创建以下 `Namespace` 自定义资源 (CR),该资源定义 `openshift-nfd` 命名空间,然后将 YAML 保存到 `nfd-namespace.yaml` 文件中。将 `cluster-monitoring` 设置为 `"true"`。
apiVersion: v1
kind: Namespace
metadata:
name: openshift-nfd
labels:
name: openshift-nfd
openshift.io/cluster-monitoring: "true"
运行以下命令创建命名空间
$ oc create -f nfd-namespace.yaml
通过创建以下对象,在您在上一步中创建的命名空间中安装 NFD 运算符
创建以下 `OperatorGroup` CR 并将 YAML 保存到 `nfd-operatorgroup.yaml` 文件中
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
generateName: openshift-nfd-
name: openshift-nfd
namespace: openshift-nfd
spec:
targetNamespaces:
- openshift-nfd
运行以下命令创建 `OperatorGroup` CR
$ oc create -f nfd-operatorgroup.yaml
创建以下 `Subscription` CR 并将 YAML 保存到 `nfd-sub.yaml` 文件中
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: nfd
namespace: openshift-nfd
spec:
channel: "stable"
installPlanApproval: Automatic
name: nfd
source: redhat-operators
sourceNamespace: openshift-marketplace
运行以下命令创建订阅对象
$ oc create -f nfd-sub.yaml
切换到openshift-nfd
项目
$ oc project openshift-nfd
要验证 Operator 部署是否成功,请运行
$ oc get pods
NAME READY STATUS RESTARTS AGE
nfd-controller-manager-7f86ccfb58-vgr4x 2/2 Running 0 10m
成功的部署将显示运行中
状态。
作为集群管理员,您可以使用 Web 控制台安装 NFD Operator。
在 OpenShift Container Platform Web 控制台中,点击Operators → OperatorHub。
从可用 Operator 列表中选择节点功能发现,然后点击安装。
在安装 Operator页面上,选择集群上的特定命名空间,然后点击安装。您无需创建命名空间,因为它会为您自动创建。
验证 NFD Operator 是否成功安装
导航到Operators → 已安装的 Operators页面。
确保节点功能发现列在openshift-nfd
项目中,且状态为InstallSucceeded。
在安装过程中,Operator 可能会显示失败状态。如果安装稍后成功并显示InstallSucceeded消息,则可以忽略失败消息。 |
如果 Operator 未显示为已安装,请进一步进行故障排除
导航到Operators → 已安装的 Operators页面,并检查Operator 订阅和安装计划选项卡中状态下的任何失败或错误。
导航到工作负载 → Pod页面,并检查openshift-nfd
项目中 Pod 的日志。
节点功能发现 (NFD) Operator 通过监视NodeFeatureDiscovery
自定义资源 (CR) 来协调运行节点功能发现守护程序集所需的所有资源。根据NodeFeatureDiscovery
CR,Operator 在选定的命名空间中创建操作数 (NFD) 组件。您可以编辑 CR 以使用其他命名空间、镜像、镜像拉取策略和nfd-worker-conf
配置映射等选项。
作为集群管理员,您可以使用 OpenShift CLI (oc
) 或 Web 控制台创建NodeFeatureDiscovery
CR。
从 4.12 版本开始, |
作为集群管理员,您可以使用 OpenShift CLI (oc
) 创建NodeFeatureDiscovery
CR 实例。
|
以下示例显示了使用-rhel9
获取正确镜像的方法。
您可以访问 OpenShift Container Platform 集群
您已安装 OpenShift CLI (oc
)。
您已以具有cluster-admin
权限的用户身份登录。
您已安装 NFD Operator。
创建NodeFeatureDiscovery
CR
NodeFeatureDiscovery
CR 示例apiVersion: nfd.openshift.io/v1
kind: NodeFeatureDiscovery
metadata:
name: nfd-instance
namespace: openshift-nfd
spec:
instance: "" # instance is empty by default
topologyupdater: false # False by default
operand:
image: registry.redhat.io/openshift4/ose-node-feature-discovery-rhel9:v4.17 (1)
imagePullPolicy: Always
workerConfig:
configData: |
core:
# labelWhiteList:
# noPublish: false
sleepInterval: 60s
# sources: [all]
# klog:
# addDirHeader: false
# alsologtostderr: false
# logBacktraceAt:
# logtostderr: true
# skipHeaders: false
# stderrthreshold: 2
# v: 0
# vmodule:
## NOTE: the following options are not dynamically run-time configurable
## and require a nfd-worker restart to take effect after being changed
# logDir:
# logFile:
# logFileMaxSize: 1800
# skipLogHeaders: false
sources:
cpu:
cpuid:
# NOTE: whitelist has priority over blacklist
attributeBlacklist:
- "BMI1"
- "BMI2"
- "CLMUL"
- "CMOV"
- "CX16"
- "ERMS"
- "F16C"
- "HTT"
- "LZCNT"
- "MMX"
- "MMXEXT"
- "NX"
- "POPCNT"
- "RDRAND"
- "RDSEED"
- "RDTSCP"
- "SGX"
- "SSE"
- "SSE2"
- "SSE3"
- "SSE4.1"
- "SSE4.2"
- "SSSE3"
attributeWhitelist:
kernel:
kconfigFile: "/path/to/kconfig"
configOpts:
- "NO_HZ"
- "X86"
- "DMI"
pci:
deviceClassWhitelist:
- "0200"
- "03"
- "12"
deviceLabelFields:
- "class"
customConfig:
configData: |
- name: "more.kernel.features"
matchOn:
- loadedKMod: ["example_kmod3"]
1 | operand.image 字段是必需的。 |
运行以下命令创建NodeFeatureDiscovery
CR
$ oc apply -f <filename>
运行以下命令检查NodeFeatureDiscovery
CR 是否已创建
$ oc get pods
NAME READY STATUS RESTARTS AGE
nfd-controller-manager-7f86ccfb58-vgr4x 2/2 Running 0 11m
nfd-master-hcn64 1/1 Running 0 60s
nfd-master-lnnxx 1/1 Running 0 60s
nfd-master-mp6hr 1/1 Running 0 60s
nfd-worker-vgcz9 1/1 Running 0 60s
nfd-worker-xqbws 1/1 Running 0 60s
成功的部署将显示运行中
状态。
作为集群管理员,您可以使用 OpenShift CLI (oc
) 创建NodeFeatureDiscovery
CR 实例。
您可以访问 OpenShift Container Platform 集群
您已安装 OpenShift CLI (oc
)。
您已以具有cluster-admin
权限的用户身份登录。
您已安装 NFD Operator。
您可以访问包含所需镜像的镜像仓库。
您已安装skopeo
CLI 工具。
确定镜像仓库镜像的摘要
运行以下命令
$ skopeo inspect docker://registry.redhat.io/openshift4/ose-node-feature-discovery:<openshift_version>
$ skopeo inspect docker://registry.redhat.io/openshift4/ose-node-feature-discovery:v4.12
检查输出以识别镜像摘要
{
...
"Digest": "sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
...
}
使用skopeo
CLI 工具将镜像从registry.redhat.io
复制到您的镜像仓库,运行以下命令:
skopeo copy docker://registry.redhat.io/openshift4/ose-node-feature-discovery@<image_digest> docker://<mirror_registry>/openshift4/ose-node-feature-discovery@<image_digest>
skopeo copy docker://registry.redhat.io/openshift4/ose-node-feature-discovery@sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef docker://<your-mirror-registry>/openshift4/ose-node-feature-discovery@sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
创建NodeFeatureDiscovery
CR
NodeFeatureDiscovery
CR 示例apiVersion: nfd.openshift.io/v1
kind: NodeFeatureDiscovery
metadata:
name: nfd-instance
spec:
operand:
image: <mirror_registry>/openshift4/ose-node-feature-discovery@<image_digest> (1)
imagePullPolicy: Always
workerConfig:
configData: |
core:
# labelWhiteList:
# noPublish: false
sleepInterval: 60s
# sources: [all]
# klog:
# addDirHeader: false
# alsologtostderr: false
# logBacktraceAt:
# logtostderr: true
# skipHeaders: false
# stderrthreshold: 2
# v: 0
# vmodule:
## NOTE: the following options are not dynamically run-time configurable
## and require a nfd-worker restart to take effect after being changed
# logDir:
# logFile:
# logFileMaxSize: 1800
# skipLogHeaders: false
sources:
cpu:
cpuid:
# NOTE: whitelist has priority over blacklist
attributeBlacklist:
- "BMI1"
- "BMI2"
- "CLMUL"
- "CMOV"
- "CX16"
- "ERMS"
- "F16C"
- "HTT"
- "LZCNT"
- "MMX"
- "MMXEXT"
- "NX"
- "POPCNT"
- "RDRAND"
- "RDSEED"
- "RDTSCP"
- "SGX"
- "SSE"
- "SSE2"
- "SSE3"
- "SSE4.1"
- "SSE4.2"
- "SSSE3"
attributeWhitelist:
kernel:
kconfigFile: "/path/to/kconfig"
configOpts:
- "NO_HZ"
- "X86"
- "DMI"
pci:
deviceClassWhitelist:
- "0200"
- "03"
- "12"
deviceLabelFields:
- "class"
customConfig:
configData: |
- name: "more.kernel.features"
matchOn:
- loadedKMod: ["example_kmod3"]
1 | operand.image 字段是必需的。 |
运行以下命令创建NodeFeatureDiscovery
CR
$ oc apply -f <filename>
运行以下命令检查NodeFeatureDiscovery
CR 的状态
$ oc get nodefeaturediscovery nfd-instance -o yaml
运行以下命令检查 Pod 是否在没有ImagePullBackOff
错误的情况下运行
$ oc get pods -n <nfd_namespace>
作为集群管理员,您可以使用 OpenShift Container Platform Web 控制台创建NodeFeatureDiscovery
CR。
您可以访问 OpenShift Container Platform 集群
您已以具有cluster-admin
权限的用户身份登录。
您已安装 NFD Operator。
导航到Operators → 已安装的 Operators页面。
在节点功能发现部分的提供的 API下,点击创建实例。
编辑NodeFeatureDiscovery
CR 的值。
点击创建。
从 4.12 版本开始, |
core
部分包含一些通用的配置设置,这些设置不是特定于任何特定功能源的。
core.sleepInterval
指定连续功能检测或重新检测过程之间的间隔,也因此指定节点重新标记之间的间隔。非正值表示无限睡眠间隔;不执行重新检测或重新标记。
如果指定了已弃用的--sleep-interval
命令行标志,则此值将被覆盖。
core:
sleepInterval: 60s (1)
默认值为60s
。
core.sources
指定已启用功能源的列表。特殊值all
启用所有功能源。
如果指定了已弃用的--sources
命令行标志,则此值将被覆盖。
默认值:[all]
core:
sources:
- system
- custom
core.labelWhiteList
指定用于根据标签名称过滤功能标签的正则表达式。不匹配的标签不会发布。
正则表达式仅与标签的基本名称部分匹配,即名称中'/'之后的部分。标签前缀或命名空间被省略。
如果指定了已弃用的--label-whitelist
命令行标志,则此值将被覆盖。
默认值:null
core:
labelWhiteList: '^cpu-cpuid'
将core.noPublish
设置为true
将禁用与nfd-master
的所有通信。它实际上是一个试运行标志;nfd-worker
正常运行功能检测,但不会向nfd-master
发送任何标记请求。
如果指定了--no-publish
命令行标志,则此值将被覆盖。
示例
core:
noPublish: true (1)
默认值为false
。
以下选项指定日志记录器配置,其中大部分可以在运行时动态调整。
日志记录器选项也可以使用命令行标志指定,命令行标志优先于任何对应的配置文件选项。
如果设置为true
,core.klog.addDirHeader
会将文件目录添加到日志消息的头部。
默认值:false
运行时可配置:是
同时向标准错误和文件记录日志。
默认值:false
运行时可配置:是
当日志记录命中文件line:N时,发出堆栈跟踪。
默认值:空
运行时可配置:是
如果非空,则在此目录中写入日志文件。
默认值:空
运行时可配置:否
如果非空,则使用此日志文件。
默认值:空
运行时可配置:否
core.klog.logFileMaxSize
定义日志文件可以增长到的最大大小。单位为兆字节。如果值为0
,则最大文件大小不限。
默认值:1800
运行时可配置:否
将日志记录到标准错误而不是文件。
默认值:true
运行时可配置:是
如果将core.klog.skipHeaders
设置为true
,则避免在日志消息中使用头部前缀。
默认值:false
运行时可配置:是
如果将core.klog.skipLogHeaders
设置为true
,则在打开日志文件时避免使用头部。
默认值:false
运行时可配置:否
等于或高于此阈值的日志将发送到 stderr。
默认值:2
运行时可配置:是
core.klog.v
是日志级别详细程度的数字。
默认值:0
运行时可配置:是
core.klog.vmodule
是一个逗号分隔的pattern=N
设置列表,用于按文件过滤日志记录。
默认值:空
运行时可配置:是
sources
部分包含特定于功能源的配置参数。
阻止发布此选项中列出的cpuid
功能。
如果指定,此值将被sources.cpu.cpuid.attributeWhitelist
覆盖。
默认值:[BMI1, BMI2, CLMUL, CMOV, CX16, ERMS, F16C, HTT, LZCNT, MMX, MMXEXT, NX, POPCNT, RDRAND, RDSEED, RDTSCP, SGX, SGXLC, SSE, SSE2, SSE3, SSE4.1, SSE4.2, SSSE3]
sources:
cpu:
cpuid:
attributeBlacklist: [MMX, MMXEXT]
仅发布此选项中列出的cpuid
功能。
sources.cpu.cpuid.attributeWhitelist
优先于sources.cpu.cpuid.attributeBlacklist
。
默认值:空
sources:
cpu:
cpuid:
attributeWhitelist: [AVX512BW, AVX512CD, AVX512DQ, AVX512F, AVX512VL]
sources.kernel.kconfigFile
是内核配置文件的路径。如果为空,NFD 将在众所周知的标准位置进行搜索。
默认值:空
sources:
kernel:
kconfigFile: "/path/to/kconfig"
sources.kernel.configOpts
表示要作为功能标签发布的内核配置选项。
默认值:[NO_HZ, NO_HZ_IDLE, NO_HZ_FULL, PREEMPT]
sources:
kernel:
configOpts: [NO_HZ, X86, DMI]
sources.pci.deviceClassWhitelist
是要为其发布标签的PCI 设备类 ID 列表。它可以仅指定为主类(例如,03
)或完整的类-子类组合(例如 0300
)。前者意味着接受所有子类。标签的格式可以使用deviceLabelFields
进一步配置。
默认值:["03", "0b40", "12"]
sources:
pci:
deviceClassWhitelist: ["0200", "03"]
sources.pci.deviceLabelFields
是构造功能标签名称时要使用的 PCI ID 字段集。有效字段为class
、vendor
、device
、subsystem_vendor
和subsystem_device
。
默认值:[class, vendor]
sources:
pci:
deviceLabelFields: [class, vendor, device]
使用上面的示例配置,NFD 将发布诸如feature.node.kubernetes.io/pci-<class-id>_<vendor-id>_<device-id>.present=true
之类的标签
sources.usb.deviceClassWhitelist
是要为其发布功能标签的 USB 设备类 ID 列表。标签的格式可以使用deviceLabelFields
进一步配置。
默认值:["0e", "ef", "fe", "ff"]
sources:
usb:
deviceClassWhitelist: ["ef", "ff"]
sources.usb.deviceLabelFields
是用于组合功能标签名称的 USB ID 字段集。有效字段为class
、vendor
和device
。
默认值:[class, vendor, device]
sources:
pci:
deviceLabelFields: [class, vendor]
使用上面的示例配置,NFD 将发布类似于:feature.node.kubernetes.io/usb-<class-id>_<vendor-id>.present=true
的标签。
sources.custom
是要在自定义功能源中处理的规则列表,以创建用户特定的标签。
默认值:空
source:
custom:
- name: "my.custom.feature"
matchOn:
- loadedKMod: ["e1000e"]
- pciId:
class: ["0200"]
vendor: ["8086"]
NodeFeatureRule
对象是用于基于规则的节点自定义标签的NodeFeatureDiscovery
自定义资源。一些用例包括特定于应用程序的标签或硬件供应商的分布,以创建其设备的特定标签。
NodeFeatureRule
对象提供了一种方法来创建特定于供应商或应用程序的标签和污点。它使用灵活的基于规则的机制来创建标签,并根据节点功能可选地创建污点。
如果一组规则与条件匹配,则创建NodeFeatureRule
对象来标记节点。
创建一个名为nodefeaturerule.yaml
的自定义资源文件,其中包含以下文本
apiVersion: nfd.openshift.io/v1
kind: NodeFeatureRule
metadata:
name: example-rule
spec:
rules:
- name: "example rule"
labels:
"example-custom-feature": "true"
# Label is created if all of the rules below match
matchFeatures:
# Match if "veth" kernel module is loaded
- feature: kernel.loadedmodule
matchExpressions:
veth: {op: Exists}
# Match if any PCI device with vendor 8086 exists in the system
- feature: pci.device
matchExpressions:
vendor: {op: In, value: ["8086"]}
此自定义资源指定当加载veth
模块并且集群中存在任何具有供应商代码8086
的 PCI 设备时发生标签。
通过运行以下命令将nodefeaturerule.yaml
文件应用于您的集群
$ oc apply -f https://raw.githubusercontent.com/kubernetes-sigs/node-feature-discovery/v0.13.6/examples/nodefeaturerule.yaml
此示例将功能标签应用于加载了veth
模块并且存在任何具有供应商代码8086
的 PCI 设备的节点。
可能会发生长达 1 分钟的重新标记延迟。 |
节点功能发现 (NFD) 拓扑更新程序是一个守护程序,负责检查工作节点上的已分配资源。它考虑了可按区域分配给新 Pod 的资源,其中区域可以是非统一内存访问 (NUMA) 节点。NFD 拓扑更新程序将信息传达给 nfd-master,nfd-master 创建一个与集群中所有工作节点对应的NodeResourceTopology
自定义资源 (CR)。集群的每个节点上都运行一个 NFD 拓扑更新程序实例。
要在 NFD 中启用拓扑更新程序工作程序,请在NodeFeatureDiscovery
CR 中将topologyupdater
变量设置为true
,如使用节点功能发现运算符部分所述。
使用 NFD 拓扑更新程序运行时,NFD 会创建与节点资源硬件拓扑对应的自定义资源实例,例如
apiVersion: topology.node.k8s.io/v1alpha1
kind: NodeResourceTopology
metadata:
name: node1
topologyPolicies: ["SingleNUMANodeContainerLevel"]
zones:
- name: node-0
type: Node
resources:
- name: cpu
capacity: 20
allocatable: 16
available: 10
- name: vendor/nic1
capacity: 3
allocatable: 3
available: 3
- name: node-1
type: Node
resources:
- name: cpu
capacity: 30
allocatable: 30
available: 15
- name: vendor/nic2
capacity: 6
allocatable: 6
available: 6
- name: node-2
type: Node
resources:
- name: cpu
capacity: 30
allocatable: 30
available: 15
- name: vendor/nic1
capacity: 3
allocatable: 3
available: 3
要查看可用的命令行标志,请运行nfd-topology-updater -help
命令。例如,在podman容器中,运行以下命令:
$ podman run gcr.io/k8s-staging-nfd/node-feature-discovery:master nfd-topology-updater -help
-ca-file
标志与-cert-file
和-key-file
标志一起,是控制NFD拓扑更新程序上相互TLS身份验证的三个标志之一。此标志指定用于验证nfd-master真实性的TLS根证书。
默认值:空
必须与 |
$ nfd-topology-updater -ca-file=/opt/nfd/ca.crt -cert-file=/opt/nfd/updater.crt -key-file=/opt/nfd/updater.key
-cert-file
标志与-ca-file
和-key-file
标志一起,是控制NFD拓扑更新程序上相互TLS身份验证的三个标志之一。此标志指定用于验证外发请求的TLS证书。
默认值:空
必须与 |
$ nfd-topology-updater -cert-file=/opt/nfd/updater.crt -key-file=/opt/nfd/updater.key -ca-file=/opt/nfd/ca.crt
打印用法并退出。
-key-file
标志与-ca-file
和-cert-file
标志一起,是控制NFD拓扑更新程序上相互TLS身份验证的三个标志之一。此标志指定与给定证书文件(或-cert-file
)相对应的私钥,用于验证外发请求。
默认值:空
必须与 |
$ nfd-topology-updater -key-file=/opt/nfd/updater.key -cert-file=/opt/nfd/updater.crt -ca-file=/opt/nfd/ca.crt
-kubelet-config-file
指定Kubelet配置文件的路径。
默认值:/host-var/lib/kubelet/config.yaml
$ nfd-topology-updater -kubelet-config-file=/var/lib/kubelet/config.yaml
-no-publish
标志禁用与nfd-master的所有通信,使其成为nfd-topology-updater的干运行标志。NFD拓扑更新程序正常运行资源硬件拓扑检测,但不向nfd-master发送CR请求。
默认值:false
$ nfd-topology-updater -no-publish
-oneshot
标志导致NFD拓扑更新程序在完成一次资源硬件拓扑检测后退出。
默认值:false
$ nfd-topology-updater -oneshot -no-publish
-podresources-socket
标志指定Unix套接字的路径,Kubelet通过该套接字导出gRPC服务,以启用正在使用的CPU和设备的发现,并为其提供元数据。
默认值:/host-var/liblib/kubelet/pod-resources/kubelet.sock
(注意:原文此处可能存在笔误,建议检查实际默认路径)
$ nfd-topology-updater -podresources-socket=/var/lib/kubelet/pod-resources/kubelet.sock
-server
标志指定要连接到的nfd-master端点的地址。
默认值:localhost:8080
$ nfd-topology-updater -server=nfd-master.nfd.svc.cluster.local:443
-server-name-override
标志指定要从nfd-master TLS证书中期望的公用名(CN)。此标志主要用于开发和调试目的。
默认值:空
$ nfd-topology-updater -server-name-override=localhost
-sleep-interval
标志指定资源硬件拓扑重新检查和自定义资源更新之间的间隔。非正值表示无限睡眠间隔,不进行重新检测。
默认值:60s
$ nfd-topology-updater -sleep-interval=1h
打印版本并退出。
-watch-namespace
标志指定命名空间,以确保资源硬件拓扑检查仅针对在指定命名空间中运行的Pod进行。在资源会计过程中,不考虑不在指定命名空间中运行的Pod。这对于测试和调试特别有用。*
值表示在会计过程中考虑所有命名空间中的所有Pod。
默认值:*
$ nfd-topology-updater -watch-namespace=rte