18.3. 配置 SR-IOV 以太网网络附加
您可以为集群中的单根 I/O 虚拟化(SR-IOV)设备配置以太网网络附加。
在执行以下文档中的任何任务前,请确保 安装了 SR-IOV Network Operator。
18.3.1. 以太网设备配置对象
您可以通过定义 SriovNetwork
对象来配置以太网网络设备。
以下 YAML 描述了 SriovNetwork
对象:
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: <name> 1 namespace: openshift-sriov-network-operator 2 spec: resourceName: <sriov_resource_name> 3 networkNamespace: <target_namespace> 4 vlan: <vlan> 5 spoofChk: "<spoof_check>" 6 ipam: |- 7 {} linkState: <link_state> 8 maxTxRate: <max_tx_rate> 9 minTxRate: <min_tx_rate> 10 vlanQoS: <vlan_qos> 11 trust: "<trust_vf>" 12 capabilities: <capabilities> 13
- 1
- 对象的名称。SR-IOV Network Operator 创建一个名称相同的
NetworkAttachmentDefinition
对象。 - 2
- 安装 SR-IOV Network Operator 的命名空间。
- 3
- 用于为这个额外网络定义 SR-IOV 硬件的
SriovNetworkNodePolicy
对象中的spec.resourceName
参数的值。 - 4
SriovNetwork
对象的目标命名空间。只有目标命名空间中的 pod 可以附加到额外网络。- 5
- 可选:额外网络的虚拟 LAN(VLAN)ID。它需要是一个从
0
到4095
范围内的一个整数值。默认值为0
。 - 6
- 可选:VF 的 spoof 检查模式。允许的值是字符串
"on"
和"off"
。重要指定的值必须由引号包括,否则 SR-IOV Network Operator 将拒绝对象。
- 7
- 为 IPAM CNI 插件指定一个配置对象做为一个 YAML 块 scalar。该插件管理附加定义的 IP 地址分配。
- 8
- 可选:虚拟功能(VF)的链接状态。允许的值是
enable
、disable
和auto
。 - 9
- 可选:VF 的最大传输率(以 Mbps 为单位)。
- 10
- 可选:VF 的最低传输率(以 Mbps 为单位)。这个值必须小于或等于最大传输率。注意
Intel NIC 不支持
minTxRate
参数。如需更多信息,请参阅 BZ#1772847。 - 11
- 可选:VF 的 IEEE 802.1p 优先级级别。默认值为
0
。 - 12
- 可选:VF 的信任模式。允许的值是字符串
"on"
和"off"
。重要您必须在引号中包含指定的值,或者 SR-IOV Network Operator 拒绝对象。
- 13
- 可选:为这个额外网络配置功能。您可以指定
'{ "ips": true }'
来启用 IP 地址支持,或指定'{ "mac": true }'
来启用 MAC 地址支持。
18.3.1.1. 为动态分配双栈 IP 地址创建配置
双栈 IP 地址分配可使用 ipRanges
参数进行配置:
- IPv4 地址
- IPv6 地址
- 多个 IP 地址分配
流程
-
将
type
设置为whereabouts
。 使用
ipRanges
来分配 IP 地址,如下例所示:cniVersion: operator.openshift.io/v1 kind: Network =metadata: name: cluster spec: additionalNetworks: - name: whereabouts-shim namespace: default type: Raw rawCNIConfig: |- { "name": "whereabouts-dual-stack", "cniVersion": "0.3.1, "type": "bridge", "ipam": { "type": "whereabouts", "ipRanges": [ {"range": "192.168.10.0/24"}, {"range": "2001:db8::/64"} ] } }
- 将网络附加到 pod。如需更多信息,请参阅"将 pod 添加到额外网络"。
- 验证是否分配了所有 IP 地址。
运行以下命令,以确保 IP 地址被分配为元数据。
$ oc exec -it mypod -- ip a
18.3.1.2. 配置网络附加的 IP 地址分配
对于额外网络,可以使用 IP 地址管理(IPAM) CNI 插件来分配 IP 地址,该插件支持各种分配方法,包括动态主机配置协议(DHCP)和静态分配。
负责动态分配 IP 地址的 DHCP IPAM CNI 插件与两个不同的组件一起运行:
- CNI 插件 :负责与 Kubernetes 网络堆栈集成,以请求和释放 IP 地址。
- DHCP IPAM CNI 守护进程 :用于 DHCP 事件的监听程序,该事件与环境中的现有 DHCP 服务器协调,以处理 IP 地址分配请求。这个守护进程并不是 DHCP 服务器本身。
对于在 IPAM 配置中需要 type: dhcp
的网络,请确保以下内容:
- DHCP 服务器可用并在环境中运行。DHCP 服务器是集群外部的,应该成为客户的现有网络基础架构的一部分。
- DHCP 服务器被正确配置为为节点提供 IP 地址。
如果环境中 DHCP 服务器不可用,建议使用 Whereabouts IPAM CNI 插件。Whereabouts CNI 提供类似的 IP 地址管理功能,而无需外部 DHCP 服务器。
当没有外部 DHCP 服务器或首选静态 IP 地址管理时,请使用 Whereabouts CNI 插件。Whereabouts 插件包含一个协调器守护进程来管理过时的 IP 地址分配。
在整个容器生命周期中,必须定期更新 DHCP 租期,因此需要单独的守护进程 DHCP IPAM CNI 守护进程。要部署 DHCP IPAM CNI 守护进程,请修改 Cluster Network Operator (CNO)配置,以触发此守护进程的部署,作为额外网络设置的一部分。
18.3.1.2.1. 静态 IP 地址分配配置
下表描述了静态 IP 地址分配的配置:
字段 | 类型 | 描述 |
---|---|---|
|
|
IPAM 地址类型。值必须是 |
|
| 指定分配给虚拟接口的 IP 地址的对象数组。支持 IPv4 和 IPv6 IP 地址。 |
|
| 指定要在 pod 中配置的路由的一组对象。 |
|
| 可选:指定 DNS 配置的对象数组。 |
address
数组需要带有以下字段的对象:
字段 | 类型 | 描述 |
---|---|---|
|
|
您指定的 IP 地址和网络前缀。例如:如果您指定 |
|
| 出口网络流量要路由到的默认网关。 |
字段 | 类型 | 描述 |
---|---|---|
|
|
CIDR 格式的 IP 地址范围,如 |
|
| 网络流量路由的网关。 |
字段 | 类型 | 描述 |
---|---|---|
|
| 用于发送 DNS 查询的一个或多个 IP 地址的数组。 |
|
|
要附加到主机名的默认域。例如,如果将域设置为 |
|
|
在 DNS 查找查询过程中,附加到非限定主机名(如 |
静态 IP 地址分配配置示例
{ "ipam": { "type": "static", "addresses": [ { "address": "191.168.1.7/24" } ] } }
18.3.1.2.2. 动态 IP 地址(DHCP)分配配置
pod 在创建时获取其原始 DHCP 租期。该租期必须由集群中运行的一个小型的 DHCP 服务器部署定期续订。
对于以太网网络附加,SR-IOV Network Operator 不会创建 DHCP 服务器部署。Cluster Network Operator 负责创建最小 DHCP 服务器部署。
要触发 DHCP 服务器的部署,您必须编辑 Cluster Network Operator 配置来创建 shim 网络附加,如下例所示:
shim 网络附加定义示例
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: additionalNetworks: - name: dhcp-shim namespace: default type: Raw rawCNIConfig: |- { "name": "dhcp-shim", "cniVersion": "0.3.1", "type": "bridge", "ipam": { "type": "dhcp" } } # ...
下表描述了使用 DHCP 进行动态 IP 地址地址分配的配置参数。
字段 | 类型 | 描述 |
---|---|---|
|
|
IPAM 地址类型。需要值 |
以下 JSON 示例描述了使用 DHCP 进行动态 IP 地址地址分配的配置 p。
动态 IP 地址(DHCP)分配配置示例
{ "ipam": { "type": "dhcp" } }
18.3.1.2.3. 使用 Whereabouts 进行动态 IP 地址分配配置
Whereabouts CNI 插件允许在不使用 DHCP 服务器的情况下动态地将 IP 地址分配给额外网络。
Whereabouts CNI 插件还支持在单独的 NetworkAttachmentDefinition
CRD 中多次出现同一 CIDR 范围的重叠 IP 地址范围和配置。这在多租户环境中提供了更大的灵活性和管理功能。
18.3.1.2.3.1. 动态 IP 地址配置对象
下表描述了使用 Whereabouts 进行动态 IP 地址分配的配置对象:
字段 | 类型 | 描述 |
---|---|---|
|
|
IPAM 地址类型。需要 |
|
| CIDR 表示法中的 IP 地址和范围。IP 地址是通过这个地址范围来分配的。 |
|
| 可选: CIDR 标记中零个或更多 IP 地址和范围的列表。包含在排除地址范围中的 IP 地址。 |
|
| 可选:帮助确保每个 pod 的组或域都有自己的一组 IP 地址,即使它们共享相同的 IP 地址范围。设置此字段对于保持网络独立和组织非常重要,特别是在多租户环境中。 |
18.3.1.2.3.2. 使用 Whereabouts 的动态 IP 地址分配配置
以下示例显示了使用 Whereabouts 的动态地址分配配置:
Whereabouts 动态 IP 地址分配
{ "ipam": { "type": "whereabouts", "range": "192.0.2.192/27", "exclude": [ "192.0.2.192/30", "192.0.2.196/32" ] } }
18.3.1.2.3.3. 使用 Whereabouts 带有重叠 IP 地址范围的动态 IP 地址分配
以下示例显示了一个动态 IP 地址分配,它将重叠的 IP 地址范围用于多租户网络。
NetworkAttachmentDefinition 1
{
"ipam": {
"type": "whereabouts",
"range": "192.0.2.192/29",
"network_name": "example_net_common", 1
}
}
- 1
- 可选。如果设置,必须与
NetworkAttachmentDefinition 2
的network_name
匹配。
NetworkAttachmentDefinition 2
{
"ipam": {
"type": "whereabouts",
"range": "192.0.2.192/24",
"network_name": "example_net_common", 1
}
}
- 1
- 可选。如果设置,必须与
NetworkAttachmentDefinition 1
的network_name
匹配。
18.3.2. 配置 SR-IOV 额外网络
您可以通过创建一个 SriovNetwork
对象来配置使用 SR-IOV 硬件的额外网络。创建 SriovNetwork
对象时,SR-IOV Network Operator 会自动创建一个 NetworkAttachmentDefinition
对象。
如果一个 SriovNetwork
对象已被附加到状态为 running
的 pod,则不要修改或删除它。
先决条件
-
安装 OpenShift CLI(
oc
)。 -
以具有
cluster-admin
特权的用户身份登录。
流程
创建一个
SriovNetwork
对象,然后在<name>.yaml
文件中保存 YAML,其中<name>
是这个额外网络的名称。对象规格可能类似以下示例:apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: attach1 namespace: openshift-sriov-network-operator spec: resourceName: net1 networkNamespace: project2 ipam: |- { "type": "host-local", "subnet": "10.56.217.0/24", "rangeStart": "10.56.217.171", "rangeEnd": "10.56.217.181", "gateway": "10.56.217.1" }
运行以下命令来创建对象:
$ oc create -f <name>.yaml
这里的
<name>
指定额外网络的名称。可选: 要确认与您在上一步中创建的
SriovNetwork
对象关联的NetworkAttachmentDefinition
对象是否存在,请输入以下命令。将<namespace>
替换为您在SriovNetwork
对象中指定的 networkNamespace。$ oc get net-attach-def -n <namespace>
18.3.3. 将 SR-IOV 网络分配给 VRF
作为集群管理员,您可以使用 CNI VRF 插件为 VRF 域分配 SR-IOV 网络接口。
要做到这一点,将 VRF 配置添加到 SriovNetwork
资源的可选 metaPlugins
参数中。
使用 VRF 的应用程序需要绑定到特定设备。通常的用法是在套接字中使用 SO_BINDTODEVICE
选项。SO_BINDTODEVICE
将套接字绑定到在传递接口名称中指定的设备,例如 eth1
。要使用 SO_BINDTODEVICE
,应用程序必须具有 CAP_NET_RAW
功能。
OpenShift Container Platform pod 不支持通过 ip vrf exec
命令使用 VRF。要使用 VRF,将应用程序直接绑定到 VRF 接口。
18.3.3.1. 使用 CNI VRF 插件创建额外的 SR-IOV 网络附加
SR-IOV Network Operator 管理额外网络定义。当您指定要创建的额外 SR-IOV 网络时,SR-IOV Network Operator 会自动创建 NetworkAttachmentDefinition
自定义资源(CR)。
不要编辑 SR-IOV Network Operator 所管理的 NetworkAttachmentDefinition
自定义资源。这样做可能会破坏额外网络上的网络流量。
要使用 CNI VRF 插件创建额外的 SR-IOV 网络附加,请执行以下步骤。
先决条件
- 安装 OpenShift Container Platform CLI(oc)。
- 以具有 cluster-admin 权限的用户身份登录 OpenShift Container Platform 集群。
流程
为额外 SR-IOV 网络附加创建
SriovNetwork
自定义资源 (CR) 并插入metaPlugins
配置,如下例所示。将 YAML 保存为文件sriov-network-attachment.yaml
。SriovNetwork
自定义资源(CR)示例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 }
创建
SriovNetwork
资源:$ oc create -f sriov-network-attachment.yaml
验证 NetworkAttachmentDefinition
CR 是否已成功创建
运行以下命令,确认 SR-IOV Network Operator 创建了
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 Network Operator 创建 CR 之前可能会有延迟。
验证额外 SR-IOV 网络附加是否成功
要验证 VRF CNI 是否已正确配置并附加额外的 SR-IOV 网络附加,请执行以下操作:
- 创建使用 VRF CNI 的 SR-IOV 网络。
- 将网络分配给 pod。
验证 pod 网络附加是否已连接到 SR-IOV 额外网络。远程 shell 到 pod 并运行以下命令:
$ ip vrf show
输出示例
Name Table ----------------------- red 10
运行以下命令确认 VRF 接口是二级接口的
主
接口:$ ip link
输出示例
... 5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode ...
18.3.4. 基于以太网的 SR-IOV 附加的运行时配置
将 pod 附加到额外网络时,您可以指定运行时配置来为 pod 进行特定的自定义。例如,,您可以请求特定的 MAC 硬件地址。
您可以通过在 pod 规格中设置注解来指定运行时配置。注解键是 k8s.v1.cni.cncf.io/network
,它接受一个 JSON 对象来描述运行时配置。
以下 JSON 描述了基于以太网的 SR-IOV 网络附加的运行时配置选项。
[ { "name": "<name>", 1 "mac": "<mac_address>", 2 "ips": ["<cidr_range>"] 3 } ]
运行时配置示例
apiVersion: v1 kind: Pod metadata: name: sample-pod annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "net1", "mac": "20:04:0f:f1:88:01", "ips": ["192.168.10.1/24", "2001::1/64"] } ] spec: containers: - name: sample-container image: <image> imagePullPolicy: IfNotPresent command: ["sleep", "infinity"]
18.3.5. 将 pod 添加到额外网络
您可以将 pod 添加到额外网络。pod 继续通过默认网络发送与集群相关的普通网络流量。
创建 pod 时会附加额外网络。但是,如果 pod 已存在,您无法为其附加额外网络。
pod 必须与额外网络处于相同的命名空间。
先决条件
-
安装 OpenShift CLI(
oc
)。 - 登录到集群。
流程
为
Pod
对象添加注解。只能使用以下注解格式之一:要在没有自定义的情况下附加额外网络,请使用以下格式添加注解。将
<network>
替换为要与 pod 关联的额外网络的名称:metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 1
- 1
- 要指定多个额外网络,请使用逗号分隔各个网络。逗号之间不可包括空格。如果您多次指定同一额外网络,则该 pod 会将多个网络接口附加到该网络。
要通过自定义来附加额外网络,请添加具有以下格式的注解:
metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>", 1 "namespace": "<namespace>", 2 "default-route": ["<default-route>"] 3 } ]
运行以下命令来创建 pod。将
<name>
替换为 pod 的名称。$ oc create -f <name>.yaml
可选: 要确认
Pod
CR 中是否存在注解,请输入以下命令将<name>
替换为 pod 的名称。$ oc get pod <name> -o yaml
在以下示例中,
example-pod
pod 附加到net1
额外网络:$ oc get pod example-pod -o yaml apiVersion: v1 kind: Pod metadata: annotations: k8s.v1.cni.cncf.io/networks: macvlan-bridge k8s.v1.cni.cncf.io/network-status: |- 1 [{ "name": "ovn-kubernetes", "interface": "eth0", "ips": [ "10.128.2.14" ], "default": true, "dns": {} },{ "name": "macvlan-bridge", "interface": "net1", "ips": [ "20.2.2.100" ], "mac": "22:2f:60:a5:f8:00", "dns": {} }] name: example-pod namespace: default spec: ... status: ...
- 1
k8s.v1.cni.cncf.io/network-status
参数是对象的 JSON 数组。每个对象描述附加到 pod 的额外网络的状态。注解值保存为纯文本值。
18.3.5.1. 向 pod 公开 vfio-pci SR-IOV 设备的 MTU
将 pod 添加到额外网络后,您可以检查 MTU 可供 SR-IOV 网络使用。
流程
运行以下命令,检查 pod 注解是否包含 MTU:
$ oc describe pod example-pod
以下示例显示了输出示例:
"mac": "20:04:0f:f1:88:01", "mtu": 1500, "dns": {}, "device-info": { "type": "pci", "version": "1.1.0", "pci": { "pci-address": "0000:86:01.3" } }
运行以下命令,验证 pod 中的
/etc/podnetinfo/
中是否有 MTU:$ oc exec example-pod -n sriov-tests -- cat /etc/podnetinfo/annotations | grep mtu
以下示例显示了输出示例:
k8s.v1.cni.cncf.io/network-status="[{ \"name\": \"ovn-kubernetes\", \"interface\": \"eth0\", \"ips\": [ \"10.131.0.67\" ], \"mac\": \"0a:58:0a:83:00:43\", \"default\": true, \"dns\": {} },{ \"name\": \"sriov-tests/sriov-nic-1\", \"interface\": \"net1\", \"ips\": [ \"192.168.10.1\" ], \"mac\": \"20:04:0f:f1:88:01\", \"mtu\": 1500, \"dns\": {}, \"device-info\": { \"type\": \"pci\", \"version\": \"1.1.0\", \"pci\": { \"pci-address\": \"0000:86:01.3\" } } }]"
18.3.6. 在 SR-IOV 网络策略更新过程中配置并行节点排空
默认情况下,SR-IOV Network Operator 会在每次策略更改前从节点排空工作负载。Operator 一次执行这个操作,一个节点以确保没有工作负载受到重新配置的影响。
在大型集群中,按顺序排空节点可能非常耗时,需要几小时甚至几天。在时间敏感的环境中,您可以在 SriovNetworkPoolConfig
自定义资源 (CR) 中启用并行节点排空,以更快地推出 SR-IOV 网络配置。
要配置并行排空,请使用 SriovNetworkPoolConfig
CR 创建节点池。然后,您可以在池中添加节点,并在 Operator 可以并行排空的池中定义最大节点数。使用这个方法,您可以启用并行排空来更快地重新配置,同时确保池中仍有足够的节点来处理任何正在运行的工作负载。
节点只能属于一个 SR-IOV 网络池配置。如果节点不是池的一部分,则会将其添加到虚拟(默认)中,该池配置为仅排空一个节点。
节点可能会在排空过程中重启。
先决条件
-
安装 OpenShift CLI(
oc
)。 -
以具有
cluster-admin
特权的用户身份登录。 - 安装 SR-IOV Network Operator。
- 节点具有支持 SR-IOV 的硬件。
流程
创建一个
SriovNetworkPoolConfig
资源:创建一个定义
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: ""
运行以下命令来创建
SriovNetworkPoolConfig
资源:$ oc create -f sriov-nw-pool.yaml
运行以下命令来创建
sriov-test
命名空间:$ oc create namespace sriov-test
创建一个
SriovNetworkNodePolicy
资源:创建一个定义
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
运行以下命令来创建
SriovNetworkNodePolicy
资源:$ oc create -f sriov-node-policy.yaml
创建一个
SriovNetwork
资源:创建一个定义
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" }'
运行以下命令来创建
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
角色的所有节点。
要使用上述流程中的示例场景演示节点排空过程,请完成以下步骤:
更新
SriovNetworkNodePolicy
资源中的虚拟功能数量,以触发集群中的工作负载排空:$ oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'
运行以下命令监控目标集群上的排空状态:
$ 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
18.3.7. 排除 NUMA 感知调度的 SR-IOV 网络拓扑
要将 SR-IOV 网络资源的 Non-Uniform Memory Access (NUMA)节点排除到拓扑管理器,您可以在 SriovNetworkNodePolicy
自定义资源中配置 excludeTopology
规格。在 NUMA 感知 pod 调度过程中,使用此配置来实现更灵活的 SR-IOV 网络部署。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您已将 CPU Manager 策略配置为
static
。有关 CPU Manager 的更多信息,请参阅附加资源部分。 -
您已将 Topology Manager 策略配置为
single-numa-node
。 - 已安装 SR-IOV Network Operator。
流程
创建
SriovNetworkNodePolicy
CR:将以下 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
注意如果多个
SriovNetworkNodePolicy
资源都以同一 SR-IOV 网络资源为目标,则SriovNetworkNodePolicy
资源必须具有与excludeTopology
规格相同的值。否则,冲突策略将被拒绝。运行以下命令来创建
SriovNetworkNodePolicy
资源:$ oc create -f sriov-network-node-policy.yaml
输出示例
sriovnetworknodepolicy.sriovnetwork.openshift.io/policy-for-numa-0 created
创建
SriovNetwork
CR:将以下 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>", }
运行以下命令来创建
SriovNetwork
资源:$ oc create -f sriov-network.yaml
输出示例
sriovnetwork.sriovnetwork.openshift.io/sriov-numa-0-network created
创建 pod 并从上一步中分配 SR-IOV 网络资源:
将以下 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
资源的名称。
运行以下命令来创建
Pod
资源:$ oc create -f sriov-network-pod.yaml
输出示例
pod/example-pod created
验证
运行以下命令,将
<pod_name>
替换为 pod 的名称来验证 pod 的状态:$ oc get pod <pod_name>
输出示例
NAME READY STATUS RESTARTS AGE test-deployment-sriov-76cbbf4756-k9v72 1/1 Running 0 45h
打开目标 pod 的 debug 会话,以验证 SR-IOV 网络资源是否已部署到与内存和 CPU 资源不同的节点上。
运行以下命令,使用 pod 打开 debug 会话,将 <pod_name> 替换为目标 pod 名称。
$ oc debug pod/<pod_name>
将
/host
设为 debug shell 中的根目录。debug pod 从 pod 中的/host
中的主机挂载 root 文件系统。将根目录改为/host
,您可以从主机文件系统中运行二进制文件:$ chroot /host
运行以下命令,查看有关 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 node1
,但 SR-IOV 网络资源可以使用NUMA node0
中的 NIC。
如果 excludeTopology
规格被设置为 True
,则同一 NUMA 节点上可能存在所需资源。