12장. 하드웨어 네트워크
12.1. SR-IOV(Single Root I/O Virtualization) 하드웨어 네트워크 정보
SR-IOV(Single Root I/O Virtualization) 사양은 단일 장치를 여러 Pod와 공유할 수 있는 PCI 장치 할당 유형의 표준입니다.
SR-IOV를 사용하면 호스트 노드에서 물리적 기능(PF)으로 인식되는 호환 네트워크 장치를 여러 VF(가상 기능)로 분할할 수 있습니다. VF는 다른 네트워크 장치와 같이 사용됩니다. 장치의 SR-IOV 장치 드라이버는 컨테이너에서 VF가 노출되는 방식을 결정합니다.
-
netdevice
드라이버: 컨테이너의netns
에 있는 일반 커널 네트워크 장치 -
vfIO-pci
드라이버: 컨테이너에 마운트된 문자 장치
높은 대역폭 또는 짧은 대기 시간이 필요한 애플리케이션의 베어 메탈 또는 RHOSP(Red Hat OpenStack Platform) 인프라에 OpenShift Container Platform 클러스터에서 추가 네트워크와 함께 SR-IOV 네트워크 장치를 사용할 수 있습니다.
다음 명령을 사용하여 노드에서 SR-IOV를 활성화할 수 있습니다.
$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
12.1.1. SR-IOV 네트워크 장치를 관리하는 구성 요소
SR-IOV 네트워크 Operator는 SR-IOV 스택의 구성 요소를 생성하고 관리합니다. 다음과 같은 기능을 수행합니다.
- SR-IOV 네트워크 장치 검색 및 관리 오케스트레이션
-
SR-IOV 컨테이너 네트워크 인터페이스(CNI)에 대한
NetworkAttachmentDefinition
사용자 정의 리소스 생성 - SR-IOV 네트워크 장치 플러그인의 구성 생성 및 업데이트
-
노드별
SriovNetworkNodeState
사용자 정의 리소스 생성 -
각
SriovNetworkNodeState
사용자 정의 리소스에서spec.interfaces
필드 업데이트
Operator는 다음 구성 요소를 프로비저닝합니다.
- SR-IOV 네트워크 구성 데몬
- SR-IOV Operator가 시작될 때 작업자 노드에 배포되는 DaemonSet. 데몬은 클러스터에서 SR-IOV 네트워크 장치를 검색하고 초기화합니다.
- SR-IOV Operator 웹 후크
- Operator 사용자 정의 리소스의 유효성을 검증하고 설정되지 않은 필드에 적절한 기본값을 설정하는 동적 승인 컨트롤러 webhook.
- SR-IOV 네트워크 리소스 인젝터
-
SR-IOV VF와 같은 사용자 정의 네트워크 리소스에 대한 요청 및 제한으로 Kubernetes pod 사양을 패치하는 기능을 제공하는 동적 승인 컨트롤러 webhook. SR-IOV 네트워크 리소스 인젝터는
리소스
필드를 Pod의 첫 번째 컨테이너에 자동으로 추가합니다. - SR-IOV 네트워크 장치 플러그인
- SR-IOV 네트워크 VF(가상 기능) 리소스를 검색, 보급 및 할당하는 장치 플러그인입니다. Kubernetes에서는 장치 플러그인을 사용하여 일반적으로 물리적 장치에서 제한된 리소스를 사용할 수 있습니다. 장치 플러그인은 Kubernetes 스케줄러에 리소스 가용성을 알려 스케줄러가 충분한 리소스가 있는 노드에서 pod를 스케줄링할 수 있도록 합니다.
- SR-IOV CNI 플러그인
- SR-IOV 장치 플러그인에서 할당된 VF 인터페이스를 pod에 직접 연결하는 CNI 플러그인입니다.
- SR-IOV InfiniBand CNI 플러그인
- SR-IOV 장치 플러그인에서 할당된 IB(InfiniBand) VF 인터페이스를 pod에 직접 연결하는 CNI 플러그인입니다.
SR-IOV 네트워크 리소스 인젝터 및 SR-IOV 네트워크 Operator webhook는 기본적으로 활성화되어 있으며 기본
SriovOperatorConfig
CR을 편집하여 비활성화할 수 있습니다.
12.1.1.1. 지원되는 플랫폼
SR-IOV Network Operator는 다음 플랫폼에서 지원됩니다.
- 베어 메탈
- Red Hat OpenStack Platform (RHOSP)
12.1.1.2. 지원되는 장치
OpenShift Container Platform에서는 다음 네트워크 인터페이스 컨트롤러를 지원합니다.
제조업체 | 모델 | 벤더 ID | 장치 ID |
---|---|---|---|
Intel | X710 | 8086 | 1572 |
Intel | XXV710 | 8086 | 158b |
Mellanox | MT27700 제품군 [ConnectX-4] | 15b3 | 1013 |
Mellanox | MT27710 제품군 [ConnectX-4 Lx] | 15b3 | 1015 |
Mellanox | MT27800 제품군 [ConnectX-5] | 15b3 | 1017 |
Mellanox | MT28908 제품군 [ConnectX-6] | 15b3 | 101b |
12.1.1.3. SR-IOV 네트워크 장치의 자동 검색
SR-IOV Network Operator는 작업자 노드에서 SR-IOV 가능 네트워크 장치를 클러스터에서 검색합니다. Operator는 호환되는 SR-IOV 네트워크 장치를 제공하는 각 작업자 노드에 대해 SriovNetworkNodeState CR(사용자 정의 리소스)을 생성하고 업데이트합니다.
CR에는 작업자 노드와 동일한 이름이 할당됩니다. status.interfaces
목록은 노드의 네트워크 장치에 대한 정보를 제공합니다.
SriovNetworkNodeState
오브젝트를 수정하지 마십시오. Operator는 이러한 리소스를 자동으로 생성하고 관리합니다.
12.1.1.3.1. SriovNetworkNodeState 오브젝트의 예
다음 YAML은 SR-IOV Network Operator가 생성한 SriovNetworkNodeState
오브젝트의 예입니다.
SriovNetworkNodeState 오브젝트
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodeState metadata: name: node-25 1 namespace: openshift-sriov-network-operator ownerReferences: - apiVersion: sriovnetwork.openshift.io/v1 blockOwnerDeletion: true controller: true kind: SriovNetworkNodePolicy name: default spec: dpConfigVersion: "39824" status: interfaces: 2 - deviceID: "1017" driver: mlx5_core mtu: 1500 name: ens785f0 pciAddress: "0000:18:00.0" totalvfs: 8 vendor: 15b3 - deviceID: "1017" driver: mlx5_core mtu: 1500 name: ens785f1 pciAddress: "0000:18:00.1" totalvfs: 8 vendor: 15b3 - deviceID: 158b driver: i40e mtu: 1500 name: ens817f0 pciAddress: 0000:81:00.0 totalvfs: 64 vendor: "8086" - deviceID: 158b driver: i40e mtu: 1500 name: ens817f1 pciAddress: 0000:81:00.1 totalvfs: 64 vendor: "8086" - deviceID: 158b driver: i40e mtu: 1500 name: ens803f0 pciAddress: 0000:86:00.0 totalvfs: 64 vendor: "8086" syncStatus: Succeeded
12.1.1.4. Pod에서 가상 함수 사용 예
SR-IOV VF가 연결된 pod에서 RDMA(Remote Direct Memory Access) 또는 DPDK(Data Plane Development Kit) 애플리케이션을 실행할 수 있습니다.
이 예는 RDMA 모드에서 VF(가상 기능)를 사용하는 pod를 보여줍니다.
RDMA 모드를 사용하는 Pod
사양
apiVersion: v1 kind: Pod metadata: name: rdma-app annotations: k8s.v1.cni.cncf.io/networks: sriov-rdma-mlnx spec: containers: - name: testpmd image: <RDMA_image> imagePullPolicy: IfNotPresent securityContext: runAsUser: 0 capabilities: add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] command: ["sleep", "infinity"]
다음 예는 DPDK 모드에서 VF가 있는 pod를 보여줍니다.
DPDK 모드를 사용하는 Pod
사양
apiVersion: v1 kind: Pod metadata: name: dpdk-app annotations: k8s.v1.cni.cncf.io/networks: sriov-dpdk-net spec: containers: - name: testpmd image: <DPDK_image> securityContext: runAsUser: 0 capabilities: add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] volumeMounts: - mountPath: /dev/hugepages name: hugepage resources: limits: memory: "1Gi" cpu: "2" hugepages-1Gi: "4Gi" requests: memory: "1Gi" cpu: "2" hugepages-1Gi: "4Gi" command: ["sleep", "infinity"] volumes: - name: hugepage emptyDir: medium: HugePages
Pod와 관련된 네트워크 정보를 수집할 때 컨테이너에서 실행되는 애플리케이션을 돕기 위해 선택적 라이브러리를 사용할 수 있습니다. 이 라이브러리를 'app-netutil'이라고 합니다. app-netutil
GitHub repo에서 라이브러리의 소스 코드를 참조하십시오.
이 라이브러리는 DPDK 모드의 SR-IOV VF를 컨테이너에 쉽게 통합할 수 있도록 고안되었습니다. 라이브러리는 GO API 및 C API와 두 언어 사용 예를 모두 제공합니다.
pod-spec의 환경 변수 l2fwd, l3wd 또는 testpmd와 같은 DPDK 샘플 애플리케이션 중 하나를 실행할 수 있는 샘플 Docker 이미지 'dpdk-app-centos'도 있습니다. 이 Docker 이미지는 'app-netutil'을 컨테이너 이미지 자체에 통합하는 예를 제공합니다. 라이브러리는 원하는 데이터를 수집하고 기존 DPDK 워크로드로 데이터를 전달하는 초기화 컨테이너에 통합할 수도 있습니다.
12.1.2. 다음 단계
- SR-IOV Network Operator 설치
- 선택 사항: SR-IOV Network Operator 구성
- SR-IOV 네트워크 장치 구성
- OpenShift Virtualization을 사용하는 경우: 가상 머신의 SR-IOV 네트워크 장치 구성
- SR-IOV 네트워크 연결 구성
- SR-IOV 추가 네트워크에 pod 추가