23장. 하드웨어 네트워크

23.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 네트워크에 대한 다중 네트워크 정책을 구성할 수 있습니다. 이에 대한 지원은 기술 프리뷰이며 SR-IOV 추가 네트워크는 커널 NIC에서만 지원됩니다. DPDK(Data Plane Development Kit) 애플리케이션에서는 지원되지 않습니다.

참고

SR-IOV 네트워크에서 다중 네트워크 정책을 생성하면 다중 네트워크 정책이 구성되지 않은 SR-IOV 네트워크와 비교하여 애플리케이션에 동일한 성능을 제공하지 못할 수 있습니다.

중요

SR-IOV 네트워크의 다중 네트워크 정책은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

다음 명령을 사용하여 노드에서 SR-IOV를 활성화할 수 있습니다.

$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"

23.1.1. SR-IOV 네트워크 장치를 관리하는 구성 요소

SR-IOV 네트워크 Operator는 SR-IOV 스택의 구성 요소를 생성하고 관리합니다. 다음과 같은 기능을 수행합니다.

  • SR-IOV 네트워크 장치 검색 및 관리 오케스트레이션
  • SR-IOV CNI(Container Network Interface)에 대한 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 웹 후크를 비활성화할 때 주의하십시오. 문제 해결과 같은 특정 상황에서 웹 후크를 비활성화하거나 지원되지 않는 장치를 사용하려는 경우 사용할 수 있습니다.

23.1.1.1. 지원되는 플랫폼

SR-IOV Network Operator는 다음 플랫폼에서 지원됩니다.

  • 베어 메탈
  • Red Hat OpenStack Platform (RHOSP)

23.1.1.2. 지원되는 장치

OpenShift Container Platform에서는 다음 네트워크 인터페이스 컨트롤러를 지원합니다.

표 23.1. 지원되는 네트워크 인터페이스 컨트롤러

제조업체모델벤더 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

Mellanox

ConnectX-6 NIC 모드의 MT42822 BlueField-2

15b3

a2d6

펜산도 [1]

DSC-25 듀얼 포트 25G 분산 서비스 카드 ionic 드라이버

0x1dd8

0x1002

펜산도 [1]

ionic 드라이버용 DSC-100 듀얼 포트 100G 분산 서비스 카드

0x1dd8

0x1003

Silicom

STS Family

8086

1591

  1. OpenShift SR-IOV는 지원되지만 SR-IOV를 사용할 때 SR-IOV CNI 구성 파일을 사용하여 고정 VF(가상 기능) 미디어 액세스 제어(MAC) 주소를 설정해야 합니다.
참고

지원되는 카드 및 호환 가능한 OpenShift Container Platform 버전에 대한 최신 목록은 Openshift SR-IOV(Single Root I/O Virtualization) 및 PTP 하드웨어 네트워크 지원 매트릭스 를 참조하십시오.

23.1.1.3. SR-IOV 네트워크 장치의 자동 검색

SR-IOV Network Operator는 작업자 노드에서 SR-IOV 가능 네트워크 장치를 클러스터에서 검색합니다. Operator는 호환되는 SR-IOV 네트워크 장치를 제공하는 각 작업자 노드에 대해 SriovNetworkNodeState CR(사용자 정의 리소스)을 생성하고 업데이트합니다.

CR에는 작업자 노드와 동일한 이름이 할당됩니다. status.interfaces 목록은 노드의 네트워크 장치에 대한 정보를 제공합니다.

중요

SriovNetworkNodeState 오브젝트를 수정하지 마십시오. Operator는 이러한 리소스를 자동으로 생성하고 관리합니다.

23.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

1
name 필드의 값은 작업자 노드의 이름과 동일합니다.
2
인터페이스 스탠자에는 작업자 노드에서 Operator가 검색한 모든 SR-IOV 장치 목록이 포함되어 있습니다.

23.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

23.1.1.5. 컨테이너 애플리케이션에서 사용하는 DPDK 라이브러리

선택적 라이브러리app-netutil 은 해당 Pod 내에서 실행되는 컨테이너 내에서 포드에 대한 네트워크 정보를 수집하기 위한 여러 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 워크로드에 데이터를 전달할 수 있습니다.

23.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 > 접미사로 종료할 수 있습니다.

23.1.2. 추가 리소스

23.1.3. 다음 단계