×

SR-IOV网络节点配置对象

通过创建 SR-IOV 网络节点策略来指定节点的 SR-IOV 网络设备配置。该策略的 API 对象属于 `sriovnetwork.openshift.io` API 组。

以下 YAML 描述了一个 SR-IOV 网络节点策略

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name> (1)
  namespace: openshift-sriov-network-operator (2)
spec:
  resourceName: <sriov_resource_name> (3)
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true" (4)
  priority: <priority> (5)
  mtu: <mtu> (6)
  needVhostNet: false (7)
  numVfs: <num> (8)
  externallyManaged: false (9)
  nicSelector: (10)
    vendor: "<vendor_code>" (11)
    deviceID: "<device_id>" (12)
    pfNames: ["<pf_name>", ...] (13)
    rootDevices: ["<pci_bus_id>", ...] (14)
    netFilter: "<filter_string>" (15)
  deviceType: <device_type> (16)
  isRdma: false (17)
  linkType: <link_type> (18)
  eSwitchMode: "switchdev" (19)
  excludeTopology: false (20)
1 自定义资源对象的名称。
2 安装 SR-IOV 网络操作符的命名空间。
3 SR-IOV 网络设备插件的资源名称。您可以为一个资源名称创建多个 SR-IOV 网络节点策略。

指定名称时,请确保在 `resourceName` 中使用接受的语法表达式 `^[a-zA-Z0-9_]+$`。

4 节点选择器指定要配置的节点。仅配置所选节点上的 SR-IOV 网络设备。SR-IOV 容器网络接口 (CNI) 插件和设备插件仅部署在选定的节点上。

SR-IOV 网络操作符按顺序将节点网络配置策略应用于节点。在应用节点网络配置策略之前,SR-IOV 网络操作符会检查节点的机器配置池 (MCP) 是否处于不健康状态,例如 `Degraded` 或 `Updating`。如果节点处于不健康的 MCP 状态,则应用节点网络配置策略到集群中所有目标节点的过程将暂停,直到 MCP 返回健康状态。

为避免不健康的 MCP 中的节点阻止将节点网络配置策略应用于其他节点(包括其他 MCP 中的节点),必须为每个 MCP 创建单独的节点网络配置策略。

5 可选:优先级是一个介于 `0` 和 `99` 之间的整数值。较小的值具有较高的优先级。例如,优先级 `10` 比 `99` 优先级更高。默认值为 `99`。
6 可选:虚拟函数的最大传输单元 (MTU)。最大 MTU 值因不同的网络接口控制器 (NIC) 型号而异。
7 可选:将 `needVhostNet` 设置为 `true` 以在 Pod 中挂载 `/dev/vhost-net` 设备。使用挂载的 `/dev/vhost-net` 设备与数据平面开发套件 (DPDK) 配合使用,将流量转发到内核网络堆栈。
8 为 SR-IOV 物理网络设备创建的虚拟函数 (VF) 的数量。对于英特尔网络接口控制器 (NIC),VF 数量不能大于设备支持的 VF 总数。对于Mellanox NIC,VF 数量不能大于 `127`。
9 `externallyManaged` 字段指示 SR-IOV 网络操作符是否管理所有虚拟函数 (VF) 或仅管理虚拟函数 (VF) 的子集。将该值设置为 `false` 时,SR-IOV 网络操作符将管理和配置 PF 上的所有 VF。

当 `externallyManaged` 设置为 `true` 时,必须在应用 `SriovNetworkNodePolicy` 资源之前手动在物理功能 (PF) 上创建虚拟函数 (VF)。如果未预先创建 VF,则 SR-IOV 网络操作符的 Webhook 将阻止策略请求。

当 `externallyManaged` 设置为 `false` 时,SR-IOV 网络操作符会自动创建和管理 VF,包括必要时重置它们。

要在主机系统上使用 VF,必须通过 NMState 创建它们,并将 `externallyManaged` 设置为 `true`。在此模式下,SR-IOV 网络操作符不会修改 PF 或手动管理的 VF,除非策略的 `nicSelector` 字段中明确定义了这些 VF。但是,SR-IOV 网络操作符将继续管理用作 Pod 次要接口的 VF。

10 NIC 选择器标识此资源适用的设备。您不必为所有参数指定值。建议使用足够的精度来标识网络设备,以避免无意中选择设备。

如果指定 `rootDevices`,则还必须为 `vendor`、`deviceID` 或 `pfNames` 指定一个值。如果同时指定 `pfNames` 和 `rootDevices`,请确保它们引用的是同一个设备。如果为 `netFilter` 指定一个值,则无需指定任何其他参数,因为网络 ID 是唯一的。

11 可选:SR-IOV 网络设备的供应商十六进制供应商标识符。允许的值只有 `8086`(英特尔)和 `15b3`(Mellanox)。
12 可选:SR-IOV 网络设备的设备十六进制设备标识符。例如,`101b` 是 Mellanox ConnectX-6 设备的设备 ID。
13 可选:资源必须应用到的一个或多个物理功能 (PF) 名称的数组。
14 可选:资源必须应用到的一个或多个 PCI 总线地址的数组。例如 `0000:02:00.1`。
15 可选:特定于平台的网络过滤器。唯一支持的平台是 Red Hat OpenStack Platform (RHOSP)。可接受的值使用以下格式:`openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`。将 `xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx` 替换为 `/var/config/openstack/latest/network_data.json` 元数据文件中的值。此过滤器确保 VF 与特定的 OpenStack 网络关联。操作员使用此过滤器根据 OpenStack 平台提供的元数据将 VF 映射到相应的网络。
16 可选:为此资源创建的 VF 配置的驱动程序。允许的值只有 `netdevice` 和 `vfio-pci`。默认值为 `netdevice`。

要使 Mellanox NIC 在裸机节点上的 DPDK 模式下工作,请使用 `netdevice` 驱动程序类型并将 `isRdma` 设置为 `true`。

17 可选:配置是否启用远程直接内存访问 (RDMA) 模式。默认值为 `false`。

如果将 `isRdma` 参数设置为 `true`,则可以继续将启用 RDMA 的 VF 用作普通网络设备。设备可以在任一模式下使用。

将 `isRdma` 设置为 `true` 并另外将 `needVhostNet` 设置为 `true` 以配置 Mellanox NIC 以与快速数据路径 DPDK 应用程序一起使用。

不能为英特尔 NIC 将 `isRdma` 参数设置为 `true`。

18 可选:VF 的链路类型。默认值为以太网的 `eth`。将其值更改为 InfiniBand 的 `ib`。

当 `linkType` 设置为 `ib` 时,SR-IOV 网络操作符 Webhook 会自动将 `isRdma` 设置为 `true`。当 `linkType` 设置为 `ib` 时,不应将 `deviceType` 设置为 `vfio-pci`。

不要为 SriovNetworkNodePolicy 设置 `linkType` 为 `eth`,因为这会导致设备插件报告的可用设备数量不正确。

19 可选:要启用硬件卸载,必须将 `eSwitchMode` 字段设置为 `"switchdev"`。有关硬件卸载的更多信息,请参见“配置硬件卸载”。
20 可选:要排除将 SR-IOV 网络资源的 NUMA 节点宣传给拓扑管理器,请将值设置为 `true`。默认值为 `false`。

SR-IOV 网络节点配置示例

以下示例描述了 InfiniBand 设备的配置

InfiniBand 设备的示例配置
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-ib-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: ibnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    rootDevices:
      - "0000:19:00.0"
  linkType: ib
  isRdma: true

以下示例描述了 RHOSP 虚拟机中 SR-IOV 网络设备的配置

虚拟机中 SR-IOV 设备的示例配置
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-sriov-net-openstack-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: sriovnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 1 (1)
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509" (2)
1 配置虚拟机的节点网络策略时,`numVfs` 字段始终设置为 `1`。
2 当虚拟机部署在 RHOSP 上时,`netFilter` 字段必须引用网络 ID。`netFilter` 的有效值可从 `SriovNetworkNodeState` 对象获取。

SR-IOV 设备的虚拟函数 (VF) 分区

在某些情况下,您可能希望将来自同一物理函数 (PF) 的多个虚拟函数 (VF) 分割到多个资源池中。例如,您可能希望某些 VF 使用默认驱动程序加载,而其余 VF 使用vfio-pci驱动程序加载。在这种部署中,可以在 SriovNetworkNodePolicy 自定义资源 (CR) 中使用pfNames选择器来使用以下格式指定池的 VF 范围:<pfname>#<first_vf>-<last_vf>

例如,以下 YAML 显示了名为netpf0的接口以及 VF 27 的选择器。

pfNames: ["netpf0#2-7"]
  • netpf0 是 PF 接口名称。

  • 2 是范围内包含的第一个 VF 索引(基于 0)。

  • 7 是范围内包含的最后一个 VF 索引(基于 0)。

如果满足以下要求,则可以使用不同的策略 CR 选择来自同一 PF 的 VF。

  • 对于选择同一 PF 的策略,numVfs 值必须相同。

  • VF 索引必须在0<numVfs>-1的范围内。例如,如果策略的numVfs设置为8,则<first_vf>值不能小于0<last_vf>不能大于7

  • 不同策略中的 VF 范围不能重叠。

  • <first_vf>不能大于<last_vf>

以下示例说明了 SR-IOV 设备的 NIC 分区。

策略policy-net-1定义了一个资源池net-1,其中包含使用默认 VF 驱动程序的 PF netpf0 的 VF 0。策略policy-net-1-dpdk定义了一个资源池net-1-dpdk,其中包含使用vfio VF 驱动程序的 PF netpf0 的 VF 815

策略policy-net-1

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#0-0"]
  deviceType: netdevice

策略policy-net-1-dpdk

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1-dpdk
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1dpdk
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#8-15"]
  deviceType: vfio-pci
验证接口是否已成功分区

通过运行以下命令,确认接口已成功划分为 SR-IOV 设备的虚拟函数 (VF)。

$ ip link show <interface> (1)
1 <interface>替换为您在将 SR-IOV 设备分区到 VF 时指定的接口,例如ens3f1
示例输出
5: ens3f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:d1:bc:01 brd ff:ff:ff:ff:ff:ff

vf 0     link/ether 5a:e7:88:25:ea:a0 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 1     link/ether 3e:1d:36:d7:3d:49 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 2     link/ether ce:09:56:97:df:f9 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 3     link/ether 5e:91:cf:88:d1:38 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 4     link/ether e6:06:a1:96:2f:de brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

配置 SR-IOV 网络设备

SR-IOV 网络操作员将SriovNetworkNodePolicy.sriovnetwork.openshift.io自定义资源定义添加到 OpenShift Container Platform。您可以通过创建 SriovNetworkNodePolicy 自定义资源 (CR) 来配置 SR-IOV 网络设备。

应用SriovNetworkNodePolicy对象中指定的配置时,SR-IOV 运算符可能会清空节点,在某些情况下,会重启节点。重启仅在以下情况下发生:

  • 对于 Mellanox NIC(mlx5驱动程序),每次物理函数 (PF) 上的虚拟函数 (VF) 数量增加时,都会发生节点重启。

  • 对于 Intel NIC,只有在内核参数不包含intel_iommu=oniommu=pt时,才会发生重启。

配置更改的应用可能需要几分钟时间。

先决条件
  • 您已安装 OpenShift CLI(oc)。

  • 您可以作为具有cluster-admin角色的用户访问集群。

  • 您已安装 SR-IOV 网络操作员。

  • 您的集群中有足够的可用节点来处理从已清空节点中驱逐的工作负载。

  • 您没有为 SR-IOV 网络设备配置选择任何控制平面节点。

步骤
  1. 创建一个SriovNetworkNodePolicy对象,然后将 YAML 保存到<name>-sriov-node-network.yaml文件中。将<name>替换为此配置的名称。

  2. 可选:如果 SR-IOV 可用集群节点尚未标记,请使用SriovNetworkNodePolicy.Spec.NodeSelector标记它们。有关标记节点的更多信息,请参阅“了解如何在节点上更新标签”。

  3. 创建SriovNetworkNodePolicy对象

    $ oc create -f <name>-sriov-node-network.yaml

    其中<name>指定此配置的名称。

    应用配置更新后,sriov-network-operator命名空间中的所有 pod 都将转换为Running状态。

  4. 要验证 SR-IOV 网络设备是否已配置,请输入以下命令。将<node_name>替换为您刚刚配置的具有 SR-IOV 网络设备的节点的名称。

    $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'

配置 SR-IOV 网络策略更新期间的并行节点清空

默认情况下,SR-IOV 网络操作员会在每次策略更改之前清空节点上的工作负载。操作员一次执行一个节点的操作,以确保没有工作负载受重新配置的影响。

在大型集群中,顺序清空节点可能非常耗时,可能需要数小时甚至数天。在时间敏感的环境中,您可以在SriovNetworkPoolConfig自定义资源 (CR) 中启用并行节点清空,以加快 SR-IOV 网络配置的部署。

要配置并行清空,请使用SriovNetworkPoolConfig CR 创建节点池。然后,您可以将节点添加到池中,并定义操作员可以并行清空的池中节点的最大数量。使用这种方法,您可以启用并行清空以加快重新配置速度,同时确保您在池中仍然有足够的节点来处理任何正在运行的工作负载。

一个节点只能属于一个 SR-IOV 网络池配置。如果节点不是池的一部分,则将其添加到虚拟的默认池中,该池一次只能清空一个节点。

节点可能会在清空过程中重启。

先决条件
  • 安装 OpenShift CLI(oc)。

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

  • 安装 SR-IOV 网络操作员。

  • 节点具有支持 SR-IOV 的硬件。

步骤
  1. 创建SriovNetworkPoolConfig资源

    1. 创建一个定义SriovNetworkPoolConfig资源的 YAML 文件

      示例sriov-nw-pool.yaml文件
      apiVersion: v1
      kind: SriovNetworkPoolConfig
      metadata:
        name: pool-1 (1)
        namespace: openshift-sriov-network-operator (2)
      spec:
        maxUnavailable: 2 (3)
        nodeSelector: (4)
          matchLabels:
            node-role.kubernetes.io/worker: ""
      1 指定SriovNetworkPoolConfig对象的名称。
      2 指定安装 SR-IOV 网络操作员的命名空间。
      3 为更新期间池中可能不可用的节点指定整数或百分比值。例如,如果您有 10 个节点并将最大不可用节点设置为 2,则任何时候只能并行清空 2 个节点,留下 8 个节点来处理工作负载。
      4 使用节点选择器指定要添加到池中的节点。此示例将所有具有worker角色的节点添加到池中。
    2. 通过运行以下命令创建SriovNetworkPoolConfig资源

      $ oc create -f sriov-nw-pool.yaml
  2. 通过运行以下命令创建sriov-test命名空间

    $ oc create namespace sriov-test
  3. 创建一个SriovNetworkNodePolicy资源

    1. 创建一个定义SriovNetworkNodePolicy资源的 YAML 文件

      示例sriov-node-policy.yaml文件
      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetworkNodePolicy
      metadata:
        name: sriov-nic-1
        namespace: openshift-sriov-network-operator
      spec:
        deviceType: netdevice
        nicSelector:
          pfNames: ["ens1"]
        nodeSelector:
          node-role.kubernetes.io/worker: ""
        numVfs: 5
        priority: 99
        resourceName: sriov_nic_1
    2. 通过运行以下命令创建SriovNetworkNodePolicy资源

      $ oc create -f sriov-node-policy.yaml
  4. 创建一个SriovNetwork资源

    1. 创建一个定义SriovNetwork资源的 YAML 文件

      示例sriov-network.yaml文件
      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetwork
      metadata:
        name: sriov-nic-1
        namespace: openshift-sriov-network-operator
      spec:
        linkState: auto
        networkNamespace: sriov-test
        resourceName: sriov_nic_1
        capabilities: '{ "mac": true, "ips": true }'
        ipam: '{ "type": "static" }'
    2. 运行以下命令创建SriovNetwork资源

      $ oc create -f sriov-network.yaml
验证
  • 运行以下命令查看您创建的节点池

    $ oc get sriovNetworkpoolConfig -n openshift-sriov-network-operator
    示例输出
    NAME     AGE
    pool-1   67s (1)
    
    1 在此示例中,pool-1包含所有具有worker角色的节点。

要使用上述步骤中的示例场景演示节点移除过程,请完成以下步骤

  1. 更新SriovNetworkNodePolicy资源中的虚拟函数数量以触发集群中的工作负载移除

    $ oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'
  2. 运行以下命令监控目标集群上的移除状态

    $ oc get sriovNetworkNodeState -n openshift-sriov-network-operator
    示例输出
    NAMESPACE                          NAME       SYNC STATUS   DESIRED SYNC STATE   CURRENT SYNC STATE   AGE
    openshift-sriov-network-operator   worker-0   InProgress    Drain_Required       DrainComplete        3d10h
    openshift-sriov-network-operator   worker-1   InProgress    Drain_Required       DrainComplete        3d10h

    移除过程完成后,同步状态 (SYNC STATUS) 将更改为成功 (Succeeded),并且所需同步状态 (DESIRED SYNC STATE)当前同步状态 (CURRENT SYNC STATE) 值将返回到空闲 (IDLE)

    示例输出
    NAMESPACE                          NAME       SYNC STATUS   DESIRED SYNC STATE   CURRENT SYNC STATE   AGE
    openshift-sriov-network-operator   worker-0   Succeeded     Idle                 Idle                 3d10h
    openshift-sriov-network-operator   worker-1   Succeeded     Idle                 Idle                 3d10h

SR-IOV配置故障排除

按照配置 SR-IOV 网络设备的过程之后,以下部分将解决一些错误情况。

要显示节点的状态,请运行以下命令

$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>

其中:<node_name> 指定具有 SR-IOV 网络设备的节点的名称。

错误输出:无法分配内存
"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"

当节点指示其无法分配内存时,请检查以下项目

  • 确认已在节点的 BIOS 中启用全局 SR-IOV 设置。

  • 确认已在节点的 BIOS 中启用 VT-d。

将 SR-IOV 网络分配给 VRF

作为集群管理员,您可以使用 CNI VRF 插件将 SR-IOV 网络接口分配到您的 VRF 域。

为此,请将 VRF 配置添加到SriovNetwork资源的可选metaPlugins参数中。

使用 VRF 的应用程序需要绑定到特定设备。常用方法是为套接字使用SO_BINDTODEVICE选项。SO_BINDTODEVICE将套接字绑定到在传递的接口名称中指定的设备,例如eth1。要使用SO_BINDTODEVICE,应用程序必须具有CAP_NET_RAW权限。

在 OpenShift Container Platform Pod 中不支持使用ip vrf exec命令通过 VRF。要使用 VRF,请将应用程序直接绑定到 VRF 接口。

使用 CNI VRF 插件创建额外的 SR-IOV 网络连接

SR-IOV 网络操作员管理其他网络定义。当您指定要创建的额外 SR-IOV 网络时,SR-IOV 网络操作员会自动创建NetworkAttachmentDefinition自定义资源 (CR)。

不要编辑 SR-IOV 网络操作员管理的NetworkAttachmentDefinition自定义资源。这样做可能会中断额外网络上的网络流量。

要使用 CNI VRF 插件创建额外的 SR-IOV 网络连接,请执行以下步骤。

先决条件
  • 安装 OpenShift Container Platform 命令行界面 (oc)。

  • 以具有集群管理员权限的用户身份登录到 OpenShift Container Platform 集群。

步骤
  1. 为额外的 SR-IOV 网络连接创建SriovNetwork自定义资源 (CR),并插入metaPlugins配置,如下例 CR 所示。将 YAML 保存为文件sriov-network-attachment.yaml

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: example-network
      namespace: additional-sriov-network-1
    spec:
      ipam: |
        {
          "type": "host-local",
          "subnet": "10.56.217.0/24",
          "rangeStart": "10.56.217.171",
          "rangeEnd": "10.56.217.181",
          "routes": [{
            "dst": "0.0.0.0/0"
          }],
          "gateway": "10.56.217.1"
        }
      vlan: 0
      resourceName: intelnics
      metaPlugins : |
        {
          "type": "vrf", (1)
          "vrfname": "example-vrf-name" (2)
        }
    1 type必须设置为vrf
    2 vrfname是接口分配到的 VRF 的名称。如果它在 Pod 中不存在,则会创建它。
  2. 创建SriovNetwork资源

    $ oc create -f sriov-network-attachment.yaml
验证NetworkAttachmentDefinition CR 是否已成功创建
  • 通过运行以下命令确认 SR-IOV 网络操作员是否已创建NetworkAttachmentDefinition CR。

    $ oc get network-attachment-definitions -n <namespace> (1)
    1 <namespace>替换为您在配置网络连接时指定的命名空间,例如additional-sriov-network-1
    示例输出
    NAME                            AGE
    additional-sriov-network-1      14m

    SR-IOV 网络操作员创建 CR 之前可能会有延迟。

验证额外的 SR-IOV 网络连接是否成功

要验证 VRF CNI 是否已正确配置以及是否已附加额外的 SR-IOV 网络连接,请执行以下操作

  1. 创建一个使用 VRF CNI 的 SR-IOV 网络。

  2. 将网络分配给 Pod。

  3. 验证 Pod 网络连接是否已连接到 SR-IOV 额外网络。远程 shell 登录到 Pod 并运行以下命令

    $ ip vrf show
    示例输出
    Name              Table
    -----------------------
    red                 10
  4. 确认 VRF 接口是辅助接口的主接口

    $ ip link
    示例输出
    ...
    5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
    ...

排除用于 NUMA 感知调度的 SR-IOV 网络拓扑

您可以排除为 SR-IOV 网络向拓扑管理器宣传非一致内存访问 (NUMA) 节点,以便在 NUMA 感知 Pod 调度期间实现更灵活的 SR-IOV 网络部署。

在某些情况下,优先级是最大限度地提高 Pod 在单个 NUMA 节点上的 CPU 和内存资源。通过不向拓扑管理器提供关于 Pod 的 SR-IOV 网络资源的 NUMA 节点的提示,拓扑管理器可以将 SR-IOV 网络资源和 Pod CPU 和内存资源部署到不同的 NUMA 节点。由于 NUMA 节点之间的数据传输,这可能会增加网络延迟。但是,在工作负载需要最佳 CPU 和内存性能的情况下,这是可以接受的。

例如,考虑一个具有两个 NUMA 节点:numa0numa1 的计算节点compute-1。支持 SR-IOV 的 NIC 位于numa0上。可用于 Pod 调度的 CPU 仅位于numa1上。通过将excludeTopology规范设置为true,拓扑管理器可以将 Pod 的 CPU 和内存资源分配给numa1,并将同一 Pod 的 SR-IOV 网络资源分配给numa0。只有在将excludeTopology规范设置为true时才有可能。否则,拓扑管理器会尝试将所有资源放置在同一个 NUMA 节点上。

排除用于 NUMA 感知调度的 SR-IOV 网络拓扑

要排除将 SR-IOV 网络资源的非一致内存访问 (NUMA) 节点宣传给拓扑管理器,您可以在SriovNetworkNodePolicy自定义资源中配置excludeTopology规范。在 NUMA 感知 Pod 调度期间,使用此配置可以实现更灵活的 SR-IOV 网络部署。

先决条件
  • 您已安装 OpenShift CLI (oc)。

  • 您已将 CPU 管理器策略配置为static。有关 CPU 管理器的更多信息,请参阅“其他资源”部分。

  • 您已将拓扑管理器策略配置为single-numa-node

  • 您已安装 SR-IOV 网络操作员。

步骤
  1. 创建SriovNetworkNodePolicy CR

    1. 将以下 YAML 保存到sriov-network-node-policy.yaml文件中,替换 YAML 中的值以匹配您的环境

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetworkNodePolicy
      metadata:
        name: <policy_name>
        namespace: openshift-sriov-network-operator
      spec:
        resourceName: sriovnuma0 (1)
        nodeSelector:
          kubernetes.io/hostname: <node_name>
        numVfs: <number_of_Vfs>
        nicSelector: (2)
          vendor: "<vendor_ID>"
          deviceID: "<device_ID>"
        deviceType: netdevice
        excludeTopology: true (3)
      1 SR-IOV 网络设备插件的资源名称。此 YAML 使用示例resourceName值。
      2 使用 NIC 选择器标识操作员要配置的设备。
      3 要排除将 SR-IOV 网络资源的 NUMA 节点宣传给拓扑管理器,请将值设置为true。默认值为false

      如果多个SriovNetworkNodePolicy资源定位相同的 SR-IOV 网络资源,则SriovNetworkNodePolicy资源必须具有与excludeTopology规范相同的值。否则,将拒绝冲突的策略。

    2. 通过运行以下命令创建SriovNetworkNodePolicy资源

      $ oc create -f sriov-network-node-policy.yaml
      示例输出
      sriovnetworknodepolicy.sriovnetwork.openshift.io/policy-for-numa-0 created
  2. 创建SriovNetwork CR

    1. 将以下 YAML 保存到sriov-network.yaml文件中,替换 YAML 中的值以匹配您的环境

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetwork
      metadata:
        name: sriov-numa-0-network (1)
        namespace: openshift-sriov-network-operator
      spec:
        resourceName: sriovnuma0 (2)
        networkNamespace: <namespace> (3)
        ipam: |- (4)
          {
            "type": "<ipam_type>",
          }
      1 sriov-numa-0-network替换为 SR-IOV 网络资源的名称。
      2 指定上一步中SriovNetworkNodePolicy CR 的资源名称。此 YAML 使用示例resourceName值。
      3 输入 SR-IOV 网络的命名空间。
      4 输入 SR-IOV 网络的 IP 地址管理配置。
    2. 运行以下命令创建SriovNetwork资源

      $ oc create -f sriov-network.yaml
      示例输出
      sriovnetwork.sriovnetwork.openshift.io/sriov-numa-0-network created
  3. 创建一个 Pod 并分配上一步中的 SR-IOV 网络资源

    1. 将以下 YAML 保存到sriov-network-pod.yaml文件中,替换 YAML 中的值以匹配您的环境

      apiVersion: v1
      kind: Pod
      metadata:
        name: <pod_name>
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "sriov-numa-0-network", (1)
              }
            ]
      spec:
        containers:
        - name: <container_name>
          image: <image>
          imagePullPolicy: IfNotPresent
          command: ["sleep", "infinity"]
      1 这是使用SriovNetworkNodePolicy资源的SriovNetwork资源的名称。
    2. 运行以下命令创建Pod资源

      $ oc create -f sriov-network-pod.yaml
      示例输出
      pod/example-pod created
验证
  1. 运行以下命令验证 Pod 状态,将<pod_name>替换为 Pod 的名称。

    $ oc get pod <pod_name>
    示例输出
    NAME                                     READY   STATUS    RESTARTS   AGE
    test-deployment-sriov-76cbbf4756-k9v72   1/1     Running   0          45h
  2. 打开目标 Pod 的调试会话,以验证 SR-IOV 网络资源是否部署到与内存和 CPU 资源不同的节点上。

    1. 运行以下命令打开 Pod 的调试会话,将<pod_name>替换为目标 Pod 名称。

      $ oc debug pod/<pod_name>
    2. 在调试 shell 中将/host设置为根目录。调试 Pod 从主机挂载根文件系统到 Pod 内的/host。通过将根目录更改为/host,您可以运行主机文件系统中的二进制文件。

      $ chroot /host
    3. 运行以下命令查看有关 CPU 分配的信息。

      $ lscpu | grep NUMA
      示例输出
      NUMA node(s):                    2
      NUMA node0 CPU(s):     0,2,4,6,8,10,12,14,16,18,...
      NUMA node1 CPU(s):     1,3,5,7,9,11,13,15,17,19,...
      $ cat /proc/self/status | grep Cpus
      示例输出
      Cpus_allowed:	aa
      Cpus_allowed_list:	1,3,5,7
      $ cat  /sys/class/net/net1/device/numa_node
      示例输出
      0

      在此示例中,CPU 1、3、5 和 7 分配给NUMA 节点 1,但 SR-IOV 网络资源可以使用NUMA 节点 0中的网卡。

如果excludeTopology规范设置为True,则所需资源可能存在于同一个 NUMA 节点中。

其他资源