20장. 하드웨어 네트워크
20.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"
20.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가 시작될 때 작업자 노드에 배포되는 데몬 세트입니다. 데몬은 클러스터에서 SR-IOV 네트워크 장치를 검색하고 초기화합니다.
- SR-IOV 네트워크 Operator webhook
- 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을 편집하여 비활성화할 수 있습니다. SR-IOV Network Operator Admission Controller 웹 후크를 비활성화할 때 주의하십시오. 문제 해결과 같은 특정 상황에서 웹 후크를 비활성화하거나 지원되지 않는 장치를 사용하려는 경우 사용할 수 있습니다.
20.1.1.1. 지원되는 플랫폼
SR-IOV Network Operator는 다음 플랫폼에서 지원됩니다.
- 베어 메탈
- Red Hat OpenStack Platform (RHOSP)
20.1.1.2. 지원되는 장치
OpenShift Container Platform에서는 다음 네트워크 인터페이스 컨트롤러를 지원합니다.
| 제조업체 | 모델 | 벤더 ID | 장치 ID |
|---|---|---|---|
| Broadcom | BCM57414 | 14e4 | 16d7 |
| Broadcom | BCM57508 | 14e4 | 1750 |
| Intel | X710 | 8086 | 1572 |
| Intel | XL710 | 8086 | 1583 |
| Intel | XXV710 | 8086 | 158b |
| Intel | E810-CQDA2 | 8086 | 1592 |
| Intel | E810-2CQDA2 | 8086 | 1592 |
| Intel | E810-XXVDA2 | 8086 | 159b |
| Intel | E810-XXVDA4 | 8086 | 1593 |
| Mellanox | MT27700 제품군 [ConnectX-4] | 15b3 | 1013 |
| Mellanox | MT27710 제품군 [ConnectX-4 Lx] | 15b3 | 1015 |
| Mellanox | MT27800 제품군 [ConnectX-5] | 15b3 | 1017 |
| Mellanox | MT28880 제품군 [ConnectX-5 Ex] | 15b3 | 1019 |
| Mellanox | MT28908 제품군 [ConnectX-6] | 15b3 | 101b |
| Mellanox | MT2892 제품군 [ConnectX-6 Dx] | 15b3 | 101d |
| Mellanox | MT2894 제품군 [ConnectX-6 Lx] | 15b3 | 101f |
| Pensando [1] | DSC-25 듀얼 포트 25G 분산 서비스 카드 ionic 드라이버 | 0x1dd8 | 0x1002 |
| Pensando [1] | ionic 드라이버용 DSC-100 듀얼 포트 100G 분산 서비스 카드 | 0x1dd8 | 0x1003 |
- OpenShift SR-IOV는 지원되지만 SR-IOV를 사용할 때 SR-IOV를 사용할 때 SR-IOV CNI 구성 파일을 사용하여 정적인 VF(가상 기능) 미디어 액세스 제어(MAC) 주소를 설정해야 합니다.
지원되는 카드 및 호환 가능한 OpenShift Container Platform 버전의 최신 목록은 Openshift Single Root I/O Virtualization(SR-IOV) 및 PTP 하드웨어 네트워크 지원 매트릭스 를 참조하십시오.
20.1.1.3. SR-IOV 네트워크 장치의 자동 검색
SR-IOV Network Operator는 작업자 노드에서 SR-IOV 가능 네트워크 장치를 클러스터에서 검색합니다. Operator는 호환되는 SR-IOV 네트워크 장치를 제공하는 각 작업자 노드에 대해 SriovNetworkNodeState CR(사용자 정의 리소스)을 생성하고 업데이트합니다.
CR에는 작업자 노드와 동일한 이름이 할당됩니다. status.interfaces 목록은 노드의 네트워크 장치에 대한 정보를 제공합니다.
SriovNetworkNodeState 오브젝트를 수정하지 마십시오. Operator는 이러한 리소스를 자동으로 생성하고 관리합니다.
20.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
20.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
20.1.1.5. 컨테이너 애플리케이션에서 사용하는 DPDK 라이브러리
선택적 라이브러리인 app-netutil은 해당 포드에서 실행 중인 컨테이너 내에서 포드에 관한 네트워크 정보를 수집하기 위해 여러 API 메서드를 제공합니다.
이 라이브러리는 DPDK(Data Plane Development Kit) 모드의 SR-IOV VF(가상 기능)를 컨테이너에 통합하는 데 도움이 될 수 있습니다. 라이브러리는 Golang API와 C API를 모두 제공합니다.
현재 세 가지 API 메서드가 구현되어 있습니다.
GetCPUInfo()- 이 함수는 컨테이너에서 사용할 수 있는 CPU를 결정하고 목록을 반환합니다.
GetHugepages()-
이 함수는 각 컨테이너에 대해
Pod사양에서 요청된 대량의 페이지 메모리의 양을 결정하고 값을 반환합니다. GetInterfaces()- 이 함수는 컨테이너의 인터페이스 집합을 결정하고 목록을 반환합니다. 반환 값에는 각 인터페이스에 대한 인터페이스 유형 및 유형별 데이터가 포함됩니다.
라이브러리 리포지토리에는 컨테이너 이미지 dpdk-app-centos를 빌드하는 샘플 Dockerfile이 포함되어 있습니다. 컨테이너 이미지는 pod 사양의 환경 변수에 따라 다음 DPDK 샘플 애플리케이션 중 하나를 실행할 수 있습니다. l2fwd,l3wd 또는 testpmd. 컨테이너 이미지는 app-netutil 라이브러리를 컨테이너 이미지 자체에 통합하는 예를 제공합니다. 라이브러리는 init 컨테이너에 통합할 수도 있습니다. init 컨테이너는 필요한 데이터를 수집하고 기존 DPDK 워크로드에 데이터를 전달할 수 있습니다.
20.1.1.6. Downward API 에 대한 대규보 페이지 리소스 주입
Pod 사양에 대규모 페이지에 대한 리소스 요청 또는 제한이 포함된 경우 Network Resources Injector는 컨테이너에 대규모 페이지 정보를 제공하기 위해 Pod 사양에 Downward API 필드를 자동으로 추가합니다.
Network Resources Injector는 podnetinfo라는 볼륨을 추가하고 Pod의 각 컨테이너에 대해 /etc/podnetinfo에 마운트됩니다. 볼륨은 Downward API를 사용하며 대규모 페이지 요청 및 제한에 대한 파일을 포함합니다. 파일 이름 지정 규칙은 다음과 같습니다.
-
/etc/podnetinfo/hugepages_1G_request_<container-name> -
/etc/podnetinfo/hugepages_1G_limit_<container-name> -
/etc/podnetinfo/hugepages_2M_request_<container-name> -
/etc/podnetinfo/hugepages_2M_limit_<container-name>
이전 목록에 지정된 경로는 app-netutil 라이브러리와 호환됩니다. 기본적으로 라이브러리는 /etc/podnetinfo 디렉터리에서 리소스 정보를 검색하도록 구성됩니다. Downward API 경로 항목을 수동으로 지정하도록 선택하는 경우 app-netutil 라이브러리는 이전 목록의 경로 외에도 다음 경로를 검색합니다.
-
/etc/podnetinfo/hugepages_request -
/etc/podnetinfo/hugepages_limit -
/etc/podnetinfo/hugepages_1G_request -
/etc/podnetinfo/hugepages_1G_limit -
/etc/podnetinfo/hugepages_2M_request -
/etc/podnetinfo/hugepages_2M_limit
Network Resources Injector에서 생성할 수 있는 경로와 마찬가지로, 이전 목록의 경로는 선택적으로 _<container-name> 접미사로 종료할 수 있습니다.
20.1.2. 다음 단계
- SR-IOV Network Operator 설치
- 선택사항: SR-IOV Network Operator 구성
- SR-IOV 네트워크 장치 구성
- OpenShift Virtualization을 사용하는 경우: 가상 머신을 SR-IOV 네트워크에 연결
- SR-IOV 네트워크 연결 구성
- SR-IOV 추가 네트워크에 pod 추가
