24.4. SR-IOV 네트워크 장치 구성
클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치를 구성할 수 있습니다.
24.4.1. 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 nicSelector: 9 vendor: "<vendor_code>" 10 deviceID: "<device_id>" 11 pfNames: ["<pf_name>", ...] 12 rootDevices: ["<pci_bus_id>", ...] 13 netFilter: "<filter_string>" 14 deviceType: <device_type> 15 isRdma: false 16 linkType: <link_type> 17 eSwitchMode: <mode> 18 excludeTopology: false 19
- 1
- 사용자 정의 리소스 오브젝트의 이름입니다.
- 2
- SR-IOV Network Operator가 설치된 네임스페이스입니다.
- 3
- SR-IOV 네트워크 장치 플러그인의 리소스 이름입니다. 리소스 이름에 대한 SR-IOV 네트워크 노드 정책을 여러 개 생성할 수 있습니다.
이름을 지정할 때
resourceName
에 허용되는 구문 표현식^[a-zA-Z0-9_]+$
를 사용해야 합니다. - 4
- 노드 선택기는 구성할 노드를 지정합니다. 선택한 노드의 SR-IOV 네트워크 장치만 구성됩니다. SR-IOV CNI(Container Network Interface) 플러그인 및 장치 플러그인은 선택한 노드에만 배포됩니다.중요
SR-IOV Network Operator는 노드 네트워크 구성 정책을 순서대로 노드에 적용합니다. 노드 네트워크 구성 정책을 적용하기 전에 SR-IOV Network Operator는 노드의 MCP(Machine config pool)가
Degraded
또는 Update와 같은 비정상적인 상태에 있는지확인합니다
. 노드가 비정상 MCP에 있는 경우 MCP가 정상 상태로 돌아올 때까지 클러스터의 모든 대상 노드에 노드 네트워크 구성 정책을 적용하는 프로세스입니다.비정상 MCP의 노드가 다른 MCP의 노드를 포함하여 다른 노드에 대한 노드 네트워크 구성 정책의 애플리케이션을 차단하지 않도록 하려면 각 MCP에 대한 별도의 노드 네트워크 구성 정책을 생성해야 합니다.
- 5
- 선택 사항: 우선순위는
0
에서99
사이의 정수 값입니다. 작은 값은 우선순위가 높습니다. 예를 들어 우선순위10
은 우선순위99
보다 높습니다. 기본값은99
입니다. - 6
- 선택사항: 가상 기능의 최대 전송 단위(MTU)입니다. 최대 MTU 값은 네트워크 인터페이스 컨트롤러(NIC) 모델마다 다를 수 있습니다.중요
기본 네트워크 인터페이스에서 가상 기능을 생성하려면 MTU가 클러스터 MTU와 일치하는 값으로 설정되어 있는지 확인합니다.
- 7
- 선택 사항: pod에
/dev/vhost-net
장치를 마운트하려면needVhostNet
을true
로 설정합니다. DPDK(Data Plane Development Kit)와 함께 마운트된/dev/vhost-net
장치를 사용하여 트래픽을 커널 네트워크 스택으로 전달합니다. - 8
- SR-IOV 물리적 네트워크 장치에 생성할 VF(가상 기능) 수입니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는
127
보다 클 수 없습니다. - 9
- NIC 선택기는 Operator가 구성할 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다.
rootDevices
를 지정하면vendor
,deviceID
또는pfNames
의 값도 지정해야 합니다.pfNames
와rootDevices
를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오.netFilter
의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다. - 10
- 선택 사항: SR-IOV 네트워크 장치의 벤더 16진수 코드입니다. 허용되는 값은
8086
및15b3
입니다. - 11
- 선택사항: SR-IOV 네트워크 장치의 장치 16진수 코드입니다. 예를 들어
101b
는 Mellanox ConnectX-6 장치의 장치 ID입니다. - 12
- 선택사항: 장치에 대해 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.
- 13
- 선택 사항: 장치의 PF에 대해 하나 이상의 PCI 버스 주소로 구성된 배열입니다. 주소를
0000:02: 00.1
형식으로 입력합니다. - 14
- 선택 사항: 플랫폼별 네트워크 필터입니다. 지원되는 유일한 플랫폼은 RHOSP(Red Hat OpenStack Platform)입니다. 허용 가능한 값은 다음 형식을 사용합니다.
openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
를/var/config/openstack/latest/network_data.json
메타데이터 파일의 값으로 바꿉니다. - 15
- 선택사항: 가상 기능의 드라이버 유형입니다. 허용되는 값은
netdevice
및vfio-pci
입니다. 기본값은netdevice
입니다.베어 메탈 노드의 DPDK 모드에서 Mellanox NIC가 작동하려면
netdevice
드라이버 유형을 사용하고isRdma
를true
로 설정합니다. - 16
- 선택 사항: 원격 직접 메모리 액세스(RDMA) 모드를 활성화할지 여부를 구성합니다. 기본값은
false
입니다.isRdma
매개변수가true
로 설정된 경우 RDMA 사용 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다.isRdma
를true
로 설정하고 추가로needVhostNet
을true
로 설정하여 Fast Datapath DPDK 애플리케이션에서 사용할 Mellanox NIC를 구성합니다.참고intel NIC의 경우
isRdma
매개변수를true
로 설정할 수 없습니다. - 17
- 선택사항: VF의 링크 유형입니다. 기본값은
eth
이더넷입니다. 이 값을 InfiniBand의 'ib'로 변경합니다.linkType
을ib
로 설정하면isRdma
가 SR-IOV Network Operator 웹 후크에 의해 자동으로true
로 설정됩니다.linkType
을ib
로 설정하면deviceType
을vfio-pci
로 설정해서는 안 됩니다.SriovNetworkNodePolicy에 대해 linkType을 'eth'로 설정하지 마십시오. 장치 플러그인에서 보고한 사용 가능한 장치가 잘못된 수 있기 때문입니다.
- 18
- 선택사항: NIC 장치 모드입니다. 허용되는 유일한 값은
legacy
또는switchdev
입니다.eSwitchMode
가legacy
로 설정되면 기본 SR-IOV 동작이 활성화됩니다.eSwitchMode
가switchdev
로 설정되면 하드웨어 오프로드가 활성화됩니다. - 19
- 선택 사항: SR-IOV 네트워크 리소스의 NUMA 노드를 토폴로지 관리자로 알리려면 값을
true
로 설정합니다. 기본값은false
입니다.
24.4.1.1. 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
24.4.1.2. SR-IOV 장치의 VF(가상 기능) 파티셔닝
경우에 따라 동일한 물리적 기능(PF)의 VF(가상 기능)를 여러 리소스 풀로 분할할 수 있습니다. 예를 들어, 일부 VF를 기본 드라이버로 로드하고 나머지 VF를vfio-pci
드라이버로 로드할 수 있습니다. 이러한 배포에서 SriovNetworkNodePolicy CR(사용자 정의 리소스)의 pfNames
선택기를 사용하여 <pfname>#<first_vf>-<last_vf>
형식을 사용하여 풀의 VF 범위를 지정할 수 있습니다.
예를 들어 다음 YAML은 VF 2
에서 7
까지의 netpf0
인터페이스에 대한 선택기를 보여줍니다.
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
은 기본 VF 드라이버와 함께 PF netpf0
의 VF 0
을 포함하는 리소스 풀 net-1
을 정의합니다. 정책 policy-net-1-dpdk
는 vfio
VF 드라이버와 함께 PF netpf0
의 VF 8
~ 15
를 포함하는 리소스 풀 net-1-dpdk
를 정의합니다.
정책 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
- &
lt;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
24.4.2. SR-IOV 네트워크 장치 구성
SR-IOV Network Operator는 SriovNetworkNodePolicy.sriovnetwork.openshift.io
CustomResourceDefinition을 OpenShift Container Platform에 추가합니다. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 만들어 SR-IOV 네트워크 장치를 구성할 수 있습니다.
SriovNetworkNodePolicy
오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다.
구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - SR-IOV Network Operator가 설치되어 있습니다.
- 비운 노드에서 제거된 워크로드를 처리하기 위해 클러스터에 사용 가능한 노드가 충분합니다.
- SR-IOV 네트워크 장치 구성에 대한 컨트롤 플레인 노드를 선택하지 않았습니다.
절차
-
SriovNetworkNodePolicy
오브젝트를 생성한 후 YAML을<name>-sriov-node-network.yaml
파일에 저장합니다.<name>
을 이 구성의 이름으로 바꿉니다. -
선택 사항:
SriovNetworkNodePolicy.Spec.NodeSelector
를 사용하여 SR-IOV 가능 클러스터 노드에 레이블을 지정하지 않은 경우 레이블을 지정합니다. 노드에 레이블 지정에 대한 자세한 내용은 "노드에서 라벨을 업데이트하는 방법"을 참조하십시오. SriovNetworkNodePolicy
오브젝트를 생성합니다.$ oc create -f <name>-sriov-node-network.yaml
<name>
은 이 구성의 이름을 지정합니다.구성 업데이트를 적용하면
sriov-network-operator
네임스페이스의 모든 Pod가Running
상태로 전환됩니다.SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다.
<node_name>
을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다.$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
추가 리소스
24.4.3. 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"
노드가 메모리를 할당할 수 없음을 나타내는 경우 다음 항목을 확인합니다.
- 글로벌 SR-IOV 설정이 노드의 BIOS에서 활성화되어 있는지 확인합니다.
- BIOS에서 노드에 대해 VT-d가 활성화되어 있는지 확인합니다.
24.4.4. SR-IOV 네트워크를 VRF에 할당
클러스터 관리자는 CNI VRF 플러그인을 사용하여 SR-IOV 네트워크 인터페이스를 VRF 도메인에 할당할 수 있습니다.
이렇게 하려면 SriovNetwork
리소스의 선택적 metaPlugins
매개변수에 VRF 구성을 추가합니다.
VRF를 사용하는 애플리케이션은 특정 장치에 바인딩해야 합니다. 일반적인 사용은 소켓에 SO_BINDTODEVICE
옵션을 사용하는 것입니다. SO_BINDTODEVICE
는 소켓을 전달된 인터페이스 이름(예: eth1
)에 지정된 장치에 바인딩합니다. SO_BINDTODEVICE
를 사용하려면 애플리케이션에 CAP_NET_RAW
기능이 있어야 합니다.
OpenShift Container Platform Pod에서는 ip vrf exec
명령을 통해 VRF를 사용할 수 없습니다. VRF를 사용하려면 애플리케이션을 VRF 인터페이스에 직접 바인딩합니다.
24.4.4.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(사용자 정의 리소스)을 생성하고 다음 예제 CR과 같이metaPlugins
구성을 삽입합니다. 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 }
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 네트워크를 생성합니다.
- 포드에 네트워크를 할당합니다.
포드 네트워크 연결이 SR-IOV 추가 네트워크에 연결되어 있는지 확인합니다. 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 ...
24.4.5. NUMA 인식 스케줄링의 SR-IOV 네트워크 토폴로지 제외
SR-IOV 네트워크의 NUMA(Non-Uniform Memory Access) 노드를 토폴로지 관리자에게 알리면 NUMA 인식 Pod 예약 중에 보다 유연한 SR-IOV 네트워크 배포를 제외할 수 있습니다.
일부 시나리오에서는 단일 NUMA 노드에서 Pod의 CPU 및 메모리 리소스를 최대화하는 것이 우선 순위입니다. 토폴로지 관리자는 Pod의 SR-IOV 네트워크 리소스에 대한 NUMA 노드에 대한 힌트를 제공하지 않기 때문에 토폴로지 관리자는 SR-IOV 네트워크 리소스 및 Pod CPU 및 메모리 리소스를 다른 NUMA 노드에 배포할 수 있습니다. NUMA 노드 간 데이터 전송으로 인해 네트워크 대기 시간에 추가할 수 있습니다. 그러나 워크로드에 최적의 CPU 및 메모리 성능이 필요한 경우에는 이 기능이 허용됩니다.
예를 들어 numa0
과 numa1
이라는 두 개의 NUMA 노드가 있는 컴퓨팅 노드인 compute-1
을 고려해 보십시오. SR-IOV 지원 NIC는 numa0
에 있습니다. Pod 예약에 사용 가능한 CPU는 numa1
에만 있습니다. Topology Manager는 excludeTopology
사양을 true
로 설정하여 Pod의 CPU 및 메모리 리소스를 numa1
에 할당할 수 있으며 동일한 pod의 SR-IOV 네트워크 리소스를 numa0
에 할당할 수 있습니다. 이는 excludeTopology
사양을 true
로 설정한 경우에만 가능합니다. 그렇지 않으면 토폴로지 관리자가 동일한 NUMA 노드에 모든 리소스를 배치하려고 합니다.
24.4.5.1. NUMA 인식 스케줄링을 위한 SR-IOV 네트워크 토폴로지 제외
SR-IOV 네트워크 리소스의 NUMA(Non-Uniform Memory Access) 노드를 토폴로지 관리자로 알리기 위해 SriovNetworkNodePolicy
사용자 정의 리소스에서 excludeTopology
사양을 구성할 수 있습니다. NUMA 인식 Pod 예약 중에 보다 유연한 SR-IOV 네트워크 배포를 위해 이 구성을 사용합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
CPU 관리자 정책을
static
으로 구성했습니다. CPU 관리자에 대한 자세한 내용은 추가 리소스 섹션을 참조하십시오. -
토폴로지 관리자 정책을
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의 상태를 확인하고 <
pod_name>
을 Pod 이름으로 교체합니다.$ oc get pod <pod_name>
출력 예
NAME READY STATUS RESTARTS AGE test-deployment-sriov-76cbbf4756-k9v72 1/1 Running 0 45h
대상 Pod로 디버그 세션을 열어 SR-IOV 네트워크 리소스가 메모리 및 CPU 리소스와 다른 노드에 배포되었는지 확인합니다.
다음 명령을 실행하여 Pod로 디버그 세션을 열고 <pod_name>을 대상 Pod 이름으로 교체합니다.
$ oc debug pod/<pod_name>
디버그 쉘 내에서
/host
를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의/host
에 호스트의 root 파일 시스템을 마운트합니다. 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 노드에 존재할 수 있습니다.
추가 리소스