×

了解节点功能发现 (NFD) 运算符以及如何使用它通过编排节点功能发现(一种用于检测硬件功能和系统配置的 Kubernetes 附加组件)来公开节点级信息。

节点功能发现运算符 (NFD) 通过使用特定于硬件的信息标记节点来管理 OpenShift Container Platform 集群中硬件功能和配置的检测。NFD 使用节点特定的属性(例如 PCI 卡、内核、操作系统版本等)标记主机。

通过搜索“节点功能发现”可以在 Operator Hub 中找到 NFD 运算符。

安装节点功能发现运算符

节点功能发现 (NFD) 运算符编排运行 NFD 守护程序集所需的所有资源。作为集群管理员,您可以使用 OpenShift Container Platform CLI 或 Web 控制台安装 NFD 运算符。

使用 CLI 安装 NFD 运算符

作为集群管理员,您可以使用 CLI 安装 NFD 运算符。

先决条件
  • 一个 OpenShift Container Platform 集群

  • 安装 OpenShift CLI (oc)。

  • 以具有 cluster-admin 权限的用户身份登录。

步骤
  1. 为 NFD 运算符创建一个命名空间。

    1. 创建以下 `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"
    2. 运行以下命令创建命名空间

      $ oc create -f nfd-namespace.yaml
  2. 通过创建以下对象,在您在上一步中创建的命名空间中安装 NFD 运算符

    1. 创建以下 `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
    2. 运行以下命令创建 `OperatorGroup` CR

      $ oc create -f nfd-operatorgroup.yaml
    3. 创建以下 `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
    4. 运行以下命令创建订阅对象

      $ oc create -f nfd-sub.yaml
    5. 切换到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

作为集群管理员,您可以使用 Web 控制台安装 NFD Operator。

步骤
  1. 在 OpenShift Container Platform Web 控制台中,点击OperatorsOperatorHub

  2. 从可用 Operator 列表中选择节点功能发现,然后点击安装

  3. 安装 Operator页面上,选择集群上的特定命名空间,然后点击安装。您无需创建命名空间,因为它会为您自动创建。

验证

验证 NFD Operator 是否成功安装

  1. 导航到Operators已安装的 Operators页面。

  2. 确保节点功能发现列在openshift-nfd项目中,且状态InstallSucceeded

    在安装过程中,Operator 可能会显示失败状态。如果安装稍后成功并显示InstallSucceeded消息,则可以忽略失败消息。

故障排除

如果 Operator 未显示为已安装,请进一步进行故障排除

  1. 导航到Operators已安装的 Operators页面,并检查Operator 订阅安装计划选项卡中状态下的任何失败或错误。

  2. 导航到工作负载Pod页面,并检查openshift-nfd项目中 Pod 的日志。

使用节点功能发现 Operator

节点功能发现 (NFD) Operator 通过监视NodeFeatureDiscovery自定义资源 (CR) 来协调运行节点功能发现守护程序集所需的所有资源。根据NodeFeatureDiscovery CR,Operator 在选定的命名空间中创建操作数 (NFD) 组件。您可以编辑 CR 以使用其他命名空间、镜像、镜像拉取策略和nfd-worker-conf配置映射等选项。

作为集群管理员,您可以使用 OpenShift CLI (oc) 或 Web 控制台创建NodeFeatureDiscovery CR。

从 4.12 版本开始,NodeFeatureDiscovery CR 中的operand.image字段是必需的。如果使用 Operator Lifecycle Manager (OLM) 部署 NFD Operator,OLM 会自动设置operand.image字段。如果您使用 OpenShift Container Platform CLI 或 OpenShift Container Platform Web 控制台创建NodeFeatureDiscovery CR,则必须显式设置operand.image字段。

使用 CLI 创建 NodeFeatureDiscovery CR

作为集群管理员,您可以使用 OpenShift CLI (oc) 创建NodeFeatureDiscovery CR 实例。

spec.operand.image设置需要定义-rhel9镜像才能与 OpenShift Container Platform 4.13 及更高版本一起使用。

以下示例显示了使用-rhel9获取正确镜像的方法。

先决条件
  • 您可以访问 OpenShift Container Platform 集群

  • 您已安装 OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录。

  • 您已安装 NFD Operator。

步骤
  1. 创建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字段是必需的。
  2. 运行以下命令创建NodeFeatureDiscovery CR

    $ oc apply -f <filename>
验证
  1. 运行以下命令检查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

    成功的部署将显示运行中状态。

在断开连接的环境中使用 CLI 创建 NodeFeatureDiscovery CR

作为集群管理员,您可以使用 OpenShift CLI (oc) 创建NodeFeatureDiscovery CR 实例。

先决条件
  • 您可以访问 OpenShift Container Platform 集群

  • 您已安装 OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录。

  • 您已安装 NFD Operator。

  • 您可以访问包含所需镜像的镜像仓库。

  • 您已安装skopeo CLI 工具。

步骤
  1. 确定镜像仓库镜像的摘要

    1. 运行以下命令

      $ 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
    2. 检查输出以识别镜像摘要

      示例输出
      {
        ...
        "Digest": "sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
        ...
      }
  2. 使用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
  3. 创建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字段是必需的。
  4. 运行以下命令创建NodeFeatureDiscovery CR

    $ oc apply -f <filename>
验证
  1. 运行以下命令检查NodeFeatureDiscovery CR 的状态

    $ oc get nodefeaturediscovery nfd-instance -o yaml
  2. 运行以下命令检查 Pod 是否在没有ImagePullBackOff错误的情况下运行

    $ oc get pods -n <nfd_namespace>

使用 Web 控制台创建 NodeFeatureDiscovery CR

作为集群管理员,您可以使用 OpenShift Container Platform Web 控制台创建NodeFeatureDiscovery CR。

先决条件
  • 您可以访问 OpenShift Container Platform 集群

  • 您已以具有cluster-admin权限的用户身份登录。

  • 您已安装 NFD Operator。

步骤
  1. 导航到Operators已安装的 Operators页面。

  2. 节点功能发现部分的提供的 API下,点击创建实例

  3. 编辑NodeFeatureDiscovery CR 的值。

  4. 点击创建

从 4.12 版本开始,NodeFeatureDiscovery CR 中的operand.image字段是必需的。如果使用 Operator Lifecycle Manager (OLM) 部署 NFD Operator,OLM 会自动设置operand.image字段。如果您使用 OpenShift Container Platform CLI 或 OpenShift Container Platform Web 控制台创建NodeFeatureDiscovery CR,则必须显式设置operand.image字段。

配置节点功能发现 Operator

核心

core部分包含一些通用的配置设置,这些设置不是特定于任何特定功能源的。

core.sleepInterval

core.sleepInterval指定连续功能检测或重新检测过程之间的间隔,也因此指定节点重新标记之间的间隔。非正值表示无限睡眠间隔;不执行重新检测或重新标记。

如果指定了已弃用的--sleep-interval命令行标志,则此值将被覆盖。

使用示例
core:
  sleepInterval: 60s (1)

默认值为60s

core.sources

core.sources指定已启用功能源的列表。特殊值all启用所有功能源。

如果指定了已弃用的--sources命令行标志,则此值将被覆盖。

默认值:[all]

使用示例
core:
  sources:
    - system
    - custom

core.labelWhiteList

core.labelWhiteList指定用于根据标签名称过滤功能标签的正则表达式。不匹配的标签不会发布。

正则表达式仅与标签的基本名称部分匹配,即名称中'/'之后的部分。标签前缀或命名空间被省略。

如果指定了已弃用的--label-whitelist命令行标志,则此值将被覆盖。

默认值:null

使用示例
core:
  labelWhiteList: '^cpu-cpuid'

core.noPublish

core.noPublish设置为true将禁用与nfd-master的所有通信。它实际上是一个试运行标志;nfd-worker正常运行功能检测,但不会向nfd-master发送任何标记请求。

如果指定了--no-publish命令行标志,则此值将被覆盖。

示例

使用示例
core:
  noPublish: true (1)

默认值为false

core.klog

以下选项指定日志记录器配置,其中大部分可以在运行时动态调整。

日志记录器选项也可以使用命令行标志指定,命令行标志优先于任何对应的配置文件选项。

core.klog.addDirHeader

如果设置为truecore.klog.addDirHeader 会将文件目录添加到日志消息的头部。

默认值:false

运行时可配置:是

core.klog.alsologtostderr

同时向标准错误和文件记录日志。

默认值:false

运行时可配置:是

core.klog.logBacktraceAt

当日志记录命中文件line:N时,发出堆栈跟踪。

默认值:

运行时可配置:是

core.klog.logDir

如果非空,则在此目录中写入日志文件。

默认值:

运行时可配置:否

core.klog.logFile

如果非空,则使用此日志文件。

默认值:

运行时可配置:否

core.klog.logFileMaxSize

core.klog.logFileMaxSize 定义日志文件可以增长到的最大大小。单位为兆字节。如果值为0,则最大文件大小不限。

默认值:1800

运行时可配置:否

core.klog.logtostderr

将日志记录到标准错误而不是文件。

默认值:true

运行时可配置:是

core.klog.skipHeaders

如果将core.klog.skipHeaders 设置为true,则避免在日志消息中使用头部前缀。

默认值:false

运行时可配置:是

core.klog.skipLogHeaders

如果将core.klog.skipLogHeaders 设置为true,则在打开日志文件时避免使用头部。

默认值:false

运行时可配置:否

core.klog.stderrthreshold

等于或高于此阈值的日志将发送到 stderr。

默认值:2

运行时可配置:是

core.klog.v

core.klog.v 是日志级别详细程度的数字。

默认值:0

运行时可配置:是

core.klog.vmodule

core.klog.vmodule 是一个逗号分隔的pattern=N 设置列表,用于按文件过滤日志记录。

默认值:

运行时可配置:是

sources

sources 部分包含特定于功能源的配置参数。

sources.cpu.cpuid.attributeBlacklist

阻止发布此选项中列出的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]

sources.cpu.cpuid.attributeWhitelist

仅发布此选项中列出的cpuid 功能。

sources.cpu.cpuid.attributeWhitelist 优先于sources.cpu.cpuid.attributeBlacklist

默认值:

使用示例
sources:
  cpu:
    cpuid:
      attributeWhitelist: [AVX512BW, AVX512CD, AVX512DQ, AVX512F, AVX512VL]

sources.kernel.kconfigFile

sources.kernel.kconfigFile 是内核配置文件的路径。如果为空,NFD 将在众所周知的标准位置进行搜索。

默认值:

使用示例
sources:
  kernel:
    kconfigFile: "/path/to/kconfig"

sources.kernel.configOpts

sources.kernel.configOpts 表示要作为功能标签发布的内核配置选项。

默认值:[NO_HZ, NO_HZ_IDLE, NO_HZ_FULL, PREEMPT]

使用示例
sources:
  kernel:
    configOpts: [NO_HZ, X86, DMI]

sources.pci.deviceClassWhitelist

sources.pci.deviceClassWhitelist 是要为其发布标签的PCI 设备类 ID 列表。它可以仅指定为主类(例如,03)或完整的类-子类组合(例如 0300)。前者意味着接受所有子类。标签的格式可以使用deviceLabelFields进一步配置。

默认值:["03", "0b40", "12"]

使用示例
sources:
  pci:
    deviceClassWhitelist: ["0200", "03"]

sources.pci.deviceLabelFields

sources.pci.deviceLabelFields 是构造功能标签名称时要使用的 PCI ID 字段集。有效字段为classvendordevicesubsystem_vendorsubsystem_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

sources.usb.deviceClassWhitelist 是要为其发布功能标签的 USB 设备类 ID 列表。标签的格式可以使用deviceLabelFields进一步配置。

默认值:["0e", "ef", "fe", "ff"]

使用示例
sources:
  usb:
    deviceClassWhitelist: ["ef", "ff"]

sources.usb.deviceLabelFields

sources.usb.deviceLabelFields 是用于组合功能标签名称的 USB ID 字段集。有效字段为classvendordevice

默认值:[class, vendor, device]

使用示例
sources:
  pci:
    deviceLabelFields: [class, vendor]

使用上面的示例配置,NFD 将发布类似于:feature.node.kubernetes.io/usb-<class-id>_<vendor-id>.present=true 的标签。

sources.custom

sources.custom 是要在自定义功能源中处理的规则列表,以创建用户特定的标签。

默认值:

使用示例
source:
  custom:
  - name: "my.custom.feature"
    matchOn:
    - loadedKMod: ["e1000e"]
    - pciId:
        class: ["0200"]
        vendor: ["8086"]

关于 NodeFeatureRule 自定义资源

NodeFeatureRule 对象是用于基于规则的节点自定义标签的NodeFeatureDiscovery 自定义资源。一些用例包括特定于应用程序的标签或硬件供应商的分布,以创建其设备的特定标签。

NodeFeatureRule 对象提供了一种方法来创建特定于供应商或应用程序的标签和污点。它使用灵活的基于规则的机制来创建标签,并根据节点功能可选地创建污点。

使用 NodeFeatureRule 自定义资源

如果一组规则与条件匹配,则创建NodeFeatureRule 对象来标记节点。

步骤
  1. 创建一个名为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 设备时发生标签。

  2. 通过运行以下命令将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 拓扑更新程序

节点功能发现 (NFD) 拓扑更新程序是一个守护程序,负责检查工作节点上的已分配资源。它考虑了可按区域分配给新 Pod 的资源,其中区域可以是非统一内存访问 (NUMA) 节点。NFD 拓扑更新程序将信息传达给 nfd-master,nfd-master 创建一个与集群中所有工作节点对应的NodeResourceTopology 自定义资源 (CR)。集群的每个节点上都运行一个 NFD 拓扑更新程序实例。

要在 NFD 中启用拓扑更新程序工作程序,请在NodeFeatureDiscovery CR 中将topologyupdater 变量设置为true,如使用节点功能发现运算符部分所述。

NodeResourceTopology CR

使用 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 拓扑更新程序命令行标志

要查看可用的命令行标志,请运行nfd-topology-updater -help命令。例如,在podman容器中,运行以下命令:

$ podman run gcr.io/k8s-staging-nfd/node-feature-discovery:master nfd-topology-updater -help

-ca-file

-ca-file标志与-cert-file-key-file标志一起,是控制NFD拓扑更新程序上相互TLS身份验证的三个标志之一。此标志指定用于验证nfd-master真实性的TLS根证书。

默认值:空

必须与-cert-file-key-file标志一起指定-ca-file标志。

示例
$ nfd-topology-updater -ca-file=/opt/nfd/ca.crt -cert-file=/opt/nfd/updater.crt -key-file=/opt/nfd/updater.key

-cert-file

-cert-file标志与-ca-file-key-file标志一起,是控制NFD拓扑更新程序上相互TLS身份验证的三个标志之一。此标志指定用于验证外发请求的TLS证书。

默认值:空

必须与-ca-file-key-file标志一起指定-cert-file标志。

示例
$ nfd-topology-updater -cert-file=/opt/nfd/updater.crt -key-file=/opt/nfd/updater.key -ca-file=/opt/nfd/ca.crt

-h, -help

打印用法并退出。

-key-file

-key-file标志与-ca-file-cert-file标志一起,是控制NFD拓扑更新程序上相互TLS身份验证的三个标志之一。此标志指定与给定证书文件(或-cert-file)相对应的私钥,用于验证外发请求。

默认值:空

必须与-ca-file-cert-file标志一起指定-key-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-config-file指定Kubelet配置文件的路径。

默认值:/host-var/lib/kubelet/config.yaml

示例
$ nfd-topology-updater -kubelet-config-file=/var/lib/kubelet/config.yaml

-no-publish

-no-publish标志禁用与nfd-master的所有通信,使其成为nfd-topology-updater的干运行标志。NFD拓扑更新程序正常运行资源硬件拓扑检测,但不向nfd-master发送CR请求。

默认值:false

示例
$ nfd-topology-updater -no-publish

-oneshot

-oneshot标志导致NFD拓扑更新程序在完成一次资源硬件拓扑检测后退出。

默认值:false

示例
$ nfd-topology-updater -oneshot -no-publish

-podresources-socket

-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

-server标志指定要连接到的nfd-master端点的地址。

默认值:localhost:8080

示例
$ nfd-topology-updater -server=nfd-master.nfd.svc.cluster.local:443

-server-name-override

-server-name-override标志指定要从nfd-master TLS证书中期望的公用名(CN)。此标志主要用于开发和调试目的。

默认值:空

示例
$ nfd-topology-updater -server-name-override=localhost

-sleep-interval

-sleep-interval标志指定资源硬件拓扑重新检查和自定义资源更新之间的间隔。非正值表示无限睡眠间隔,不进行重新检测。

默认值:60s

示例
$ nfd-topology-updater -sleep-interval=1h

-version

打印版本并退出。

-watch-namespace

-watch-namespace标志指定命名空间,以确保资源硬件拓扑检查仅针对在指定命名空间中运行的Pod进行。在资源会计过程中,不考虑不在指定命名空间中运行的Pod。这对于测试和调试特别有用。*值表示在会计过程中考虑所有命名空间中的所有Pod。

默认值:*

示例
$ nfd-topology-updater -watch-namespace=rte