하드웨어 네트워크


OpenShift Container Platform 4.19

OpenShift Container Platform에서 하드웨어별 네트워킹 기능 구성

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform에서 SR-IOV(Single Root I/O Virtualization) 및 기타 하드웨어별 네트워크 최적화를 구성하는 방법을 다룹니다.

1장. SR-IOV(Single Root I/O Virtualization) 하드웨어 네트워크 정보

SR-IOV(Single Root I/O Virtualization) 사양은 단일 장치를 여러 Pod와 공유할 수 있는 PCI 장치 할당 유형의 표준입니다.

SR-IOV Operator를 사용하여 클러스터에서 SR-IOV(단일 루트 I/O 가상화) 장치를 구성할 수 있습니다.

SR-IOV를 사용하면 호스트 노드에서 물리적 기능(PF)으로 인식되는 호환 네트워크 장치를 여러 VF(가상 기능)로 분할할 수 있습니다. VF는 다른 네트워크 장치와 같이 사용됩니다. 장치의 SR-IOV 네트워크 장치 드라이버는 컨테이너에서 VF가 노출되는 방식을 결정합니다.

  • netdevice 드라이버: 컨테이너의 netns에 있는 일반 커널 네트워크 장치
  • vfio-pci 드라이버: 컨테이너에 마운트된 문자 장치

베어 메탈 또는 Red Hat OpenStack Platform(RHOSP) 인프라에 설치된 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"
Copy to Clipboard Toggle word wrap

추가 리소스

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 네트워크 리소스 인젝터는 포드의 첫 번째 컨테이너에만 리소스 필드를 자동으로 추가합니다.
SR-IOV 네트워크 장치 플러그인
SR-IOV 네트워크 가상 기능(VF) 리소스를 검색, 광고 및 할당하는 장치 플러그인입니다. 장치 플러그인은 Kubernetes에서 물리적 장치에 있는 제한된 리소스를 사용할 수 있도록 하는 데 사용됩니다. 장치 플러그인은 Kubernetes 스케줄러에 리소스 가용성에 대한 인식을 제공하므로 스케줄러는 충분한 리소스가 있는 노드에 Pod를 스케줄링할 수 있습니다.
SR-IOV CNI 플러그인
SR-IOV 네트워크 장치 플러그인에서 할당된 VF 인터페이스를 포드에 직접 연결하는 CNI 플러그인입니다.
SR-IOV InfiniBand CNI 플러그인
SR-IOV 네트워크 장치 플러그인에서 할당된 InfiniBand(IB) VF 인터페이스를 Pod에 직접 연결하는 CNI 플러그인입니다.
참고

SR-IOV 네트워크 리소스 인젝터 및 SR-IOV 네트워크 Operator webhook는 기본적으로 활성화되어 있으며 기본 SriovOperatorConfig CR을 편집하여 비활성화할 수 있습니다. SR-IOV 네트워크 운영자 입장 컨트롤러 웹훅을 비활성화할 때는 주의하세요. 문제 해결이나 지원되지 않는 기기를 사용하려는 경우와 같이 특정 상황에서는 웹훅을 비활성화할 수 있습니다.

1.1.1. 지원되는 플랫폼

SR-IOV 네트워크 운영자는 다음 플랫폼에서 지원됩니다.

  • 베어 메탈
  • Red Hat 오픈스택 플랫폼(RHOSP)

1.1.2. 지원되는 장치

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

Expand
표 1.1. 지원되는 네트워크 인터페이스 컨트롤러
제조업체모델벤더 ID장치 ID

브로드컴

BCM57414

14e4

16d7

브로드컴

BCM57508

14e4

1750

브로드컴

BCM57504

14e4

1751

Intel

X710

8086

1572

Intel

X710 Backplane

8086

1581

Intel

X710 Base T

8086

15% 할인

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

Intel

E810-XXVDA4T

8086

1593

Intel

E810-XXV 백플레인

8086

1599

Intel

E823L 백플레인

8086

124c

Intel

E823L SFP

8086

124d

Intel

E825-C 백플레인

8086

579c

Intel

E825-C QSFP

8086

579d

Intel

E825-C SFP

8086

579e

마벨

옥테온 퓨전 CNF105XX

177d

ba00

마벨

옥테온10 CN10XXX

177d

b900

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 Family [ConnectX‑6 Dx]

15b3

101d

Mellanox

MT2894 제품군 [ConnectX‑6 Lx]

15b3

101f

Mellanox

Mellanox MT2910 Family [ConnectX‑7]

15b3

1021

Mellanox

ConnectX‑6 NIC 모드의 MT42822 BlueField‑2

15b3

a2d6

펜산도 [1]

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

0x1dd8

0x1002

펜산도 [1]

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

0x1dd8

0x1003

실리콤

STS 가족

8086

1591

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

지원되는 카드와 호환되는 OpenShift Container Platform 버전의 최신 목록을 보려면 Openshift Single Root I/O Virtualization(SR-IOV) 및 PTP 하드웨어 네트워크 지원 매트릭스를 참조하세요.

1.3. 다음 단계

2장. SR-IOV 네트워크 장치 구성

클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치를 구성할 수 있습니다.

다음 문서의 작업을 수행하기 전에 SR-IOV 네트워크 운영자가 설치되어 있는지 확인하세요.

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

  externallyManaged: false 
9

  nicSelector: 
10

    vendor: "<vendor_code>" 
11

    deviceID: "<device_id>" 
12

    pfNames: ["<pf_name>", ...] 
13

    rootDevices: ["<pci_bus_id>", ...] 
14

    netFilter: "<filter_string>" 
15

  deviceType: <device_type> 
16

  isRdma: false 
17

  linkType: <link_type> 
18

  eSwitchMode: "switchdev" 
19

  excludeTopology: false 
20
Copy to Clipboard Toggle word wrap
1
사용자 정의 리소스 오브젝트의 이름입니다.
2
SR-IOV Network Operator가 설치된 네임스페이스입니다.
3
SR-IOV 네트워크 장치 플러그인의 리소스 이름입니다. 리소스 이름에 대한 SR-IOV 네트워크 노드 정책을 여러 개 생성할 수 있습니다.

이름을 지정할 때는 resourceName 에 허용되는 구문 표현식 ^[a-zA-Z0-9_]+$를 사용해야 합니다.

4
노드 선택기는 구성할 노드를 지정합니다. 선택한 노드의 SR-IOV 네트워크 장치만 구성됩니다. SR-IOV 컨테이너 네트워크 인터페이스(CNI) 플러그인과 장치 플러그인은 선택된 노드에만 배포됩니다.
중요

SR-IOV 네트워크 운영자는 노드 네트워크 구성 정책을 순서대로 노드에 적용합니다. SR-IOV 네트워크 운영자는 노드 네트워크 구성 정책을 적용하기 전에 노드의 머신 구성 풀(MCP)이 저하 또는 업데이트 와 같은 비정상 상태인지 확인합니다. 노드가 비정상적 MCP에 있는 경우 클러스터의 모든 대상 노드에 노드 네트워크 구성 정책을 적용하는 프로세스는 MCP가 정상 상태로 돌아올 때까지 일시 중지됩니다.

다른 MCP에 있는 노드를 포함하여 다른 노드에 대한 노드 네트워크 구성 정책 적용을 건강에 해로운 MCP에 있는 노드가 차단하는 것을 방지하려면 각 MCP에 대해 별도의 노드 네트워크 구성 정책을 만들어야 합니다.

5
선택 사항: 우선순위는 0에서 99 사이의 정수 값입니다. 작은 값은 우선순위가 높습니다. 예를 들어 우선순위 10은 우선순위 99보다 높습니다. 기본값은 99입니다.
6
선택 사항: 물리적 기능과 모든 가상 기능의 최대 전송 단위(MTU). 최대 MTU 값은 네트워크 인터페이스 컨트롤러(NIC) 모델마다 다를 수 있습니다.
중요

기본 네트워크 인터페이스에 가상 기능을 만들려면 MTU가 클러스터 MTU와 일치하는 값으로 설정되어 있는지 확인하세요.

포드에 기능이 할당된 동안 단일 가상 기능의 MTU를 수정하려면 SR-IOV 네트워크 노드 정책에서 MTU 값을 비워 둡니다. 그렇지 않으면 SR-IOV 네트워크 운영자는 가상 기능의 MTU를 SR-IOV 네트워크 노드 정책에 정의된 MTU 값으로 되돌리는데, 이로 인해 노드 비움이 발생할 수 있습니다.

7
선택 사항: pod에 /dev/vhost-net 장치를 마운트하려면 needVhostNettrue로 설정합니다. DPDK(Data Plane Development Kit)와 함께 마운트된 /dev/vhost-net 장치를 사용하여 트래픽을 커널 네트워크 스택으로 전달합니다.
8
SR-IOV 물리적 네트워크 장치에 생성할 VF(가상 기능) 수입니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는 127 보다 클 수 없습니다.
9
externallyManaged 필드는 SR-IOV 네트워크 운영자가 모든 가상 기능(VF)을 관리하는지, 아니면 일부 가상 기능(VF)만 관리하는지 여부를 나타냅니다. 값을 false 로 설정하면 SR-IOV 네트워크 운영자가 PF의 모든 VF를 관리하고 구성합니다.
참고

externallyManagedtrue 로 설정된 경우 SriovNetworkNodePolicy 리소스를 적용하기 전에 물리적 기능(PF)에 가상 기능(VF)을 수동으로 만들어야 합니다. VF가 미리 생성되지 않은 경우 SR-IOV 네트워크 운영자의 웹후크가 정책 요청을 차단합니다.

externallyManagedfalse 로 설정되면 SR-IOV 네트워크 운영자는 필요한 경우 재설정을 포함하여 VF를 자동으로 생성하고 관리합니다.

호스트 시스템에서 VF를 사용하려면 NMState를 통해 VF를 생성하고 externallyManaged를 true 로 설정해야 합니다. 이 모드에서는 SR-IOV 네트워크 운영자가 정책의 nicSelector 필드에 명시적으로 정의된 경우를 제외하고 PF 또는 수동으로 관리되는 VF를 수정하지 않습니다. 그러나 SR-IOV 네트워크 운영자는 Pod 보조 인터페이스로 사용되는 VF를 계속 관리합니다.

10
NIC 선택기는 이 리소스가 적용되는 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다.

rootDevices를 지정하면 vendor, deviceID 또는 pfNames의 값도 지정해야 합니다. pfNamesrootDevices를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오. netFilter의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다.

11
선택 사항: SR-IOV 네트워크 장치의 공급업체 16진수 공급업체 식별자입니다. 허용되는 값은 8086 (Intel)과 15b3 (Mellanox)뿐입니다.
12
선택 사항: SR-IOV 네트워크 장치의 16진수 장치 식별자입니다. 예를 들어 101b는 Mellanox ConnectX-6 장치의 장치 ID입니다.
13
선택 사항: 리소스가 적용되어야 하는 하나 이상의 물리적 기능(PF) 이름의 배열입니다.
14
선택 사항: 리소스가 적용되어야 하는 하나 이상의 PCI 버스 주소 배열입니다. 예를 들어 0000:02:00.1 .
15
선택 사항: 플랫폼별 네트워크 필터입니다. 지원되는 유일한 플랫폼은 Red Hat OpenStack Platform(RHOSP)입니다. 허용 가능한 값은 다음 형식을 사용합니다. openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/var/config/openstack/latest/network_data.json 메타데이터 파일의 값으로 바꿉니다. 이 필터는 VF가 특정 OpenStack 네트워크와 연관되어 있는지 확인합니다. 운영자는 이 필터를 사용하여 OpenStack 플랫폼에서 제공하는 메타데이터를 기반으로 VF를 적절한 네트워크에 매핑합니다.
16
선택 사항: 이 리소스에서 생성된 VF에 대해 구성할 드라이버입니다. 허용되는 값은 netdevicevfio-pci입니다. 기본값은 netdevice입니다.

베어 메탈 노드의 DPDK 모드에서 Mellanox NIC가 작동하려면 netdevice 드라이버 유형을 사용하고 isRdmatrue로 설정합니다.

17
선택 사항: 원격 직접 메모리 액세스(RDMA) 모드를 활성화할지 여부를 구성합니다. 기본값은 false입니다.

isRdma 매개변수가 true로 설정된 경우 RDMA 사용 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다.

isRdmatrue로 설정하고 추가로 needVhostNettrue로 설정하여 Fast Datapath DPDK 애플리케이션에서 사용할 Mellanox NIC를 구성합니다.

참고

Intel NIC의 경우 isRdma 매개변수를 true 로 설정할 수 없습니다.

18
선택사항: VF의 링크 유형입니다. 이더넷의 경우 기본값은 eth 입니다. InfiniBand의 경우 이 값을 'ib'로 변경합니다.

linkTypeib로 설정하면 isRdma가 SR-IOV Network Operator 웹 후크에 의해 자동으로 true로 설정됩니다. linkTypeib로 설정하면 deviceTypevfio-pci로 설정해서는 안 됩니다.

SriovNetworkNodePolicy에 대해 linkType을 eth 로 설정하지 마세요. 이렇게 하면 장치 플러그인에서 보고하는 사용 가능한 장치 수가 잘못될 수 있습니다.

19
선택 사항: 하드웨어 오프로드를 활성화하려면 eSwitchMode 필드를 "switchdev" 로 설정해야 합니다. 하드웨어 오프로드에 대한 자세한 내용은 "하드웨어 오프로드 구성"을 참조하세요.
20
선택 사항: SR-IOV 네트워크 리소스의 NUMA 노드를 토폴로지 관리자에게 알리는 것을 제외하려면 값을 true 로 설정합니다. 기본값은 false입니다.

2.1.1. SR-IOV 네트워크 노드 구성 예

다음 예제에서는 InfiniBand 장치의 구성을 설명합니다.

InfiniBand 장치의 구성 예

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name>
  namespace: openshift-sriov-network-operator
spec:
  resourceName: <sriov_resource_name>
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: <num>
  nicSelector:
    vendor: "<vendor_code>"
    deviceID: "<device_id>"
    rootDevices:
      - "<pci_bus_id>"
  linkType: <link_type>
  isRdma: true
# ...
Copy to Clipboard Toggle word wrap

다음 예제에서는 RHOSP 가상 머신의 SR-IOV 네트워크 장치에 대한 구성을 설명합니다.

가상 머신의 SR-IOV 장치 구성 예

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name>
  namespace: openshift-sriov-network-operator
spec:
  resourceName: <sriov_resource_name>
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 1 
1

  nicSelector:
    vendor: "<vendor_code>"
    deviceID: "<device_id>"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509" 
2

# ...
Copy to Clipboard Toggle word wrap

1
가상 머신의 노드 네트워크 정책을 구성할 때 numVfs 매개변수는 항상 1 로 설정됩니다.
2
가상 머신이 RHOSP에 배포되는 경우 netFilter 매개변수는 네트워크 ID를 참조해야 합니다. netFilter의 유효한 값은 SriovNetworkNodeState 오브젝트에서 사용할 수 있습니다.

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

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

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

중요

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

2.1.2.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
Copy to Clipboard Toggle word wrap

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

SR-IOV 네트워크 운영자는 Mellanox 장치의 펌웨어 구성을 건너뛸 수 있는 옵션을 지원합니다. 이 옵션을 사용하면 시스템에서 보안 부팅이 활성화된 경우 SR-IOV 네트워크 운영자를 사용하여 가상 기능을 만들 수 있습니다. 시스템을 보안 부팅으로 전환하기 전에 펌웨어에서 가상 기능의 수를 수동으로 구성하고 할당해야 합니다.

참고

펌웨어의 가상 기능 수는 정책에서 요청할 수 있는 가상 기능의 최대 수입니다.

프로세스

  1. sriov-config 데몬을 사용할 때 시스템에 보안 부팅이 없는 경우 다음 명령을 실행하여 가상 기능(VF)을 구성합니다.

    $ mstconfig -d -0001:b1:00.1 set SRIOV_EN=1 NUM_OF_VFS=16 
    1
     
    2
    Copy to Clipboard Toggle word wrap
    1
    SRIOV_EN 환경 변수는 Mellanox 카드에서 SR-IOV 네트워크 운영자 지원을 활성화합니다.
    2
    NUM_OF_VFS 환경 변수는 펌웨어에서 활성화할 가상 함수의 수를 지정합니다.
  2. Mellanox 플러그인을 비활성화하여 SR-IOV 네트워크 운영자를 구성합니다. 다음 SriovOperatorConfig 구성 예를 참조하세요.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      configDaemonNodeSelector: {}
      configurationMode: daemon
      disableDrain: false
      disablePlugins:
      - mellanox
      enableInjector: true
      enableOperatorWebhook: true
      logLevel: 2
    Copy to Clipboard Toggle word wrap
  3. 가상 기능과 구성 설정을 활성화하려면 시스템을 재부팅하세요.
  4. 다음 명령을 실행하여 시스템을 재부팅한 후 가상 기능(VF)을 확인하세요.

    $ oc -n openshift-sriov-network-operator get sriovnetworknodestate.sriovnetwork.openshift.io worker-0 -oyaml
    Copy to Clipboard Toggle word wrap

    출력 예

    - deviceID: 101d
        driver: mlx5_core
        eSwitchMode: legacy
        linkSpeed: -1 Mb/s
        linkType: ETH
        mac: 08:c0:eb:96:31:25
        mtu: 1500
        name: ens3f1np1
        pciAddress: 0000:b1:00.1 
    1
    
        totalvfs: 16
        vendor: 15b3
    Copy to Clipboard Toggle word wrap

    1
    totalvfs 값은 이 절차의 앞부분에서 mstconfig 명령에 사용된 숫자와 동일합니다.
  5. 장치 부팅 과정에서 승인되지 않은 운영 체제와 악성 소프트웨어가 로드되는 것을 방지하려면 보안 부팅을 활성화하세요.

    1. BIOS(기본 입출력 시스템)를 사용하여 보안 부팅을 활성화합니다.

      Secure Boot: Enabled
      Secure Boot Policy: Standard
      Secure Boot Mode: Mode Deployed
      Copy to Clipboard Toggle word wrap
    2. 시스템을 재부팅합니다.

2.1.4. 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"]
Copy to Clipboard Toggle word wrap
  • netpf0은 PF 인터페이스 이름입니다.
  • 2는 범위에 포함된 첫 번째 VF 인덱스(0 기반)입니다.
  • 7은 범위에 포함된 마지막 VF 인덱스(0 기반)입니다.

다음 요구 사항이 충족되면 다른 정책 CR을 사용하여 동일한 PF에서 VF를 선택할 수 있습니다.

  • 동일한 PF를 선택하는 정책의 경우 numVfs 값이 동일해야 합니다.
  • VF 색인은 0에서 <numVfs>-1까지의 범위 내에 있어야 합니다. 예를 들어, numVfs8로 설정된 정책이 있는 경우 <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-dpdkvfio 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
Copy to Clipboard Toggle word wrap

정책 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
Copy to Clipboard Toggle word wrap

인터페이스가 성공적으로 분할되었는지 확인

다음 명령을 실행하여 SR-IOV 장치의 가상 기능(VF)으로 인터페이스가 분할되었는지 확인합니다.

$ ip link show <interface> 
1
Copy to Clipboard Toggle word wrap
1
<인터페이스>를 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
Copy to Clipboard Toggle word wrap

다음 testpmd 포드는 대규모 페이지, 예약된 CPU 및 SR-IOV 포트를 사용하여 컨테이너를 생성하는 방법을 보여줍니다.

testpmd pod의 예

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/sriov1: 1
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/sriov1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile 
1

  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
Copy to Clipboard Toggle word wrap

1
이 예에서는 성능 프로필의 이름이 cnf-performance profile 이라고 가정합니다.

다음 testpmd 포드는 Red Hat OpenStack Platform(RHOSP)에서 Open vSwitch(OVS) 하드웨어 오프로드를 보여줍니다.

testpmd pod의 예

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    k8s.v1.cni.cncf.io/networks: hwoffload1
spec:
  runtimeClassName: performance-cnf-performanceprofile 
1

  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
    volumeMounts:
      - mountPath: /mnt/huge
        name: hugepage
        readOnly: False
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
Copy to Clipboard Toggle word wrap

1
성능 프로필 이름이 cnf-performance profile 이 아닌 경우 해당 문자열을 올바른 성능 프로필 이름으로 바꾸세요.

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

2.2. SR-IOV 네트워크 장치 구성

SR-IOV Network Operator는 SriovNetworkNodePolicy.sriovnetwork.openshift.io CustomResourceDefinition을 OpenShift Container Platform에 추가합니다. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 만들어 SR-IOV 네트워크 장치를 구성할 수 있습니다.

참고

SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 재부팅은 다음의 경우에만 발생합니다.

  • Mellanox NIC( mlx5 드라이버)를 사용하면 물리적 기능(PF)의 가상 기능(VF) 수가 늘어날 때마다 노드 재부팅이 발생합니다.
  • Intel NIC를 사용하는 경우 커널 매개변수에 intel_iommu=oniommu=pt가 포함되지 않은 경우에만 재부팅이 발생합니다.

구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • SR-IOV Network Operator가 설치되어 있습니다.
  • 비운 노드에서 제거된 워크로드를 처리하기 위해 클러스터에 사용 가능한 노드가 충분합니다.
  • SR-IOV 네트워크 장치 구성에 대한 컨트롤 플레인 노드를 선택하지 않았습니다.

절차

  1. SriovNetworkNodePolicy 오브젝트를 생성한 후 YAML을 <name>-sriov-node-network.yaml 파일에 저장합니다. <name>을 이 구성의 이름으로 바꿉니다.
  2. 선택 사항: SR-IOV 지원 클러스터 노드에 SriovNetworkNodePolicy.Spec.NodeSelector 를 사용하여 레이블을 지정합니다(아직 레이블이 지정되지 않은 경우). 노드에 레이블을 지정하는 방법에 대한 자세한 내용은 "노드의 레이블을 업데이트하는 방법 이해"를 참조하세요.
  3. SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f <name>-sriov-node-network.yaml
    Copy to Clipboard Toggle word wrap

    <name>은 이 구성의 이름을 지정합니다.

    구성 업데이트를 적용하면 sriov-network-operator 네임스페이스의 모든 Pod가 Running 상태로 전환됩니다.

  4. SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다. <node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다.

    $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
    Copy to Clipboard Toggle word wrap

2.3. NUMA(Non-Uniform Memory Access) 정렬 SR-IOV Pod 생성

제한된 또는 단일 NUMA 노드 토폴로지 관리자 정책을 사용하여 동일한 NUMA 노드에서 할당된 SR-IOV 및 CPU 리소스를 제한하여 NUMA 정렬 SR-IOV 포드를 생성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • CPU 관리자 정책을 static으로 구성했습니다. CPU 관리자에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오.
  • 토폴로지 관리자 정책을 single-numa-node로 구성했습니다.

    참고

    single-numa-node가 요청을 충족할 수 없는 경우 Topology Manager 정책을 restricted로 구성할 수 있습니다. 더욱 유연한 SR-IOV 네트워크 리소스 스케줄링을 위해 추가 리소스 섹션의 NUMA 인식 스케줄링 중 SR-IOV 네트워크 토폴로지 제외를 참조하세요.

절차

  1. 다음과 같은 SR-IOV Pod 사양을 생성한 다음 YAML을 <name>-sriov-pod.yaml 파일에 저장합니다. <name>을 이 Pod의 이름으로 바꿉니다.

    다음 예는 SR-IOV Pod 사양을 보여줍니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: sample-pod
      annotations:
        k8s.v1.cni.cncf.io/networks: <name> 
    1
    
    spec:
      containers:
      - name: sample-container
        image: <image> 
    2
    
        command: ["sleep", "infinity"]
        resources:
          limits:
            memory: "1Gi" 
    3
    
            cpu: "2" 
    4
    
          requests:
            memory: "1Gi"
            cpu: "2"
    Copy to Clipboard Toggle word wrap
    1
    <name>을 SR-IOV 네트워크 첨부 파일 정의 CR의 이름으로 바꿉니다.
    2
    <image>sample-pod 이미지의 이름으로 바꿉니다.
    3
    보장된 QoS로 SR-IOV Pod를 생성하려면 메모리 제한메모리 요청과 동일하게 설정합니다.
    4
    보장된 QoS로 SR-IOV Pod를 생성하려면 cpu 제한CPU 요청과 동일하게 설정합니다.
  2. 다음 명령을 실행하여 샘플 SR-IOV Pod를 만듭니다.

    $ oc create -f <filename> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <filename>을 이전 단계에서 생성한 파일 이름으로 바꿉니다.
  3. sample-pod가 보장된 QoS로 구성되어 있는지 확인하십시오.

    $ oc describe pod sample-pod
    Copy to Clipboard Toggle word wrap
  4. sample-pod에 전용 CPU가 할당되어 있는지 확인하십시오.

    $ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
    Copy to Clipboard Toggle word wrap
  5. sample-pod에 할당된 SR-IOV 장치 및 CPU가 동일한 NUMA 노드에 있는지 확인하십시오.

    $ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
    Copy to Clipboard Toggle word wrap

NUMA 인식 포드 스케줄링 중에 SR-IOV 네트워크 배포를 더욱 유연하게 하기 위해 SR-IOV 네트워크에 대한 NUMA(Non-Uniform Memory Access) 노드 광고를 토폴로지 관리자에게 제외할 수 있습니다.

어떤 시나리오에서는 단일 NUMA 노드의 포드에 대한 CPU 및 메모리 리소스를 극대화하는 것이 우선순위입니다. 토폴로지 관리자에게 포드의 SR-IOV 네트워크 리소스에 대한 NUMA 노드에 대한 힌트를 제공하지 않으면 토폴로지 관리자가 SR-IOV 네트워크 리소스와 포드 CPU 및 메모리 리소스를 다른 NUMA 노드에 배포할 수 있습니다. NUMA 노드 간 데이터 전송으로 인해 네트워크 지연이 발생할 수 있습니다. 하지만 워크로드에 최적의 CPU 및 메모리 성능이 필요한 시나리오에서는 허용 가능합니다.

예를 들어, 두 개의 NUMA 노드( numa0numa1) 가 있는 컴퓨팅 노드인 compute-1을 생각해 보겠습니다. SR-IOV 지원 NIC는 numa0 에 있습니다. Pod 스케줄링에 사용할 수 있는 CPU는 numa1 에만 있습니다. excludeTopology 사양을 true 로 설정하면 토폴로지 관리자는 포드의 CPU 및 메모리 리소스를 numa1 에 할당하고 동일한 포드의 SR-IOV 네트워크 리소스를 numa0 에 할당할 수 있습니다. 이는 excludeTopology 사양을 true 로 설정한 경우에만 가능합니다. 그렇지 않으면 토폴로지 관리자는 모든 리소스를 동일한 NUMA 노드에 배치하려고 시도합니다.

2.5. SR-IOV 구성 문제 해결

SR-IOV 네트워크 장치를 구성하는 절차를 수행한 후 다음 섹션에서는 일부 오류 조건을 다룹니다.

노드 상태를 표시하려면 다음 명령을 실행합니다.

$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>
Copy to Clipboard Toggle word wrap

여기서 <node_name>은 SR-IOV 네트워크 장치가 있는 노드의 이름을 지정합니다.

오류 출력 : 메모리를 할당할 수 없음

"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"
Copy to Clipboard Toggle word wrap

노드가 메모리를 할당할 수 없음을 나타내는 경우 다음 항목을 확인합니다.

  • 글로벌 SR-IOV 설정이 노드의 BIOS에서 활성화되어 있는지 확인합니다.
  • BIOS에서 노드에 대해 VT-d가 활성화되어 있는지 확인합니다.

2.6. 다음 단계

3장. SR-IOV 이더넷 네트워크 연결 구성

클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치에 대한 이더넷 네트워크 연결을 구성할 수 있습니다.

다음 문서의 작업을 수행하기 전에 SR-IOV 네트워크 운영자가 설치되어 있는지 확인하세요.

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
Copy to Clipboard Toggle word wrap
1
오브젝트의 이름입니다. SR-IOV Network Operator는 동일한 이름으로 NetworkAttachmentDefinition 오브젝트를 생성합니다.
2
SR-IOV Network Operator가 설치된 네임스페이스입니다.
3
이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는 SriovNetworkNodePolicy 오브젝트의 spec.resourceName 매개변수 값입니다.
4
SriovNetwork 오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 추가 네트워크에 연결할 수 있습니다.
5
선택사항: 추가 네트워크의 VLAN(Virtual LAN) ID입니다. 정수 값은 0에서 4095 사이여야 합니다. 기본값은 0입니다.
6
선택사항: VF의 스푸핑 검사 모드입니다. 허용되는 값은 문자열 "on""off"입니다.
중요

SR-IOV Network Operator가 지정한 값을 따옴표로 묶거나 오브젝트를 거부해야 합니다.

7
YAML 블록 스칼라로서 IPAM CNI 플러그인에 대한 구성 개체입니다. 이 플러그인은 첨부 파일 정의에 대한 IP 주소 할당을 관리합니다.
8
선택사항: VF(가상 기능)의 링크 상태입니다. 허용되는 값은 enable, disableauto입니다.
9
선택사항: VF의 경우 최대 전송 속도(Mbps)입니다.
10
선택사항: VF의 경우 최소 전송 속도(Mbps)입니다. 이 값은 최대 전송 속도보다 작거나 같아야 합니다.
참고

인텔 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 주소 지원을 활성화할 수 있습니다.

3.1.1. 듀얼 스택 IP 주소를 동적으로 할당하기 위한 구성 생성

듀얼 스택 IP 주소 할당은 다음의 경우 ipRanges 매개변수로 구성할 수 있습니다.

  • IPv4 주소
  • IPv6 주소
  • 다중 IP 주소 할당

프로세스

  1. 유형을 whereabouts 로 설정합니다.
  2. 다음 예와 같이 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"}
                  ]
           }
          }
    Copy to Clipboard Toggle word wrap
  3. 네트워크를 포드에 연결합니다. 자세한 내용은 "보조 네트워크에 포드 추가"를 참조하세요.
  4. 모든 IP 주소가 할당되었는지 확인하세요.
  5. 다음 명령을 실행하여 IP 주소가 메타데이터로 할당되었는지 확인하세요.

    $ oc exec -it mypod -- ip a
    Copy to Clipboard Toggle word wrap

3.1.2. 네트워크 연결을 위한 IP 주소 할당 구성

2차 네트워크의 경우 IP 주소는 IP 주소 관리(IPAM) CNI 플러그인을 사용하여 할당할 수 있습니다. 이 플러그인은 DHCP(동적 호스트 구성 프로토콜) 및 정적 할당을 포함한 다양한 할당 방법을 지원합니다.

IP 주소의 동적 할당을 담당하는 DHCP IPAM CNI 플러그인은 두 가지 고유한 구성 요소로 작동합니다.

  • CNI 플러그인 : IP 주소를 요청하고 해제하기 위해 Kubernetes 네트워킹 스택과 통합하는 역할을 담당합니다.
  • DHCP IPAM CNI 데몬 : 환경 내 기존 DHCP 서버와 협력하여 IP 주소 할당 요청을 처리하는 DHCP 이벤트 리스너입니다. 이 데몬 자체는 DHCP 서버가 아닙니다 .

IPAM 구성에서 dhcp 유형이 필요한 네트워크의 경우 다음을 확인하세요.

  • DHCP 서버가 사용 가능하고 환경에서 실행 중입니다. DHCP 서버는 클러스터 외부에 있으며 고객의 기존 네트워크 인프라의 일부가 될 것으로 예상됩니다.
  • DHCP 서버는 노드에 IP 주소를 제공하도록 적절하게 구성됩니다.

환경에서 DHCP 서버를 사용할 수 없는 경우 Whereabouts IPAM CNI 플러그인을 대신 사용하는 것이 좋습니다. Whereabouts CNI는 외부 DHCP 서버가 필요 없이 유사한 IP 주소 관리 기능을 제공합니다.

참고

외부 DHCP 서버가 없거나 정적 IP 주소 관리가 선호되는 경우 Whereabouts CNI 플러그인을 사용하세요. Whereabouts 플러그인에는 오래된 IP 주소 할당을 관리하는 조정자 데몬이 포함되어 있습니다.

DHCP 임대는 컨테이너의 수명 동안 주기적으로 갱신되어야 하므로 별도의 데몬인 DHCP IPAM CNI 데몬이 필요합니다. DHCP IPAM CNI 데몬을 배포하려면 클러스터 네트워크 운영자(CNO) 구성을 수정하여 이 데몬이 보조 네트워크 설정의 일부로 배포되도록 합니다.

3.1.2.1. 고정 IP 주소 할당 구성

다음 표에서는 정적 IP 주소 할당 구성을 설명합니다.

Expand
표 3.1. ipam 정적 구성 객체
필드유형설명

type

string

IPAM 주소 유형. static 값이 필요합니다.

addresses

array

가상 인터페이스에 할당할 IP 주소를 지정하는 객체의 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.

routes

array

포드 내부에서 구성할 경로를 지정하는 객체 배열입니다.

dns

array

선택 사항: DNS 구성을 지정하는 객체 배열입니다.

주소 배열에는 다음 필드가 있는 객체가 필요합니다.

Expand
표 3.2. ipam.addresses[] array
필드유형설명

address

string

지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어, 10.10.21.10/24를 지정하면 보조 네트워크에 IP 주소 10.10.21.10이 할당되고 넷마스크는 255.255.255.0이 됩니다.

gateway

string

송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.

Expand
표 3.3. ipam.routes[] 배열
필드유형설명

dst

string

기본 경로의 경우 CIDR 형식의 IP 주소 범위(예: 192.168.17.0/24 또는 0.0.0.0/0)입니다 .

gw

string

네트워크 트래픽이 라우팅되는 게이트웨이입니다.

Expand
표 3.4. ipam.dns 객체
필드유형설명

네임서버

array

DNS 쿼리를 보낼 하나 이상의 IP 주소 배열입니다.

domain

array

호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 example.com으로 설정되면 example-host에 대한 DNS 조회 쿼리가 example-host.example.com으로 다시 작성됩니다.

search

array

DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: example-host)에 추가할 도메인 이름 배열입니다.

고정 IP 주소 할당 구성 예

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}
Copy to Clipboard Toggle word wrap

3.1.2.2. 동적 IP 주소(DHCP) 할당 구성

pod는 생성될 때 원래 DHCP 리스를 얻습니다. 리스는 클러스터에서 실행되는 최소 DHCP 서버 배포를 통해 주기적으로 갱신되어야 합니다.

중요

이더넷 네트워크 연결의 경우, SR-IOV 네트워크 운영자는 DHCP 서버 배포를 생성하지 않습니다. 클러스터 네트워크 운영자가 최소한의 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"
        }
      }
  # ...
Copy to Clipboard Toggle word wrap

다음 표에서는 DHCP를 사용한 동적 IP 주소 할당에 대한 구성 매개변수를 설명합니다.

Expand
표 3.5. ipam DHCP 구성 객체
필드유형설명

type

string

IPAM 주소 유형. dhcp 값이 필요합니다.

다음 JSON 예제는 DHCP를 사용하여 동적 IP 주소를 할당하기 위한 구성 p를 설명합니다.

동적 IP 주소(DHCP) 할당 구성 예

{
  "ipam": {
    "type": "dhcp"
  }
}
Copy to Clipboard Toggle word wrap

3.1.2.3. Whereabouts를 사용한 동적 IP 주소 할당 구성

Whereabouts CNI 플러그인은 DHCP 서버를 사용하지 않고 보조 네트워크에 IP 주소를 동적으로 할당하는 데 도움이 됩니다.

Whereabouts CNI 플러그인은 또한 중복되는 IP 주소 범위와 별도의 NetworkAttachmentDefinition CRD 내에서 동일한 CIDR 범위를 여러 번 구성하는 것을 지원합니다. 이를 통해 다중 테넌트 환경에서 더 큰 유연성과 관리 기능이 제공됩니다.

3.1.2.3.1. 동적 IP 주소 구성 매개변수

다음 표에서는 Whereabouts를 사용한 동적 IP 주소 할당을 위한 구성 개체를 설명합니다.

Expand
표 3.6. ipam 위치 구성 매개변수
필드유형설명

type

string

IPAM 주소 유형. whereabouts 값이 필요합니다.

범위

string

CIDR 표기법으로 나타낸 IP 주소와 범위입니다. IP 주소는 이 주소 범위 내에서 할당됩니다.

exclude

array

선택 사항: CIDR 표기법으로 나타낸 0개 이상의 IP 주소 및 범위 목록입니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.

network_name

string

선택 사항: 동일한 IP 주소 범위를 공유하더라도 각 포드 그룹 또는 도메인이 고유한 IP 주소 세트를 갖도록 보장하는 데 도움이 됩니다. 이 필드를 설정하는 것은 네트워크를 분리하고 체계적으로 유지하는 데 중요하며, 특히 다중 테넌트 환경에서 중요합니다.

다음 예에서는 Whereabouts를 사용하는 NAD 파일의 동적 주소 할당 구성을 보여줍니다.

특정 IP 주소 범위를 제외하는 동적 IP 주소 할당 위치

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}
Copy to Clipboard Toggle word wrap

다음 예에서는 다중 테넌트 네트워크에 대해 중복되는 IP 주소 범위를 사용하는 동적 IP 주소 할당을 보여줍니다.

NetworkAttachmentDefinition 1

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/29",
    "network_name": "example_net_common", 
1

  }
}
Copy to Clipboard Toggle word wrap

1
선택 사항: 설정된 경우 NetworkAttachmentDefinition 2network_name 과 일치해야 합니다.

NetworkAttachmentDefinition 2

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/24",
    "network_name": "example_net_common", 
1

  }
}
Copy to Clipboard Toggle word wrap

1
선택 사항: 설정된 경우 NetworkAttachmentDefinition 1network_name 과 일치해야 합니다.

3.2. SR-IOV 추가 네트워크 구성

SriovNetwork 오브젝트를 생성하여 SR-IOV 하드웨어를 사용하는 추가 네트워크를 구성할 수 있습니다. SriovNetwork 객체를 생성하면 SR-IOV 네트워크 운영자가 자동으로 NetworkAttachmentDefinition 객체를 생성합니다.

참고

실행 중인 포드에 연결된 SriovNetwork 객체를 수정하거나 삭제하지 마세요.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 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"
        }
    Copy to Clipboard Toggle word wrap
  2. 오브젝트를 생성하려면 다음 명령을 입력합니다:

    $ oc create -f <name>.yaml
    Copy to Clipboard Toggle word wrap

    여기서 <name>은 추가 네트워크의 이름을 지정합니다.

  3. 선택사항: 이전 단계에서 생성한 SriovNetwork 오브젝트에 연결된 NetworkAttachmentDefinition 오브젝트가 존재하는지 확인하려면 다음 명령을 입력합니다. <namespace>SriovNetwork 오브젝트에 지정한 networkNamespace로 바꿉니다.

    $ oc get net-attach-def -n <namespace>
    Copy to Clipboard Toggle word wrap

3.3. SR-IOV 네트워크를 VRF에 할당

클러스터 관리자는 CNI VRF 플러그인을 사용하여 VRF 도메인에 SR-IOV 네트워크 인터페이스를 할당할 수 있습니다.

이렇게 하려면 SriovNetwork 리소스의 선택적 metaPlugins 매개변수에 VRF 구성을 추가합니다.

참고

VRF를 사용하는 애플리케이션은 특정 장치에 바인딩해야 합니다. 일반적인 사용은 소켓에 SO_BINDTODEVICE 옵션을 사용하는 것입니다. SO_BINDTODEVICE는 소켓을 전달된 인터페이스 이름(예: eth1)에 지정된 장치에 바인딩합니다. SO_BINDTODEVICE를 사용하려면 애플리케이션에 CAP_NET_RAW 기능이 있어야 합니다.

OpenShift Container Platform Pod에서는 ip vrf exec 명령을 통해 VRF를 사용할 수 없습니다. VRF를 사용하려면 애플리케이션을 VRF 인터페이스에 직접 바인딩합니다.

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 클러스터에 로그인합니다.

프로세스

  1. 추가 SR-IOV 네트워크 연결에 대한 SriovNetwork CR(사용자 정의 리소스)을 생성하고 다음 예제 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
    
        }
    Copy to Clipboard Toggle word wrap

    1
    typevrf로 설정해야 합니다.
    2
    vrfname은 인터페이스가 할당된 VRF의 이름입니다. 포드에 없는 경우 생성됩니다.
  2. SriovNetwork 리소스를 생성합니다.

    $ oc create -f sriov-network-attachment.yaml
    Copy to Clipboard Toggle word wrap

NetworkAttachmentDefinition CR이 성공적으로 생성되었는지 확인

  • SR-IOV Network Operator가 다음 명령을 실행하여 NetworkAttachmentDefinition CR을 생성했는지 확인합니다. 예상되는 출력에는 NAD CR의 이름과 생성 시간(분)이 표시됩니다.

    $ oc get network-attachment-definitions -n <namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <namespace>를 네트워크 연결을 구성할 때 지정한 네임스페이스(예: additional-sriov-network-1)로 바꿉니다.
    참고

    SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

추가 SR-IOV 네트워크 연결에 성공했는지 확인

VRF CNI가 올바르게 구성되었고 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행합니다.

  1. VRF CNI를 사용하는 SR-IOV 네트워크를 생성합니다.
  2. 포드에 네트워크를 할당합니다.
  3. 포드 네트워크 연결이 SR-IOV 추가 네트워크에 연결되어 있는지 확인합니다. 원격 셸을 포드에 넣고 다음 명령을 실행합니다. 예상되는 출력에는 VRF 인터페이스의 이름과 라우팅 테이블에서의 고유 ID가 표시됩니다.

    $ ip vrf show
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 VRF 인터페이스가 보조 인터페이스의 마스터 인지 확인하세요.

    $ ip link
    Copy to Clipboard Toggle word wrap

    출력 예

    ...
    5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
    ...
    Copy to Clipboard Toggle word wrap

3.4. 이더넷 기반 SR-IOV 연결을 위한 런타임 구성

추가 네트워크에 pod를 연결할 때 런타임 구성을 지정하여 pod에 대한 특정 사용자 정의를 수행할 수 있습니다. 예를 들어 특정 MAC 하드웨어 주소를 요청할 수 있습니다.

Pod 사양에서 주석을 설정하여 런타임 구성을 지정합니다. 주석 키는 k8s.v1.cni.cncf.io/networks이며 런타임 구성을 설명하는 JSON 오브젝트를 허용합니다.

다음 JSON은 이더넷 기반 SR-IOV 네트워크 연결에 대한 런타임 구성 옵션을 설명합니다.

[
  {
    "name": "<name>", 
1

    "mac": "<mac_address>", 
2

    "ips": ["<cidr_range>"] 
3

  }
]
Copy to Clipboard Toggle word wrap
1
SR-IOV 네트워크 연결 정의 CR의 이름입니다.
2
선택사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 MAC 주소입니다. 이 기능을 사용하려면 SriovNetwork 오브젝트에 { "mac": true }도 지정해야 합니다.
3
선택사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 IP 주소입니다. IPv4 및 IPv6 주소가 모두 지원됩니다. 이 기능을 사용하려면 SriovNetwork 오브젝트에 { "ips": true }도 지정해야 합니다.

런타임 구성 예

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"]
Copy to Clipboard Toggle word wrap

3.5. 보조 네트워크에 포드 추가

보조 네트워크에 포드를 추가할 수 있습니다. Pod는 기본 네트워크를 통해 정상적인 클러스터 관련 네트워크 트래픽을 계속 전송합니다.

포드가 생성되면 보조 네트워크가 포드에 연결됩니다. 하지만 포드가 이미 존재하는 경우 보조 네트워크를 연결할 수 없습니다.

포드는 보조 네트워크와 동일한 네임스페이스에 있어야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터에 로그인합니다.

프로세스

  1. Pod 오브젝트에 주석을 추가합니다. 다음 주석 형식 중 하나만 사용할 수 있습니다.

    1. 사용자 정의 없이 보조 네트워크를 연결하려면 다음 형식으로 주석을 추가하세요. <네트워크>를 포드와 연결할 보조 네트워크의 이름으로 바꾸세요.

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 
      1
      Copy to Clipboard Toggle word wrap
      1
      두 개 이상의 보조 네트워크를 지정하려면 각 네트워크를 쉼표로 구분하세요. 쉼표 사이에 공백을 포함하지 마십시오. 동일한 보조 네트워크를 여러 번 지정하면 해당 Pod에 여러 개의 네트워크 인터페이스가 해당 네트워크에 연결됩니다.
    2. 사용자 정의를 사용하여 보조 네트워크를 연결하려면 다음 형식으로 주석을 추가하세요.

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "<network>", 
      1
      
                "namespace": "<namespace>", 
      2
      
                "default-route": ["<default-route>"] 
      3
      
              }
            ]
      Copy to Clipboard Toggle word wrap
      1
      NetworkAttachmentDefinition 개체에 의해 정의된 보조 네트워크의 이름을 지정합니다.
      2
      NetworkAttachmentDefinition 오브젝트가 정의된 네임스페이스를 지정합니다.
      3
      선택 사항: 기본 경로에 대한 재정의를 지정합니다(예: 192.168.17.1).
  2. Pod를 생성하려면 다음 명령을 입력합니다. <name>을 Pod 이름으로 교체합니다.

    $ oc create -f <name>.yaml
    Copy to Clipboard Toggle word wrap
  3. 선택사항: Pod CR에 주석이 있는지 확인하려면 다음 명령을 입력하고 <name>을 Pod 이름으로 교체합니다.

    $ oc get pod <name> -o yaml
    Copy to Clipboard Toggle word wrap

    다음 예에서 example-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:
      ...
    Copy to Clipboard Toggle word wrap
    1
    k8s.v1.cni.cncf.io/network-status 매개변수는 객체의 JSON 배열입니다. 각 객체는 포드에 연결된 보조 네트워크의 상태를 설명합니다. 주석 값은 일반 텍스트 값으로 저장됩니다.

3.5.1. Pod에 vfio-pci SR-IOV 장치의 MTU 노출

추가 네트워크에 포드를 추가한 후 SR-IOV 네트워크에서 MTU를 사용할 수 있는지 확인할 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 Pod 주석에 MTU가 포함되어 있는지 확인하세요.

    $ oc describe pod example-pod
    Copy to Clipboard Toggle word wrap

    다음 예에서는 샘플 출력을 보여줍니다.

    "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"
        }
      }
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 포드 내부의 /etc/podnetinfo/ 에서 MTU를 사용할 수 있는지 확인하세요.

    $ oc exec example-pod -n sriov-tests -- cat /etc/podnetinfo/annotations | grep mtu
    Copy to Clipboard Toggle word wrap

    다음 예에서는 샘플 출력을 보여줍니다.

    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\"
            }
        }
        }]"
    Copy to Clipboard Toggle word wrap

3.6. SR-IOV 네트워크 정책 업데이트 중 병렬 노드 드레이닝 구성

기본적으로 SR-IOV 네트워크 운영자는 정책이 변경되기 전에 노드에서 작업 부하를 제거합니다. 운영자는 재구성으로 인해 작업 부하가 영향을 받지 않도록 한 번에 한 노드씩 이 작업을 수행합니다.

대규모 클러스터에서 노드를 순차적으로 비우는 작업은 시간이 많이 걸릴 수 있으며, 몇 시간 또는 며칠이 걸릴 수도 있습니다. 시간에 민감한 환경에서는 SriovNetworkPoolConfig 사용자 정의 리소스(CR)에서 병렬 노드 드레이닝을 활성화하여 SR-IOV 네트워크 구성을 더 빠르게 롤아웃할 수 있습니다.

병렬 드레이닝을 구성하려면 SriovNetworkPoolConfig CR을 사용하여 노드 풀을 만듭니다. 그런 다음 풀에 노드를 추가하고 운영자가 병렬로 비울 수 있는 풀의 최대 노드 수를 정의할 수 있습니다. 이 접근 방식을 사용하면 풀에 실행 중인 작업 부하를 처리할 수 있는 충분한 노드가 남아 있는지 확인하는 동시에 더 빠른 재구성을 위해 병렬 드레이닝을 활성화할 수 있습니다.

참고

노드는 하나의 SR-IOV 네트워크 풀 구성에만 속할 수 있습니다. 노드가 풀에 속하지 않으면 한 번에 하나의 노드만 비우도록 구성된 가상 기본 풀에 추가됩니다.

노드는 배수 과정 중에 다시 시작될 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • SR-IOV Network Operator 설치.
  • 노드에는 SR-IOV를 지원하는 하드웨어가 있습니다.

프로세스

  1. SriovNetworkPoolConfig 리소스를 만듭니다.

    1. 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: ""
      Copy to Clipboard Toggle word wrap

      1
      SriovNetworkPoolConfig 개체의 이름을 지정합니다.
      2
      SR-IOV 네트워크 운영자가 설치된 네임스페이스를 지정합니다.
      3
      업데이트 중에 풀에서 사용할 수 없는 노드에 대한 정수 또는 백분율 값을 지정합니다. 예를 들어, 노드가 10개이고 사용할 수 없는 최대 노드 수를 2로 설정하면 언제든지 병렬로 비울 수 있는 노드는 2개뿐이고, 작업 부하를 처리할 수 있는 노드는 8개 남습니다.
      4
      노드 선택기를 사용하여 풀을 추가할 노드를 지정합니다. 이 예제에서는 작업자 역할이 있는 모든 노드를 풀에 추가합니다.
    2. 다음 명령을 실행하여 SriovNetworkPoolConfig 리소스를 만듭니다.

      $ oc create -f sriov-nw-pool.yaml
      Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 sriov-test 네임스페이스를 만듭니다.

    $ oc create namespace sriov-test
    Copy to Clipboard Toggle word wrap
  3. SriovNetworkNodePolicy 리소스를 만듭니다.

    1. 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
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 SriovNetworkNodePolicy 리소스를 만듭니다.

      $ oc create -f sriov-node-policy.yaml
      Copy to Clipboard Toggle word wrap
  4. SriovNetwork 리소스를 만듭니다.

    1. 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" }'
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 SriovNetwork 리소스를 만듭니다.

      $ oc create -f sriov-network.yaml
      Copy to Clipboard Toggle word wrap

검증

  • 다음 명령을 실행하여 생성한 노드 풀을 확인하세요.

    $ oc get sriovNetworkpoolConfig -n openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME     AGE
    pool-1   67s 
    1
    Copy to Clipboard Toggle word wrap

    1
    이 예에서 pool-1 에는 작업자 역할이 있는 모든 노드가 포함되어 있습니다.

위 절차의 예제 시나리오를 사용하여 노드 드레이닝 프로세스를 시연하려면 다음 단계를 완료하세요.

  1. 클러스터에서 작업 부하 감소를 트리거하기 위해 SriovNetworkNodePolicy 리소스의 가상 함수 수를 업데이트합니다.

    $ oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 대상 클러스터의 드레이닝 상태를 모니터링합니다.

    $ oc get sriovNetworkNodeState -n openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

    배수 프로세스가 완료되면 SYNC STATUS가 Succeeded 로 변경되고 DESIRED SYNC STATECURRENT SYNC STATE 값은 IDLE 로 돌아갑니다.

3.7. 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가 설치되어 있습니다.

프로세스

  1. SriovNetworkNodePolicy CR을 만듭니다.

    1. 다음 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
      Copy to Clipboard Toggle word wrap
      1
      SR-IOV 네트워크 장치 플러그인의 리소스 이름입니다. 이 YAML은 샘플 resourceName 값을 사용합니다.
      2
      NIC 선택기를 사용하여 운영자가 구성할 장치를 식별합니다.
      3
      SR-IOV 네트워크 리소스에 대한 NUMA 노드 광고를 토폴로지 관리자에게 제외하려면 값을 true 로 설정합니다. 기본값은 false입니다.
      참고

      여러 SriovNetworkNodePolicy 리소스가 동일한 SR-IOV 네트워크 리소스를 대상으로 하는 경우 SriovNetworkNodePolicy 리소스는 excludeTopology 사양과 동일한 값을 가져야 합니다. 그렇지 않으면 상충되는 정책은 거부됩니다.

    2. 다음 명령을 실행하여 SriovNetworkNodePolicy 리소스를 만듭니다. 성공적인 출력에는 SriovNetworkNodePolicy 리소스의 이름과 생성 상태가 나열됩니다.

      $ oc create -f sriov-network-node-policy.yaml
      Copy to Clipboard Toggle word wrap
  2. SriovNetwork CR을 만듭니다.

    1. 다음 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>",
          }
      Copy to Clipboard Toggle word wrap
      1
      sriov-numa-0-network를 SR-IOV 네트워크 리소스의 이름으로 바꿉니다.
      2
      이전 단계의 SriovNetworkNodePolicy CR에 대한 리소스 이름을 지정합니다. 이 YAML은 샘플 resourceName 값을 사용합니다.
      3
      SR-IOV 네트워크 리소스에 대한 네임스페이스를 입력하세요.
      4
      SR-IOV 네트워크에 대한 IP 주소 관리 구성을 입력합니다.
    2. 다음 명령을 실행하여 SriovNetwork 리소스를 만듭니다. 성공적인 출력에는 SriovNetwork 리소스의 이름과 생성 상태가 나열됩니다.

      $ oc create -f sriov-network.yaml
      Copy to Clipboard Toggle word wrap
  3. 포드를 생성하고 이전 단계의 SR-IOV 네트워크 리소스를 할당합니다.

    1. 다음 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"]
      Copy to Clipboard Toggle word wrap
      1
      이는 SriovNetworkNodePolicy 리소스를 사용하는 SriovNetwork 리소스의 이름입니다.
    2. 다음 명령을 실행하여 Pod 리소스를 만듭니다. 예상되는 출력에는 Pod 리소스의 이름과 생성 상태가 표시됩니다.

      $ oc create -f sriov-network-pod.yaml
      Copy to Clipboard Toggle word wrap

검증

  1. 다음 명령을 실행하여 포드 상태를 확인합니다. 여기서 <pod_name>을 포드 이름으로 바꿉니다.

    $ oc get pod <pod_name>
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                     READY   STATUS    RESTARTS   AGE
    test-deployment-sriov-76cbbf4756-k9v72   1/1     Running   0          45h
    Copy to Clipboard Toggle word wrap

  2. 대상 포드에서 디버그 세션을 열어 SR-IOV 네트워크 리소스가 메모리 및 CPU 리소스와 다른 노드에 배포되었는지 확인합니다.

    1. 다음 명령을 실행하여 포드로 디버그 세션을 엽니다. 여기서 <pod_name>을 대상 포드 이름으로 바꿉니다.

      $ oc debug pod/<pod_name>
      Copy to Clipboard Toggle word wrap
    2. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의 /host에 호스트의 root 파일 시스템을 마운트합니다. root 디렉토리를 /host로 변경하면 호스트 파일 시스템에서 바이너리를 실행할 수 있습니다.

      $ chroot /host
      Copy to Clipboard Toggle word wrap
    3. 다음 명령을 실행하여 CPU 할당에 대한 정보를 확인하세요.

      $ lscpu | grep NUMA
      Copy to Clipboard Toggle word wrap

      출력 예

      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,...
      Copy to Clipboard Toggle word wrap

      $ cat /proc/self/status | grep Cpus
      Copy to Clipboard Toggle word wrap

      출력 예

      Cpus_allowed:	aa
      Cpus_allowed_list:	1,3,5,7
      Copy to Clipboard Toggle word wrap

      $ cat  /sys/class/net/net1/device/numa_node
      Copy to Clipboard Toggle word wrap

      출력 예

      0
      Copy to Clipboard Toggle word wrap

      이 예에서 CPU 1, 3, 5, 7은 NUMA 노드 1 에 할당되지만 SR-IOV 네트워크 리소스는 NUMA 노드 0 의 NIC를 사용할 수 있습니다.

참고

excludeTopology 사양이 True 로 설정된 경우 필요한 리소스가 동일한 NUMA 노드에 존재할 수 있습니다.

4장. SR-IOV InfiniBand 네트워크 연결 구성

클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치에 대한 IB(InfiniBand) 네트워크 연결을 구성할 수 있습니다.

다음 문서의 작업을 수행하기 전에 SR-IOV 네트워크 운영자가 설치되어 있는지 확인하세요.

4.1. InfiniBand 장치 구성 오브젝트

SriovIBNetwork 오브젝트를 정의하여 IB(InfiniBand) 네트워크 장치를 구성할 수 있습니다.

다음 YAML은 SriovIBNetwork 오브젝트를 설명합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork
metadata:
  name: <name> 
1

  namespace: openshift-sriov-network-operator 
2

spec:
  resourceName: <sriov_resource_name> 
3

  networkNamespace: <target_namespace> 
4

  ipam: |- 
5

    {}
  linkState: <link_state> 
6

  capabilities: <capabilities> 
7
Copy to Clipboard Toggle word wrap
1
오브젝트의 이름입니다. SR-IOV Network Operator는 동일한 이름으로 NetworkAttachmentDefinition 오브젝트를 생성합니다.
2
SR-IOV Operator가 설치된 네임스페이스입니다.
3
이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는 SriovNetworkNodePolicy 오브젝트의 spec.resourceName 매개변수 값입니다.
4
SriovIBNetwork 오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 네트워크 장치에 연결할 수 있습니다.
5
선택 사항: YAML 블록 스칼라 형태의 IPAM CNI 플러그인에 대한 구성 개체입니다. 이 플러그인은 첨부 파일 정의에 대한 IP 주소 할당을 관리합니다.
6
선택사항: VF(가상 기능)의 링크 상태입니다. 허용되는 값은 enable, disable, auto입니다.
7
선택사항: 이 네트워크에 구성할 수 있는 기능입니다. '{ "ips": true }'를 지정하여 IP 주소 지원을 활성화하거나 '{ "infinibandGUID": true }'를 지정 하여 IB 전역 고유 식별자(GUID) 지원을 활성화할 수 있습니다.

4.1.1. 듀얼 스택 IP 주소를 동적으로 할당하기 위한 구성 생성

듀얼 스택 IP 주소 할당은 다음의 경우 ipRanges 매개변수로 구성할 수 있습니다.

  • IPv4 주소
  • IPv6 주소
  • 다중 IP 주소 할당

프로세스

  1. 유형을 whereabouts 로 설정합니다.
  2. 다음 예와 같이 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"}
                  ]
           }
          }
    Copy to Clipboard Toggle word wrap
  3. 네트워크를 포드에 연결합니다. 자세한 내용은 "보조 네트워크에 포드 추가"를 참조하세요.
  4. 모든 IP 주소가 할당되었는지 확인하세요.
  5. 다음 명령을 실행하여 IP 주소가 메타데이터로 할당되었는지 확인하세요.

    $ oc exec -it mypod -- ip a
    Copy to Clipboard Toggle word wrap

4.1.2. 네트워크 연결을 위한 IP 주소 할당 구성

2차 네트워크의 경우 IP 주소는 IP 주소 관리(IPAM) CNI 플러그인을 사용하여 할당할 수 있습니다. 이 플러그인은 DHCP(동적 호스트 구성 프로토콜) 및 정적 할당을 포함한 다양한 할당 방법을 지원합니다.

IP 주소의 동적 할당을 담당하는 DHCP IPAM CNI 플러그인은 두 가지 고유한 구성 요소로 작동합니다.

  • CNI 플러그인 : IP 주소를 요청하고 해제하기 위해 Kubernetes 네트워킹 스택과 통합하는 역할을 담당합니다.
  • DHCP IPAM CNI 데몬 : 환경 내 기존 DHCP 서버와 협력하여 IP 주소 할당 요청을 처리하는 DHCP 이벤트 리스너입니다. 이 데몬 자체는 DHCP 서버가 아닙니다 .

IPAM 구성에서 dhcp 유형이 필요한 네트워크의 경우 다음을 확인하세요.

  • DHCP 서버가 사용 가능하고 환경에서 실행 중입니다. DHCP 서버는 클러스터 외부에 있으며 고객의 기존 네트워크 인프라의 일부가 될 것으로 예상됩니다.
  • DHCP 서버는 노드에 IP 주소를 제공하도록 적절하게 구성됩니다.

환경에서 DHCP 서버를 사용할 수 없는 경우 Whereabouts IPAM CNI 플러그인을 대신 사용하는 것이 좋습니다. Whereabouts CNI는 외부 DHCP 서버가 필요 없이 유사한 IP 주소 관리 기능을 제공합니다.

참고

외부 DHCP 서버가 없거나 정적 IP 주소 관리가 선호되는 경우 Whereabouts CNI 플러그인을 사용하세요. Whereabouts 플러그인에는 오래된 IP 주소 할당을 관리하는 조정자 데몬이 포함되어 있습니다.

DHCP 임대는 컨테이너의 수명 동안 주기적으로 갱신되어야 하므로 별도의 데몬인 DHCP IPAM CNI 데몬이 필요합니다. DHCP IPAM CNI 데몬을 배포하려면 클러스터 네트워크 운영자(CNO) 구성을 수정하여 이 데몬이 보조 네트워크 설정의 일부로 배포되도록 합니다.

4.1.2.1. 고정 IP 주소 할당 구성

다음 표에서는 정적 IP 주소 할당 구성을 설명합니다.

Expand
표 4.1. ipam 정적 구성 객체
필드유형설명

type

string

IPAM 주소 유형. static 값이 필요합니다.

addresses

array

가상 인터페이스에 할당할 IP 주소를 지정하는 객체의 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.

routes

array

포드 내부에서 구성할 경로를 지정하는 객체 배열입니다.

dns

array

선택 사항: DNS 구성을 지정하는 객체 배열입니다.

주소 배열에는 다음 필드가 있는 객체가 필요합니다.

Expand
표 4.2. ipam.addresses[] array
필드유형설명

address

string

지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어, 10.10.21.10/24를 지정하면 보조 네트워크에 IP 주소 10.10.21.10이 할당되고 넷마스크는 255.255.255.0이 됩니다.

gateway

string

송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.

Expand
표 4.3. ipam.routes[] 배열
필드유형설명

dst

string

기본 경로의 경우 CIDR 형식의 IP 주소 범위(예: 192.168.17.0/24 또는 0.0.0.0/0)입니다 .

gw

string

네트워크 트래픽이 라우팅되는 게이트웨이입니다.

Expand
표 4.4. ipam.dns 객체
필드유형설명

네임서버

array

DNS 쿼리를 보낼 하나 이상의 IP 주소 배열입니다.

domain

array

호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 example.com으로 설정되면 example-host에 대한 DNS 조회 쿼리가 example-host.example.com으로 다시 작성됩니다.

search

array

DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: example-host)에 추가할 도메인 이름 배열입니다.

고정 IP 주소 할당 구성 예

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}
Copy to Clipboard Toggle word wrap

4.1.2.2. 동적 IP 주소(DHCP) 할당 구성

pod는 생성될 때 원래 DHCP 리스를 얻습니다. 리스는 클러스터에서 실행되는 최소 DHCP 서버 배포를 통해 주기적으로 갱신되어야 합니다.

중요

이더넷 네트워크 연결의 경우, SR-IOV 네트워크 운영자는 DHCP 서버 배포를 생성하지 않습니다. 클러스터 네트워크 운영자가 최소한의 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"
        }
      }
  # ...
Copy to Clipboard Toggle word wrap

다음 표에서는 DHCP를 사용한 동적 IP 주소 할당에 대한 구성 매개변수를 설명합니다.

Expand
표 4.5. ipam DHCP 구성 객체
필드유형설명

type

string

IPAM 주소 유형. dhcp 값이 필요합니다.

다음 JSON 예제는 DHCP를 사용하여 동적 IP 주소를 할당하기 위한 구성 p를 설명합니다.

동적 IP 주소(DHCP) 할당 구성 예

{
  "ipam": {
    "type": "dhcp"
  }
}
Copy to Clipboard Toggle word wrap

4.1.3. Whereabouts를 사용한 동적 IP 주소 할당 구성

Whereabouts CNI 플러그인은 DHCP 서버를 사용하지 않고 보조 네트워크에 IP 주소를 동적으로 할당하는 데 도움이 됩니다.

Whereabouts CNI 플러그인은 또한 중복되는 IP 주소 범위와 별도의 NetworkAttachmentDefinition CRD 내에서 동일한 CIDR 범위를 여러 번 구성하는 것을 지원합니다. 이를 통해 다중 테넌트 환경에서 더 큰 유연성과 관리 기능이 제공됩니다.

4.1.3.1. 동적 IP 주소 구성 매개변수

다음 표에서는 Whereabouts를 사용한 동적 IP 주소 할당을 위한 구성 개체를 설명합니다.

Expand
표 4.6. ipam 위치 구성 매개변수
필드유형설명

type

string

IPAM 주소 유형. whereabouts 값이 필요합니다.

범위

string

CIDR 표기법으로 나타낸 IP 주소와 범위입니다. IP 주소는 이 주소 범위 내에서 할당됩니다.

exclude

array

선택 사항: CIDR 표기법으로 나타낸 0개 이상의 IP 주소 및 범위 목록입니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.

network_name

string

선택 사항: 동일한 IP 주소 범위를 공유하더라도 각 포드 그룹 또는 도메인이 고유한 IP 주소 세트를 갖도록 보장하는 데 도움이 됩니다. 이 필드를 설정하는 것은 네트워크를 분리하고 체계적으로 유지하는 데 중요하며, 특히 다중 테넌트 환경에서 중요합니다.

다음 예에서는 Whereabouts를 사용하는 NAD 파일의 동적 주소 할당 구성을 보여줍니다.

특정 IP 주소 범위를 제외하는 동적 IP 주소 할당 위치

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}
Copy to Clipboard Toggle word wrap

4.1.3.3. IP 주소 범위가 겹치는 Whereabouts를 사용하는 동적 IP 주소 할당

다음 예에서는 다중 테넌트 네트워크에 대해 중복되는 IP 주소 범위를 사용하는 동적 IP 주소 할당을 보여줍니다.

NetworkAttachmentDefinition 1

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/29",
    "network_name": "example_net_common", 
1

  }
}
Copy to Clipboard Toggle word wrap

1
선택 사항: 설정된 경우 NetworkAttachmentDefinition 2network_name 과 일치해야 합니다.

NetworkAttachmentDefinition 2

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/24",
    "network_name": "example_net_common", 
1

  }
}
Copy to Clipboard Toggle word wrap

1
선택 사항: 설정된 경우 NetworkAttachmentDefinition 1network_name 과 일치해야 합니다.

4.2. SR-IOV 추가 네트워크 구성

SriovIBNetwork 객체를 생성하여 SR-IOV 하드웨어를 사용하는 추가 네트워크를 구성할 수 있습니다. SriovIBNetwork 객체를 생성하면 SR-IOV 네트워크 운영자가 자동으로 NetworkAttachmentDefinition 객체를 생성합니다.

참고

실행 중인 포드에 연결된 SriovIBNetwork 객체를 수정하거나 삭제하지 마세요.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. SriovIBNetwork 오브젝트를 생성한 다음 <name>.yaml 파일에 YAML을 저장합니다. 여기서 <name>은 이 추가 네트워크의 이름입니다. 오브젝트 사양은 다음 예와 유사할 수 있습니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovIBNetwork
    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"
        }
    Copy to Clipboard Toggle word wrap
  2. 오브젝트를 생성하려면 다음 명령을 입력합니다:

    $ oc create -f <name>.yaml
    Copy to Clipboard Toggle word wrap

    여기서 <name>은 추가 네트워크의 이름을 지정합니다.

  3. 선택 사항: 이전 단계에서 생성한 SriovIBNetwork 오브젝트에 연결된 NetworkAttachmentDefinition 오브젝트가 존재하는지 확인하려면 다음 명령을 입력합니다. <namespace>SriovIBNetwork 오브젝트에 지정한 networkNamespace로 바꿉니다.

    $ oc get net-attach-def -n <namespace>
    Copy to Clipboard Toggle word wrap

4.3. InfiniBand 기반 SR-IOV 연결을 위한 런타임 구성

추가 네트워크에 pod를 연결할 때 런타임 구성을 지정하여 pod에 대한 특정 사용자 정의를 수행할 수 있습니다. 예를 들어 특정 MAC 하드웨어 주소를 요청할 수 있습니다.

Pod 사양에서 주석을 설정하여 런타임 구성을 지정합니다. 주석 키는 k8s.v1.cni.cncf.io/networks이며 런타임 구성을 설명하는 JSON 오브젝트를 허용합니다.

다음 JSON은 InfiniBand 기반 SR-IOV 네트워크 연결에 대한 런타임 구성 옵션을 설명합니다.

[
  {
    "name": "<network_attachment>", 
1

    "infiniband-guid": "<guid>", 
2

    "ips": ["<cidr_range>"] 
3

  }
]
Copy to Clipboard Toggle word wrap
1
SR-IOV 네트워크 연결 정의 CR의 이름입니다.
2
SR-IOV 장치의 InfiniBand GUID입니다. 이 기능을 사용하려면 SriovIBNetwork 오브젝트에 { "infinibandGUID": true }도 지정해야 합니다.
3
SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 IP 주소입니다. IPv4 및 IPv6 주소가 모두 지원됩니다. 이 기능을 사용하려면 SriovIBNetwork 오브젝트에 { "ips": true }도 지정해야 합니다.

런타임 구성 예

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "ib1",
          "infiniband-guid": "c2:11:22:33:44:55:66:77",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]
Copy to Clipboard Toggle word wrap

4.4. 보조 네트워크에 포드 추가

보조 네트워크에 포드를 추가할 수 있습니다. Pod는 기본 네트워크를 통해 정상적인 클러스터 관련 네트워크 트래픽을 계속 전송합니다.

포드가 생성되면 보조 네트워크가 포드에 연결됩니다. 하지만 포드가 이미 존재하는 경우 보조 네트워크를 연결할 수 없습니다.

포드는 보조 네트워크와 동일한 네임스페이스에 있어야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터에 로그인합니다.

프로세스

  1. Pod 오브젝트에 주석을 추가합니다. 다음 주석 형식 중 하나만 사용할 수 있습니다.

    1. 사용자 정의 없이 보조 네트워크를 연결하려면 다음 형식으로 주석을 추가하세요. <네트워크>를 포드와 연결할 보조 네트워크의 이름으로 바꾸세요.

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 
      1
      Copy to Clipboard Toggle word wrap
      1
      두 개 이상의 보조 네트워크를 지정하려면 각 네트워크를 쉼표로 구분하세요. 쉼표 사이에 공백을 포함하지 마십시오. 동일한 추가 네트워크를 여러 번 지정하면 Pod에 해당 네트워크에 대한 인터페이스가 여러 개 연결됩니다.
    2. 사용자 정의를 사용하여 보조 네트워크를 연결하려면 다음 형식으로 주석을 추가하세요.

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "<network>", 
      1
      
                "namespace": "<namespace>", 
      2
      
                "default-route": ["<default-route>"] 
      3
      
              }
            ]
      Copy to Clipboard Toggle word wrap
      1
      NetworkAttachmentDefinition 개체에 의해 정의된 보조 네트워크의 이름을 지정합니다.
      2
      NetworkAttachmentDefinition 오브젝트가 정의된 네임스페이스를 지정합니다.
      3
      선택 사항: 기본 경로에 대한 재정의를 지정합니다(예: 192.168.17.1).
  2. Pod를 생성하려면 다음 명령을 입력합니다. <name>을 Pod 이름으로 교체합니다.

    $ oc create -f <name>.yaml
    Copy to Clipboard Toggle word wrap
  3. 선택사항: Pod CR에 주석이 있는지 확인하려면 다음 명령을 입력하고 <name>을 Pod 이름으로 교체합니다.

    $ oc get pod <name> -o yaml
    Copy to Clipboard Toggle word wrap

    다음 예에서 example-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:
      ...
    Copy to Clipboard Toggle word wrap
    1
    k8s.v1.cni.cncf.io/networks-status 매개변수는 JSON 오브젝트 배열입니다. 각 객체는 포드에 연결된 보조 네트워크의 상태를 설명합니다. 주석 값은 일반 텍스트 값으로 저장됩니다.

4.4.1. Pod에 vfio-pci SR-IOV 장치의 MTU 노출

추가 네트워크에 포드를 추가한 후 SR-IOV 네트워크에서 MTU를 사용할 수 있는지 확인할 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 Pod 주석에 MTU가 포함되어 있는지 확인하세요.

    $ oc describe pod example-pod
    Copy to Clipboard Toggle word wrap

    다음 예에서는 샘플 출력을 보여줍니다.

    "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"
        }
      }
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 포드 내부의 /etc/podnetinfo/ 에서 MTU를 사용할 수 있는지 확인하세요.

    $ oc exec example-pod -n sriov-tests -- cat /etc/podnetinfo/annotations | grep mtu
    Copy to Clipboard Toggle word wrap

    다음 예에서는 샘플 출력을 보여줍니다.

    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\"
            }
        }
        }]"
    Copy to Clipboard Toggle word wrap

5장. SR-IOV를 위한 RDMA 하위 시스템 구성

RDMA(원격 직접 메모리 액세스)를 사용하면 두 시스템의 운영 체제를 거치지 않고도 두 시스템 간의 직접 메모리 액세스가 가능합니다. SR-IOV(Single Root I/O Virtualization)에서 RDMA 컨테이너 네트워크 인터페이스(CNI)를 구성하여 컨테이너 간에 고성능, 저지연 통신을 구현할 수 있습니다. RDMA와 SR-IOV를 결합하면 DPDK(Data Plane Development Kit) 애플리케이션 내부에서 사용할 수 있도록 Mellanox 이더넷 장치의 하드웨어 카운터를 노출하는 메커니즘을 제공합니다.

5.1. SR-IOV RDMA CNI 구성

SR-IOV에서 RDMA CNI를 구성합니다.

참고

이 절차는 Mellanox 장치에만 적용됩니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • SR-IOV Network Operator가 설치되어 있습니다.

프로세스

  1. 다음 예와 같이 SriovNetworkPoolConfig CR을 만들고 sriov-nw-pool.yaml 로 저장합니다.

    예제 SriovNetworkPoolConfig CR

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkPoolConfig
    metadata:
      name: worker
      namespace: openshift-sriov-network-operator
    spec:
      maxUnavailable: 1
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/worker: ""
      rdmaMode: exclusive 
    1
    Copy to Clipboard Toggle word wrap

    1
    RDMA 네트워크 네임스페이스 모드를 배타 로 설정합니다.
  2. 다음 명령을 실행하여 SriovNetworkPoolConfig 리소스를 만듭니다.

    $ oc create -f sriov-nw-pool.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 예와 같이 SriovNetworkNodePolicy CR을 만들고 sriov-node-policy.yaml 로 저장합니다.

    예제 SriovNetworkNodePolicy CR

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: sriov-nic-pf1
      namespace: openshift-sriov-network-operator
    spec:
      deviceType: netdevice
      isRdma: true 
    1
    
      nicSelector:
        pfNames: ["ens3f0np0"]
      nodeSelector:
        node-role.kubernetes.io/worker: ""
      numVfs: 4
      priority: 99
      resourceName: sriov_nic_pf1
    Copy to Clipboard Toggle word wrap

    1
    RDMA 모드를 활성화합니다.
  4. 다음 명령을 실행하여 SriovNetworkNodePolicy 리소스를 만듭니다.

    $ oc create -f sriov-node-policy.yaml
    Copy to Clipboard Toggle word wrap
  5. 다음 예와 같이 SriovNetwork CR을 만들고 sriov-network.yaml 로 저장합니다.

    예시 SriovNetwork CR

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: sriov-nic-pf1
      namespace: openshift-sriov-network-operator
    spec:
      networkNamespace: sriov-tests
      resourceName: sriov_nic_pf1
        ipam: |-
      metaPlugins: |
        {
          "type": "rdma" 
    1
    
        }
    Copy to Clipboard Toggle word wrap

    1
    RDMA 플러그인을 생성합니다.
  6. 다음 명령을 실행하여 SriovNetwork 리소스를 만듭니다.

    $ oc create -f sriov-network.yaml
    Copy to Clipboard Toggle word wrap

검증

  1. 다음 예와 같이 Pod CR을 만들고 sriov-test-pod.yaml 로 저장합니다.

    런타임 구성 예

    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"]
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 테스트 포드를 만듭니다.

    $ oc create -f sriov-test-pod.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 테스트 포드에 로그인합니다.

    $ oc rsh testpod1 -n sriov-tests
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 hw-counters 디렉토리 경로가 있는지 확인하세요.

    $ ls /sys/bus/pci/devices/${PCIDEVICE_OPENSHIFT_IO_SRIOV_NIC_PF1}/infiniband/*/ports/1/hw_counters/
    Copy to Clipboard Toggle word wrap

    출력 예

    duplicate_request       out_of_buffer req_cqe_flush_error           resp_cqe_flush_error        roce_adp_retrans        roce_slow_restart_trans
    implied_nak_seq_err     out_of_sequence req_remote_access_errors    resp_local_length_error     roce_adp_retrans_to     rx_atomic_requests
    lifespan                packet_seq_err req_remote_invalid_request   resp_remote_access_errors   roce_slow_restart       rx_read_requests
    local_ack_timeout_err  req_cqe_error resp_cqe_error                 rnr_nak_retry_err           roce_slow_restart_cnps  rx_write_requests
    Copy to Clipboard Toggle word wrap

클러스터 관리자는 SR-IOV 네트워크 장치에 연결된 포드에 대한 컨테이너 네트워크 인터페이스(CNI) 메타 플러그인을 사용하여 인터페이스 수준 네트워크 sysctl과 무차별 모드, 전체 멀티캐스트 모드, MTU, MAC 주소와 같은 여러 인터페이스 속성을 변경할 수 있습니다.

다음 문서의 작업을 수행하기 전에 SR-IOV 네트워크 운영자가 설치되어 있는지 확인하세요.

6.1. SR-IOV가 활성화된 NIC를 사용하여 노드 레이블 지정

SR-IOV가 가능한 노드에서만 SR-IOV를 활성화하려면 몇 가지 방법이 있습니다.

  1. 노드 기능 검색(NFD) 연산자를 설치합니다. NFD는 SR-IOV가 활성화된 NIC의 존재를 감지하고 노드에 node.alpha.kubernetes-incubator.io/nfd-network-sriov.capable = true 라는 레이블을 지정합니다.
  2. 각 노드에 대한 SriovNetworkNodeState CR을 조사합니다. 인터페이스 스탠자에는 작업자 노드에서 Operator가 감지한 모든 SR-IOV 장치 목록이 포함되어 있습니다. 다음 명령을 사용하여 각 노드에 feature.node.kubernetes.io/network-sriov.capable: "true"라는 레이블을 지정합니다.

    $ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
    Copy to Clipboard Toggle word wrap
    참고

    원하는 이름으로 노드에 라벨을 지정할 수 있습니다.

6.2. 하나의 sysctl 플래그 설정

SR-IOV 네트워크 장치에 연결된 Pod에 대해 인터페이스 수준 네트워크 sysctl 설정을 지정할 수 있습니다.

이 예에서 net.ipv4.conf.IFNAME.accept_redirects는 생성된 가상 인터페이스에서 1 로 설정됩니다.

이 예제에서는 sysctl-tuning-test가 사용된 네임스페이스입니다.

  • 다음 명령을 사용하여 sysctl-tuning-test 네임스페이스를 만듭니다.

    $ oc create namespace sysctl-tuning-test
    Copy to Clipboard Toggle word wrap

6.2.1. SR-IOV 네트워크 장치가 있는 노드에 하나의 sysctl 플래그 설정

SR-IOV Network Operator는 SriovNetworkNodePolicy.sriovnetwork.openshift.io CustomResourceDefinition을 OpenShift Container Platform에 추가합니다. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 만들어 SR-IOV 네트워크 장치를 구성할 수 있습니다.

참고

SriovNetworkNodePolicy 개체에 지정된 구성을 적용할 때 SR-IOV 운영자가 노드를 비우고 재부팅할 수 있습니다.

구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.

SriovNetworkNodePolicy 사용자 정의 리소스(CR)를 생성하려면 다음 절차를 따르세요.

프로세스

  1. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성합니다. 예를 들어, 다음 YAML을 policyoneflag-sriov-node-network.yaml 파일로 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: policyoneflag 
    1
    
      namespace: openshift-sriov-network-operator 
    2
    
    spec:
      resourceName: policyoneflag 
    3
    
      nodeSelector: 
    4
    
        feature.node.kubernetes.io/network-sriov.capable="true"
      priority: 10 
    5
    
      numVfs: 5 
    6
    
      nicSelector: 
    7
    
        pfNames: ["ens5"] 
    8
    
      deviceType: "netdevice" 
    9
    
      isRdma: false 
    10
    Copy to Clipboard Toggle word wrap
    1
    사용자 정의 리소스 오브젝트의 이름입니다.
    2
    SR-IOV Network Operator가 설치된 네임스페이스입니다.
    3
    SR-IOV 네트워크 장치 플러그인의 리소스 이름입니다. 리소스 이름에 대한 SR-IOV 네트워크 노드 정책을 여러 개 생성할 수 있습니다.
    4
    노드 선택기는 구성할 노드를 지정합니다. 선택한 노드의 SR-IOV 네트워크 장치만 구성됩니다. SR-IOV CNI(Container Network Interface) 플러그인 및 장치 플러그인은 선택된 노드에만 배포됩니다.
    5
    선택 사항: 우선순위는 0에서 99 사이의 정수 값입니다. 작은 값은 우선순위가 높습니다. 예를 들어 우선순위 10은 우선순위 99보다 높습니다. 기본값은 99입니다.
    6
    SR-IOV 물리적 네트워크 장치에 생성할 VF(가상 기능) 수입니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는 128보다 클 수 없습니다.
    7
    NIC 선택기는 Operator가 구성할 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다. rootDevices를 지정하면 vendor, deviceID 또는 pfNames의 값도 지정해야 합니다. pfNamesrootDevices를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오. netFilter의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다.
    8
    선택사항: 장치에 대해 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.
    9
    선택사항: 가상 기능의 드라이버 유형입니다. 허용되는 값은 netdevice 뿐입니다. Mellanox NIC가 베어 메탈 노드에서 DPDK 모드로 작동하려면 isRdma를 true 로 설정합니다.
    10
    선택 사항: 원격 직접 메모리 액세스(RDMA) 모드를 활성화할지 여부를 구성합니다. 기본값은 false입니다. isRdma 매개변수가 true로 설정된 경우 RDMA 사용 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다. isRdmatrue로 설정하고 추가로 needVhostNettrue로 설정하여 Fast Datapath DPDK 애플리케이션에서 사용할 Mellanox NIC를 구성합니다.
    참고

    vfio-pci 드라이버 유형이 지원되지 않습니다.

  2. SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f policyoneflag-sriov-node-network.yaml
    Copy to Clipboard Toggle word wrap

    구성 업데이트를 적용한 후 sriov-network-operator 네임스페이스의 모든 포드가 실행 상태로 변경됩니다.

  3. SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다. <node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다. 예상 출력은 Succeeded 입니다.

    $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
    Copy to Clipboard Toggle word wrap

6.2.2. SR-IOV 네트워크에서 sysctl 구성

SR-IOV에서 생성된 가상 인터페이스에 인터페이스별 sysctl 설정을 지정하려면 SriovNetwork 리소스의 선택적 metaPlugins 매개변수에 튜닝 구성을 추가합니다.

SR-IOV Network Operator는 추가 네트워크 정의를 관리합니다. 생성할 추가 SR-IOV 네트워크를 지정하면 SR-IOV Network Operator가 NetworkAttachmentDefinition CR(사용자 정의 리소스)을 자동으로 생성합니다.

참고

SR-IOV Network Operator가 관리하는 NetworkAttachmentDefinition 사용자 정의 리소스를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

인터페이스 수준 네트워크 net.ipv4.conf.IFNAME.accept_redirects sysctl 설정을 변경하려면 컨테이너 네트워크 인터페이스(CNI) 튜닝 플러그인을 사용하여 추가 SR-IOV 네트워크를 만듭니다.

사전 요구 사항

  • OpenShift Container Platform CLI, oc를 설치합니다.
  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.

프로세스

  1. 추가 SR-IOV 네트워크 연결에 대한 SriovNetwork CR(사용자 정의 리소스)을 생성하고 다음 예제 CR과 같이 metaPlugins 구성을 삽입합니다. YAML을 sriov-network-interface-sysctl.yaml 파일로 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: onevalidflag 
    1
    
      namespace: openshift-sriov-network-operator 
    2
    
    spec:
      resourceName: policyoneflag 
    3
    
      networkNamespace: sysctl-tuning-test 
    4
    
      ipam: '{ "type": "static" }' 
    5
    
      capabilities: '{ "mac": true, "ips": true }' 
    6
    
      metaPlugins : | 
    7
    
        {
          "type": "tuning",
          "capabilities":{
            "mac":true
          },
          "sysctl":{
             "net.ipv4.conf.IFNAME.accept_redirects": "1"
          }
        }
    Copy to Clipboard Toggle word wrap
    1
    오브젝트의 이름입니다. SR-IOV 네트워크 운영자는 동일한 이름으로 NetworkAttachmentDefinition 객체를 생성합니다.
    2
    SR-IOV Network Operator가 설치된 네임스페이스입니다.
    3
    이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는 SriovNetworkNodePolicy 오브젝트의 spec.resourceName 매개변수 값입니다.
    4
    SriovNetwork 오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 추가 네트워크에 연결할 수 있습니다.
    5
    YAML 블록 스칼라로서 IPAM CNI 플러그인에 대한 구성 개체입니다. 이 플러그인은 첨부 파일 정의에 대한 IP 주소 할당을 관리합니다.
    6
    선택 사항: 추가 네트워크에 대한 기능을 설정합니다. "{"ips": true}" 를 지정하여 IP 주소 지원을 활성화하거나 "{"mac":true}"를 지정하여 MAC 주소 지원을 활성화할 수 있습니다.
    7
    선택 사항: metaPlugins 매개변수는 장치에 추가 기능을 추가하는 데 사용됩니다. 이 사용 사례에서는 유형 필드를 튜닝 으로 설정합니다. sysctl 필드에 설정하려는 인터페이스 수준 네트워크 sysctl을 지정합니다.
  2. SriovNetwork 리소스를 생성합니다.

    $ oc create -f sriov-network-interface-sysctl.yaml
    Copy to Clipboard Toggle word wrap

NetworkAttachmentDefinition CR이 성공적으로 생성되었는지 확인

  • 다음 명령을 실행하여 SR-IOV 네트워크 운영자가 NetworkAttachmentDefinition CR을 생성했는지 확인하세요.

    $ oc get network-attachment-definitions -n <namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <네임스페이스>를 SriovNetwork 개체에서 지정한 networkNamespace 값으로 바꾸세요. 예를 들어, sysctl-tuning-test . 예상되는 출력에는 NAD CRD의 이름과 생성 시간(분)이 표시됩니다.
    참고

    SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

추가 SR-IOV 네트워크 연결에 성공했는지 확인

튜닝 CNI가 올바르게 구성되었고 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행합니다.

  1. Pod CR을 생성합니다. 다음 YAML을 examplepod.yaml 파일로 저장합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: tunepod
      namespace: sysctl-tuning-test
      annotations:
        k8s.v1.cni.cncf.io/networks: |-
          [
            {
              "name": "onevalidflag",  
    1
    
              "mac": "0a:56:0a:83:04:0c", 
    2
    
              "ips": ["10.100.100.200/24"] 
    3
    
           }
          ]
    spec:
      containers:
      - name: podexample
        image: centos
        command: ["/bin/bash", "-c", "sleep INF"]
        securityContext:
          runAsUser: 2000
          runAsGroup: 3000
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
    Copy to Clipboard Toggle word wrap
    1
    SR-IOV 네트워크 연결 정의 CR의 이름입니다.
    2
    선택사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 MAC 주소입니다. 이 기능을 사용하려면 SriovNetwork 개체에서 { "mac": true } 도 지정해야 합니다.
    3
    선택 사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 IP 주소입니다. IPv4 및 IPv6 주소가 모두 지원됩니다. 이 기능을 사용하려면 SriovNetwork 오브젝트에 { "ips": true }도 지정해야 합니다.
  2. Pod CR 만들기:

    $ oc apply -f examplepod.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 Pod가 생성되었는지 확인하세요.

    $ oc get pod -n sysctl-tuning-test
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      READY   STATUS    RESTARTS   AGE
    tunepod   1/1     Running   0          47s
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 Pod에 로그인합니다.

    $ oc rsh -n sysctl-tuning-test tunepod
    Copy to Clipboard Toggle word wrap
  5. 구성된 sysctl 플래그의 값을 확인합니다. 다음 명령을 실행하여 net.ipv4.conf.IFNAME.accept_redirects 값을 찾으세요.

    $ sysctl net.ipv4.conf.net1.accept_redirects
    Copy to Clipboard Toggle word wrap

본딩된 SR-IOV 네트워크 장치에 연결된 포드에 대해 인터페이스 수준 네트워크 sysctl 설정을 지정할 수 있습니다.

이 예에서는 구성 가능한 특정 네트워크 인터페이스 수준 sysctl 설정이 본딩된 인터페이스에 설정됩니다.

이 예제에서는 sysctl-tuning-test가 사용된 네임스페이스입니다.

  • 다음 명령을 사용하여 sysctl-tuning-test 네임스페이스를 만듭니다.

    $ oc create namespace sysctl-tuning-test
    Copy to Clipboard Toggle word wrap

6.3.1. SR-IOV 네트워크 장치가 연결된 노드에서 모든 sysctl 플래그 설정

SR-IOV 네트워크 운영자는 OpenShift Container Platform에 SriovNetworkNodePolicy.sriovnetwork.openshift.io 사용자 정의 리소스 정의(CRD)를 추가합니다. SriovNetworkNodePolicy 사용자 정의 리소스(CR)를 생성하여 SR-IOV 네트워크 장치를 구성할 수 있습니다.

참고

SriovNetworkNodePolicy 개체에 지정된 구성을 적용할 때 SR-IOV 운영자는 노드를 비우고, 어떤 경우에는 노드를 재부팅할 수 있습니다.

구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.

SriovNetworkNodePolicy 사용자 정의 리소스(CR)를 생성하려면 다음 절차를 따르세요.

프로세스

  1. SriovNetworkNodePolicy 사용자 정의 리소스(CR)를 만듭니다. 다음 YAML을 policyallflags-sriov-node-network.yaml 파일로 저장합니다. policyallflags를 구성의 이름으로 바꾸세요.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: policyallflags 
    1
    
      namespace: openshift-sriov-network-operator 
    2
    
    spec:
      resourceName: policyallflags 
    3
    
      nodeSelector: 
    4
    
        node.alpha.kubernetes-incubator.io/nfd-network-sriov.capable = `true`
      priority: 10 
    5
    
      numVfs: 5 
    6
    
      nicSelector: 
    7
    
        pfNames: ["ens1f0"]  
    8
    
      deviceType: "netdevice" 
    9
    
      isRdma: false 
    10
    Copy to Clipboard Toggle word wrap
    1
    사용자 정의 리소스 오브젝트의 이름입니다.
    2
    SR-IOV Network Operator가 설치된 네임스페이스입니다.
    3
    SR-IOV 네트워크 장치 플러그인의 리소스 이름입니다. 리소스 이름에 대한 SR-IOV 네트워크 노드 정책을 여러 개 생성할 수 있습니다.
    4
    노드 선택기는 구성할 노드를 지정합니다. 선택한 노드의 SR-IOV 네트워크 장치만 구성됩니다. SR-IOV 컨테이너 네트워크 인터페이스(CNI) 플러그인과 장치 플러그인은 선택된 노드에만 배포됩니다.
    5
    선택 사항: 우선순위는 0에서 99 사이의 정수 값입니다. 작은 값은 우선순위가 높습니다. 예를 들어 우선순위 10은 우선순위 99보다 높습니다. 기본값은 99입니다.
    6
    SR-IOV 물리적 네트워크 장치에 대해 생성할 가상 기능(VF)의 수입니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는 127 보다 클 수 없습니다.
    7
    NIC 선택기는 Operator가 구성할 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다. rootDevices를 지정하면 vendor, deviceID 또는 pfNames의 값도 지정해야 합니다. pfNamesrootDevices를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오. netFilter의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다.
    8
    선택사항: 장치에 대해 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.
    9
    선택사항: 가상 기능의 드라이버 유형입니다. 허용되는 값은 netdevice 뿐입니다. Mellanox NIC가 베어 메탈 노드에서 DPDK 모드로 작동하려면 isRdma를 true 로 설정합니다.
    10
    선택 사항: 원격 직접 메모리 액세스(RDMA) 모드를 활성화할지 여부를 구성합니다. 기본값은 false입니다. isRdma 매개변수가 true로 설정된 경우 RDMA 사용 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다. isRdmatrue로 설정하고 추가로 needVhostNettrue로 설정하여 Fast Datapath DPDK 애플리케이션에서 사용할 Mellanox NIC를 구성합니다.
    참고

    vfio-pci 드라이버 유형이 지원되지 않습니다.

  2. SriovNetworkNodePolicy 객체를 생성합니다.

    $ oc create -f policyallflags-sriov-node-network.yaml
    Copy to Clipboard Toggle word wrap

    구성 업데이트를 적용한 후 sriov-network-operator 네임스페이스의 모든 포드가 실행 상태로 변경됩니다.

  3. SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다. <node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다. 예상 출력은 Succeeded로 표시됩니다.

    $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
    Copy to Clipboard Toggle word wrap

6.3.2. 본딩된 SR-IOV 네트워크에서 sysctl 구성

두 개의 SR-IOV 인터페이스에서 생성된 본딩 인터페이스에 인터페이스별 sysctl 설정을 지정할 수 있습니다. 이를 위해서는 본드 네트워크 첨부 정의의 선택적 플러그인 매개변수에 튜닝 구성을 추가해야 합니다.

참고

SR-IOV Network Operator가 관리하는 NetworkAttachmentDefinition 사용자 정의 리소스를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

특정 인터페이스 수준 네트워크 sysctl 설정을 변경하려면 다음 절차를 사용하여 컨테이너 네트워크 인터페이스(CNI) 튜닝 플러그인으로 SriovNetwork 사용자 정의 리소스(CR)를 만듭니다.

사전 요구 사항

  • OpenShift Container Platform CLI, oc를 설치합니다.
  • cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.

프로세스

  1. 다음 예제 CR과 같이 본딩된 인터페이스에 대한 SriovNetwork 사용자 지정 리소스(CR)를 만듭니다. YAML을 sriov-network-attachment.yaml 파일로 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: allvalidflags 
    1
    
      namespace: openshift-sriov-network-operator 
    2
    
    spec:
      resourceName: policyallflags 
    3
    
      networkNamespace: sysctl-tuning-test 
    4
    
      capabilities: '{ "mac": true, "ips": true }' 
    5
    Copy to Clipboard Toggle word wrap
    1
    오브젝트의 이름입니다. SR-IOV 네트워크 운영자는 동일한 이름으로 NetworkAttachmentDefinition 객체를 생성합니다.
    2
    SR-IOV Network Operator가 설치된 네임스페이스입니다.
    3
    이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는 SriovNetworkNodePolicy 오브젝트의 spec.resourceName 매개변수 값입니다.
    4
    SriovNetwork 오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 추가 네트워크에 연결할 수 있습니다.
    5
    선택사항: 이 추가 네트워크에 구성할 수 있는 기능입니다. "{"ips": true}" 를 지정하여 IP 주소 지원을 활성화하거나 "{"mac":true}"를 지정하여 MAC 주소 지원을 활성화할 수 있습니다.
  2. SriovNetwork 리소스를 생성합니다.

    $ oc create -f sriov-network-attachment.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 CR 예제와 같이 본드 네트워크 첨부 정의를 만듭니다. YAML을 sriov-bond-network-interface.yaml 파일로 저장합니다.

    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: bond-sysctl-network
      namespace: sysctl-tuning-test
    spec:
      config: '{
      "cniVersion":"0.4.0",
      "name":"bound-net",
      "plugins":[
        {
          "type":"bond", 
    1
    
          "mode": "active-backup", 
    2
    
          "failOverMac": 1, 
    3
    
          "linksInContainer": true, 
    4
    
          "miimon": "100",
          "links": [ 
    5
    
            {"name": "net1"},
            {"name": "net2"}
          ],
          "ipam":{ 
    6
    
            "type":"static"
          }
        },
        {
          "type":"tuning", 
    7
    
          "capabilities":{
            "mac":true
          },
          "sysctl":{
            "net.ipv4.conf.IFNAME.accept_redirects": "0",
            "net.ipv4.conf.IFNAME.accept_source_route": "0",
            "net.ipv4.conf.IFNAME.disable_policy": "1",
            "net.ipv4.conf.IFNAME.secure_redirects": "0",
            "net.ipv4.conf.IFNAME.send_redirects": "0",
            "net.ipv6.conf.IFNAME.accept_redirects": "0",
            "net.ipv6.conf.IFNAME.accept_source_route": "1",
            "net.ipv6.neigh.IFNAME.base_reachable_time_ms": "20000",
            "net.ipv6.neigh.IFNAME.retrans_time_ms": "2000"
          }
        }
      ]
    }'
    Copy to Clipboard Toggle word wrap
    1
    유형은 채권 입니다.
    2
    모드 속성은 본딩 모드를 지정합니다. 지원되는 본딩 모드는 다음과 같습니다.
    • 균형-rr - 0
    • 활성 백업 - 1
    • 밸런스-xor -2

      balance-rr 또는 balance-xor 모드의 경우 SR-IOV 가상 함수에 대한 신뢰 모드를 켜짐 으로 설정해야 합니다.

    3
    장애 조치(failover) 속성은 액티브 백업 모드에 필수입니다.
    4
    linksInContainer=true 플래그는 필요한 인터페이스가 컨테이너 내부에서 발견된다는 것을 Bond CNI에 알립니다. 기본적으로 Bond CNI는 SRIOV 및 Multus와의 통합에 적합하지 않은 호스트에서 이러한 인터페이스를 찾습니다.
    5
    링크 섹션은 본드를 생성하는 데 사용될 인터페이스를 정의합니다. 기본적으로 Multus는 연결된 인터페이스의 이름을 "net"과 1부터 시작하는 연속된 숫자로 지정합니다.
    6
    YAML 블록 스칼라로서 IPAM CNI 플러그인에 대한 구성 개체입니다. 이 플러그인은 첨부 파일 정의에 대한 IP 주소 할당을 관리합니다. 이 포드 예제에서는 IP 주소가 수동으로 구성되므로 이 경우 ipam이 정적으로 설정됩니다.
    7
    장치에 추가 기능을 추가합니다. 예를 들어, 유형 필드를 튜닝 으로 설정합니다. sysctl 필드에 설정하려는 인터페이스 수준 네트워크 sysctl을 지정합니다. 이 예제에서는 설정할 수 있는 모든 인터페이스 수준 네트워크 sysctl 설정을 지정합니다.
  4. 본드 네트워크 첨부 리소스를 만듭니다.

    $ oc create -f sriov-bond-network-interface.yaml
    Copy to Clipboard Toggle word wrap

NetworkAttachmentDefinition CR이 성공적으로 생성되었는지 확인

  • 다음 명령을 실행하여 SR-IOV 네트워크 운영자가 NetworkAttachmentDefinition CR을 생성했는지 확인하세요.

    $ oc get network-attachment-definitions -n <namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <네임스페이스>를 네트워크 연결을 구성할 때 지정한 네트워크네임스페이스(예: sysctl-tuning-test ) 로 바꿉니다. 예상 출력에는 NAD CRD의 이름과 생성 시간(분)이 표시됩니다.
    참고

    SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

추가 SR-IOV 네트워크 리소스가 성공했는지 확인

튜닝 CNI가 올바르게 구성되었고 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행합니다.

  1. Pod CR을 생성합니다. 예를 들어, 다음 YAML을 examplepod.yaml 파일로 저장합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: tunepod
      namespace: sysctl-tuning-test
      annotations:
        k8s.v1.cni.cncf.io/networks: |-
          [
            {"name": "allvalidflags"}, 
    1
    
            {"name": "allvalidflags"},
            {
              "name": "bond-sysctl-network",
              "interface": "bond0",
              "mac": "0a:56:0a:83:04:0c", 
    2
    
              "ips": ["10.100.100.200/24"] 
    3
    
           }
          ]
    spec:
      containers:
      - name: podexample
        image: centos
        command: ["/bin/bash", "-c", "sleep INF"]
        securityContext:
          runAsUser: 2000
          runAsGroup: 3000
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
    Copy to Clipboard Toggle word wrap
    1
    SR-IOV 네트워크 연결 정의 CR의 이름입니다.
    2
    선택사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 MAC 주소입니다. 이 기능을 사용하려면 SriovNetwork 개체에서 { "mac": true } 도 지정해야 합니다.
    3
    선택 사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 IP 주소입니다. IPv4 및 IPv6 주소가 모두 지원됩니다. 이 기능을 사용하려면 SriovNetwork 오브젝트에 { "ips": true }도 지정해야 합니다.
  2. YAML을 적용합니다.

    $ oc apply -f examplepod.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 Pod가 생성되었는지 확인하세요.

    $ oc get pod -n sysctl-tuning-test
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      READY   STATUS    RESTARTS   AGE
    tunepod   1/1     Running   0          47s
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 Pod에 로그인합니다.

    $ oc rsh -n sysctl-tuning-test tunepod
    Copy to Clipboard Toggle word wrap
  5. 구성된 sysctl 플래그의 값을 확인합니다. 다음 명령을 실행하여 net.ipv6.neigh.IFNAME.base_reachable_time_ms 값을 찾으세요.

    $ sysctl net.ipv6.neigh.bond0.base_reachable_time_ms
    Copy to Clipboard Toggle word wrap

6.4. 모든 멀티캐스트 모드에 대하여

특히 루트가 없는 애플리케이션의 경우 모든 멀티캐스트 모드를 활성화하는 것이 중요합니다. 이 모드를 활성화하지 않으면 포드의 보안 컨텍스트 제약 조건(SCC)에 NET_ADMIN 기능을 부여해야 합니다. NET_ADMIN 기능을 통해 포드에 특정 요구 사항을 넘어서는 변경 권한을 부여할 경우 잠재적으로 보안 취약점이 노출될 수 있습니다.

튜닝 CNI 플러그인은 모든 멀티캐스트 모드를 포함한 여러 인터페이스 속성 변경을 지원합니다. 이 모드를 활성화하면 SR-IOV 네트워크 장치에 구성된 가상 기능(VF)에서 실행되는 애플리케이션이 동일하거나 다른 물리적 기능에 연결된 다른 VF의 애플리케이션에서 멀티캐스트 트래픽을 수신할 수 있습니다.

6.4.1. SR-IOV 네트워크에서 모든 멀티캐스트 모드 활성화

SR-IOV 인터페이스에서 모든 멀티캐스트 모드를 활성화하려면 다음을 수행합니다.

  • SriovNetwork 리소스의 metaPlugins 매개변수에 튜닝 구성 추가
  • 튜닝 구성에서 allmulti 필드를 true 로 설정

    참고

    신뢰가 활성화된 상태에서 가상 기능(VF)을 생성했는지 확인하세요.

SR-IOV Network Operator는 추가 네트워크 정의를 관리합니다. 생성할 추가 SR-IOV 네트워크를 지정하면 SR-IOV Network Operator가 NetworkAttachmentDefinition CR(사용자 정의 리소스)을 자동으로 생성합니다.

참고

SR-IOV Network Operator가 관리하는 NetworkAttachmentDefinition 사용자 정의 리소스를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.

이 지침에 따라 SR-IOV 네트워크에서 모든 멀티캐스트 모드를 활성화하세요.

사전 요구 사항

  • OpenShift Container Platform CLI(oc)를 설치했습니다.
  • 클러스터 관리자 권한이 있는 사용자로 OpenShift Container Platform 클러스터에 로그인했습니다.
  • SR-IOV Network Operator가 설치되어 있습니다.
  • 적절한 SriovNetworkNodePolicy 객체를 구성했습니다.

프로세스

  1. Mellanox ConnectX-5 장치에 대한 SriovNetworkNodePolicy 객체를 정의하는 다음 설정을 사용하여 YAML 파일을 만듭니다. YAML 파일을 sriovnetpolicy-mlx.yaml 로 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: sriovnetpolicy-mlx
      namespace: openshift-sriov-network-operator
    spec:
      deviceType: netdevice
      nicSelector:
        deviceID: "1017"
        pfNames:
          - ens8f0np0#0-9
        rootDevices:
          - 0000:d8:00.0
        vendor: "15b3"
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true"
      numVfs: 10
      priority: 99
      resourceName: resourcemlx
    Copy to Clipboard Toggle word wrap
  2. 선택 사항: SR-IOV 지원 클러스터 노드에 아직 레이블이 지정되지 않은 경우 SriovNetworkNodePolicy.Spec.NodeSelector 레이블을 추가합니다. 노드에 레이블을 지정하는 방법에 대한 자세한 내용은 "노드의 레이블을 업데이트하는 방법 이해"를 참조하세요.
  3. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f sriovnetpolicy-mlx.yaml
    Copy to Clipboard Toggle word wrap

    구성 업데이트를 적용한 후 sriov-network-operator 네임스페이스의 모든 포드가 자동으로 실행 상태로 전환됩니다.

  4. 다음 명령을 실행하여 enable-allmulti-test 네임스페이스를 만듭니다.

    $ oc create namespace enable-allmulti-test
    Copy to Clipboard Toggle word wrap
  5. 다음 예제 CR YAML과 같이 추가 SR-IOV 네트워크 연결을 위한 SriovNetwork 사용자 지정 리소스(CR)를 만들고 metaPlugins 구성을 삽입한 다음, 파일을 sriov-enable-all-multicast.yaml 로 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: enableallmulti 
    1
    
      namespace: openshift-sriov-network-operator 
    2
    
    spec:
      resourceName: enableallmulti 
    3
    
      networkNamespace: enable-allmulti-test 
    4
    
      ipam: '{ "type": "static" }' 
    5
    
      capabilities: '{ "mac": true, "ips": true }' 
    6
    
      trust: "on" 
    7
    
      metaPlugins : | 
    8
    
        {
          "type": "tuning",
          "capabilities":{
            "mac":true
          },
          "allmulti": true
          }
        }
    Copy to Clipboard Toggle word wrap
    1
    오브젝트의 이름을 지정합니다. SR-IOV 네트워크 운영자는 동일한 이름으로 NetworkAttachmentDefinition 객체를 생성합니다.
    2
    SR-IOV Network Operator가 설치된 네임스페이스를 지정합니다.
    3
    이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는 SriovNetworkNodePolicy 개체의 spec.resourceName 매개변수에 대한 값을 지정합니다.
    4
    SriovNetwork 개체에 대한 대상 네임스페이스를 지정합니다. 대상 네임스페이스의 포드만 추가 네트워크에 연결할 수 있습니다.
    5
    IPAM CNI 플러그인에 대한 구성 객체를 YAML 블록 스칼라로 지정합니다. 이 플러그인은 첨부 파일 정의에 대한 IP 주소 할당을 관리합니다.
    6
    선택 사항: 추가 네트워크에 대한 기능을 설정합니다. "{"ips": true}" 를 지정하여 IP 주소 지원을 활성화하거나 "{"mac":true}"를 지정하여 MAC 주소 지원을 활성화할 수 있습니다.
    7
    가상 함수의 신뢰 모드를 지정합니다. 이 설정은 "켜짐"으로 설정되어야 합니다.
    8
    metaPlugins 매개변수를 사용하여 장치에 더 많은 기능을 추가합니다. 이 사용 사례에서는 type 필드를 tuning 으로 설정하고 allmulti 필드를 추가하고 true 로 설정합니다.
  6. 다음 명령을 실행하여 SriovNetwork 리소스를 만듭니다.

    $ oc create -f sriov-enable-all-multicast.yaml
    Copy to Clipboard Toggle word wrap

NetworkAttachmentDefinition CR 확인

  • 다음 명령을 실행하여 SR-IOV 네트워크 운영자가 NetworkAttachmentDefinition CR을 생성했는지 확인하세요.

    $ oc get network-attachment-definitions -n <namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <네임스페이스>를 SriovNetwork 개체에서 지정한 networkNamespace 값으로 바꾸세요. 이 예에서는 enable-allmulti-test 입니다. 예상되는 출력에는 NAD CR의 이름과 생성 시간(분)이 표시됩니다.
    참고

    SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.

    1. 다음 명령을 실행하여 SR-IOV 네트워크 리소스에 대한 정보를 표시합니다.

      $ oc get sriovnetwork -n openshift-sriov-network-operator
      Copy to Clipboard Toggle word wrap

추가 SR-IOV 네트워크 연결 확인

튜닝 CNI가 올바르게 구성되었고 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음 단계를 따르세요.

  1. Pod CR을 생성합니다. 다음 샘플 YAML을 examplepod.yaml 이라는 이름의 파일에 저장합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: samplepod
      namespace: enable-allmulti-test
      annotations:
        k8s.v1.cni.cncf.io/networks: |-
          [
            {
              "name": "enableallmulti",  
    1
    
              "mac": "0a:56:0a:83:04:0c", 
    2
    
              "ips": ["10.100.100.200/24"] 
    3
    
           }
          ]
    spec:
      containers:
      - name: podexample
        image: centos
        command: ["/bin/bash", "-c", "sleep INF"]
        securityContext:
          runAsUser: 2000
          runAsGroup: 3000
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
    Copy to Clipboard Toggle word wrap
    1
    SR-IOV 네트워크 연결 정의 CR의 이름을 지정합니다.
    2
    선택 사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 MAC 주소를 지정합니다. 이 기능을 사용하려면 SriovNetwork 개체에서 {"mac": true} 도 지정해야 합니다.
    3
    선택 사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 IP 주소를 지정합니다. IPv4 및 IPv6 주소가 모두 지원됩니다. 이 기능을 사용하려면 SriovNetwork 오브젝트에 { "ips": true }도 지정해야 합니다.
  2. 다음 명령을 실행하여 Pod CR을 만듭니다.

    $ oc apply -f examplepod.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 Pod가 생성되었는지 확인하세요.

    $ oc get pod -n enable-allmulti-test
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME       READY   STATUS    RESTARTS   AGE
    samplepod  1/1     Running   0          47s
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 Pod에 로그인합니다.

    $ oc rsh -n enable-allmulti-test samplepod
    Copy to Clipboard Toggle word wrap
  5. 다음 명령을 실행하여 Pod와 연결된 모든 인터페이스를 나열합니다.

    sh-4.4# ip link
    Copy to Clipboard Toggle word wrap

    출력 예

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    2: eth0@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8901 qdisc noqueue state UP mode DEFAULT group default
        link/ether 0a:58:0a:83:00:10 brd ff:ff:ff:ff:ff:ff link-netnsid 0 
    1
    
    3: net1@if24: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
        link/ether ee:9b:66:a4:ec:1d brd ff:ff:ff:ff:ff:ff link-netnsid 0 
    2
    Copy to Clipboard Toggle word wrap

    1
    eth0@if22 는 기본 인터페이스입니다
    2
    net1@if24는 모든 멀티캐스트 모드( ALLMULTI 플래그)를 지원하는 네트워크 연결 정의로 구성된 보조 인터페이스입니다.

7장. SR-IOV 지원 워크로드에 대한 QinQ 지원 구성

QinQ는 공식적으로 802.1Q-in-802.1Q로 알려져 있으며 IEEE 802.1ad에 의해 정의된 네트워킹 기술입니다. IEEE 802.1ad는 IEEE 802.1Q-1998 표준을 확장하고 이미 802.1Q 태그가 지정된 패킷에 추가적인 802.1Q 태그를 도입하여 VLAN 기능을 강화합니다. 이 방법은 VLAN 스태킹 또는 이중 VLAN이라고도 합니다.

다음 문서의 작업을 수행하기 전에 SR-IOV 네트워크 운영자가 설치되어 있는지 확인하세요.

7.1. 802.1Q 지원에 대한 802.1Q 정보

기존 VLAN 설정에서 프레임은 일반적으로 VLAN-100과 같은 단일 VLAN 태그와 QoS(서비스 품질) 비트 및 프로토콜 정보와 같은 기타 메타데이터를 포함합니다. QinQ는 두 번째 VLAN 태그를 도입하여 서비스 제공자가 외부 태그를 자체적으로 지정하여 유연성을 제공하는 반면, 내부 태그는 고객의 VLAN에 전용으로 유지됩니다.

QinQ는 이중 VLAN 태깅을 사용하여 중첩된 VLAN을 쉽게 생성하여 네트워크 환경 내에서 트래픽을 더욱 세밀하게 분할하고 격리할 수 있습니다. 이러한 접근 방식은 공통 인프라를 통해 여러 고객에게 VLAN 기반 서비스를 제공해야 하는 동시에 트래픽의 분리와 격리를 보장해야 하는 서비스 제공자 네트워크에서 특히 가치가 있습니다.

다음 다이어그램은 OpenShift Container Platform이 SR-IOV와 QinQ를 사용하여 컨테이너화된 워크로드에 대한 고급 네트워크 분할 및 격리를 달성하는 방법을 보여줍니다.

이 다이어그램은 SR-IOV를 지원하는 워커 노드에서 이중 VLAN 태깅(QinQ)이 작동하는 방식을 보여줍니다. Pod 네임스페이스 ext0 에 위치한 SR-IOV 가상 기능(VF)은 VLAN ID와 VLAN 프로토콜을 사용하여 SR-IOV 컨테이너 네트워크 인터페이스(CNI)에 의해 구성됩니다. 이는 S-태그에 해당합니다. 포드 내부에서 VLAN CNI는 기본 인터페이스 ext0을 사용하여 하위 인터페이스를 생성합니다. 이 하위 인터페이스는 C 태그에 해당하는 802.1Q 프로토콜을 사용하여 내부 VLAN ID를 추가합니다.

이는 QinQ가 네트워크 내에서 트래픽을 어떻게 더 세밀하게 분할하고 격리하는지 보여줍니다. 오른쪽에는 이더넷 프레임 구조가 자세히 설명되어 있으며, VLAN 태그, EtherType, IP, TCP 및 페이로드 섹션이 모두 포함되어 있는 것을 강조하고 있습니다. QinQ는 트래픽 분리 및 격리를 보장하는 동시에 공유 인프라를 통해 여러 고객에게 VLAN 기반 서비스를 제공하기 쉽게 해줍니다.

OpenShift Container Platform SR-IOV 솔루션은 이미 SriovNetwork 사용자 정의 리소스(CR)에 VLAN 프로토콜을 설정하는 것을 지원합니다. 가상 기능(VF)은 이 프로토콜을 사용하여 VLAN 태그(외부 태그라고도 함)를 설정할 수 있습니다. 그런 다음 Pod는 VLAN CNI 플러그인을 사용하여 내부 태그를 구성할 수 있습니다.

Expand
표 7.1. 지원되는 네트워크 인터페이스 카드
NIC802.1ad/802.1Q802.1Q/802.1Q

Intel X710

없음

지원됨

Intel E810

지원됨

지원됨

Mellanox

없음

지원됨

7.2. SR-IOV 지원 워크로드에 대한 QinQ 지원 구성

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • SR-IOV Network Operator가 설치되어 있습니다.

프로세스

  1. 다음 내용을 사용하여 sriovnetpolicy-810-sriov-node-network.yaml 이라는 이름의 파일을 만듭니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: sriovnetpolicy-810
      namespace: openshift-sriov-network-operator
    spec:
      deviceType: netdevice
      nicSelector:
        pfNames:
          - ens5f0#0-9
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
      numVfs: 10
      priority: 99
      resourceName: resource810
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f sriovnetpolicy-810-sriov-node-network.yaml
    Copy to Clipboard Toggle word wrap
  3. 별도의 터미널 창을 열고 다음 명령을 실행하여 openshift-sriov-network-operator 네임스페이스에 지정된 노드의 SR-IOV 네트워크 노드 상태의 동기화 상태를 모니터링합니다.

    $ watch -n 1 'oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath="{.status.syncStatus}"'
    Copy to Clipboard Toggle word wrap

    동기화 상태가 InProgress 에서 Succeeded 로 변경되었음을 나타냅니다.

  4. SriovNetwork 객체를 생성하고 인프라에 속하므로 S-태그 또는 서비스 태그 라고 하는 외부 VLAN을 설정합니다.

    중요

    스위치의 트렁크 인터페이스에서 VLAN을 구성해야 합니다. 또한, QinQ 태깅을 지원하기 위해 일부 스위치를 추가로 구성해야 할 수도 있습니다.

    1. 다음 내용을 사용하여 nad-sriovnetwork-1ad-810.yaml 이라는 이름의 파일을 만듭니다.

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetwork
      metadata:
        name: sriovnetwork-1ad-810
        namespace: openshift-sriov-network-operator
      spec:
        ipam: '{}'
        vlan: 171 
      1
      
        vlanProto: "802.1ad" 
      2
      
        networkNamespace: default
        resourceName: resource810
      Copy to Clipboard Toggle word wrap
      1
      S-태그 VLAN 태그를 171 로 설정합니다.
      2
      가상 기능(VF)에 할당할 VLAN 프로토콜을 지정합니다. 지원되는 값은 802.1ad802.1q 입니다. 기본값은 802.1q 입니다.
    2. 다음 명령을 실행하여 객체를 생성합니다.

      $ oc create -f nad-sriovnetwork-1ad-810.yaml
      Copy to Clipboard Toggle word wrap
  5. 내부 VLAN이 있는 NetworkAttachmentDefinition 객체를 만듭니다. 내부 VLAN은 네트워크 기능에 속하므로 종종 C 태그 또는 고객 태그 라고 합니다.

    1. 다음 내용을 사용하여 nad-cvlan100.yaml 이라는 파일을 만듭니다.

      apiVersion: k8s.cni.cncf.io/v1
      kind: NetworkAttachmentDefinition
      metadata:
        name: nad-cvlan100
        namespace: default
      spec:
        config: '{
          "name": "vlan-100",
          "cniVersion": "0.3.1",
          "type": "vlan",
          "linkInContainer": true,
          "master": "net1", 
      1
      
          "vlanId": 100,
          "ipam": {"type": "static"}
        }'
      Copy to Clipboard Toggle word wrap
      1
      포드 내부의 VF 인터페이스를 지정합니다. Pod 주석에 이름이 설정되지 않았으므로 기본 이름은 net1 입니다.
    2. 다음 명령을 실행하여 YAML 파일을 적용합니다.

      $ oc apply -f nad-cvlan100.yaml
      Copy to Clipboard Toggle word wrap

검증

  • 다음 절차에 따라 노드에서 QinQ가 활성화되어 있는지 확인하세요.

    1. 다음 내용을 사용하여 test-qinq-pod.yaml 이라는 파일을 만듭니다.

      apiVersion: v1
      kind: Pod
      metadata:
        name: test-pod
        annotations:
          k8s.v1.cni.cncf.io/networks: sriovnetwork-1ad-810, nad-cvlan100
      spec:
        containers:
          - name: test-container
            image: quay.io/ocp-edge-qe/cnf-gotests-client:v4.10
            imagePullPolicy: Always
            securityContext:
              privileged: true
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 테스트 포드를 만듭니다.

      $ oc create -f test-qinq-pod.yaml
      Copy to Clipboard Toggle word wrap
    3. 다음 명령을 실행하여 포드가 있는 대상 노드에서 디버그 세션을 시작하고 네트워크 인터페이스 ens5f0 에 대한 정보를 표시합니다.

      $ oc debug node/my-cluster-node -- bash -c "ip link show ens5f0"
      Copy to Clipboard Toggle word wrap

      출력 예

      6: ens5f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
      link/ether b4:96:91:a5:22:10 brd ff:ff:ff:ff:ff:ff
      vf 0 link/ether a2:81:ba:d0:6f:f3 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
      vf 1 link/ether 8a:bb:0a:36:f2:ed brd ff:ff:ff:ff:ff:ff, vlan 171, vlan protocol 802.1ad, spoof checking on, link-state auto, trust off
      vf 2 link/ether ca:0e:e1:5b:0c:d2 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
      vf 3 link/ether ee:6c:e2:f5:2c:70 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
      vf 4 link/ether 0a:d6:b7:66:5e:e8 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
      vf 5 link/ether da:d5:e7:14:4f:aa brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
      vf 6 link/ether d6:8e:85:75:12:5c brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
      vf 7 link/ether d6:eb:ce:9c:ea:78 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
      vf 8 link/ether 5e:c5:cc:05:93:3c brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust on
      vf 9 link/ether a6:5a:7c:1c:2a:16 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
      Copy to Clipboard Toggle word wrap

      출력에 있는 VLAN 프로토콜 802.1ad ID는 인터페이스가 프로토콜 802.1ad(QinQ)를 사용하여 VLAN 태그를 지원함을 나타냅니다. VLAN ID는 171입니다.

8장. 고성능 멀티 캐스트 사용

SR-IOV(Single Root I/O Virtualization) 하드웨어 네트워크에서 멀티 캐스트를 사용할 수 있습니다.

다음 문서의 작업을 수행하기 전에 SR-IOV 네트워크 운영자가 설치되어 있는지 확인하세요.

8.1. 고성능 멀티캐스트

OVN-Kubernetes 네트워크 플러그인은 기본 네트워크의 포드 간 멀티캐스트를 지원합니다. 이는 고 대역폭 애플리케이션이 아닌 저 대역폭 조정 또는 서비스 검색에 가장 적합합니다. IPTV(Internet Protocol Television) 및 멀티 포인트 화상 회의와 같은 스트리밍 미디어와 같은 애플리케이션의 경우 SR-IOV(Single Root I/O Virtualization) 하드웨어를 사용하여 거의 네이티브와 같은 성능을 제공할 수 있습니다.

멀티 캐스트에 추가 SR-IOV 인터페이스를 사용하는 경우:

  • 멀티 캐스트 패키지는 추가 SR-IOV 인터페이스를 통해 pod에서 보내거나 받아야 합니다.
  • SR-IOV 인터페이스를 연결하는 물리적 네트워크는 멀티 캐스트 라우팅 및 토폴로지를 결정하며 OpenShift Container Platform에서 제어하지 않습니다.

8.2. 멀티캐스트를 위한 SR-IOV 인터페이스 구성

다음 프로시저는 멀티 캐스트용 SR-IOV 인터페이스 예제를 만듭니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

프로세스

  1. SriovNetworkNodePolicy 오브젝트를 생성합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: policy-example
      namespace: openshift-sriov-network-operator
    spec:
      resourceName: example
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true"
      numVfs: 4
      nicSelector:
        vendor: "8086"
        pfNames: ['ens803f0']
        rootDevices: ['0000:86:00.0']
    Copy to Clipboard Toggle word wrap
  2. SriovNetwork 오브젝트를 생성합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: net-example
      namespace: openshift-sriov-network-operator
    spec:
      networkNamespace: default
      ipam: | 
    1
    
        {
          "type": "host-local", 
    2
    
          "subnet": "10.56.217.0/24",
          "rangeStart": "10.56.217.171",
          "rangeEnd": "10.56.217.181",
          "routes": [
            {"dst": "224.0.0.0/5"},
            {"dst": "232.0.0.0/5"}
          ],
          "gateway": "10.56.217.1"
        }
      resourceName: example
    Copy to Clipboard Toggle word wrap
    1 2
    DHCP를 IPAM으로 구성하도록 선택한 경우 DHCP 서버를 통해 224.0.0.0/5232.0.0.0/5 기본 경로를 프로비저닝해야 합니다. 이는 기본 네트워크 공급자가 설정한 정적 멀티 캐스트 경로를 재정의하는 것입니다.
  3. 멀티 캐스트 애플리케이션으로 pod를 생성합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: testpmd
      namespace: default
      annotations:
        k8s.v1.cni.cncf.io/networks: nic1
    spec:
      containers:
      - name: example
        image: rhel7:latest
        securityContext:
          capabilities:
            add: ["NET_ADMIN"] 
    1
    
        command: [ "sleep", "infinity"]
    Copy to Clipboard Toggle word wrap
    1
    NET_ADMIN 기능은 애플리케이션이 멀티 캐스트 IP 주소를 SR-IOV 인터페이스에 할당해야 하는 경우에만 필요합니다. 그 밖의 경우에는 생략할 수 있습니다.

9장. DPDK 및 RDMA 사용

컨테이너화된 DPDK(Data Plane Development Kit) 애플리케이션은 OpenShift Container Platform에서 지원됩니다. DPDK(Data Plane Development Kit) 및 RDMA(Remote Direct Memory Access)와 함께 SR-IOV(Single Root I/O Virtualization) 네트워크 하드웨어를 사용할 수 있습니다.

다음 문서의 작업을 수행하기 전에 SR-IOV 네트워크 운영자가 설치되어 있는지 확인하세요.

9.1. 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"]
Copy to Clipboard Toggle word wrap

다음 예는 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
Copy to Clipboard Toggle word wrap

9.2. Intel NIC와 함께 DPDK 모드에서 가상 기능 사용

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • SR-IOV Network Operator 설치.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 다음 SriovNetworkNodePolicy 오브젝트를 생성한 다음 YAML을 intel-dpdk-node-policy.yaml 파일에 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: intel-dpdk-node-policy
      namespace: openshift-sriov-network-operator
    spec:
      resourceName: intelnics
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true"
      priority: <priority>
      numVfs: <num>
      nicSelector:
        vendor: "8086"
        deviceID: "158b"
        pfNames: ["<pf_name>", ...]
        rootDevices: ["<pci_bus_id>", "..."]
      deviceType: vfio-pci 
    1
    Copy to Clipboard Toggle word wrap
    1
    가상 기능의 드라이버 유형을 vfio-pci로 지정합니다.
    참고

    SriovNetworkNodePolicy의 각 옵션에 대한 자세한 설명은 Configuring SR-IOV network devices 섹션을 참조하십시오.

    SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.

    구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.

  2. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f intel-dpdk-node-policy.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 SriovNetwork 오브젝트를 생성한 다음 YAML을 intel-dpdk-network.yaml 파일에 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: intel-dpdk-network
      namespace: openshift-sriov-network-operator
    spec:
      networkNamespace: <target_namespace>
      ipam: |-
    # ... 
    1
    
      vlan: <vlan>
      resourceName: intelnics
    Copy to Clipboard Toggle word wrap
    1
    ipam CNI 플러그인에 대한 구성 객체를 YAML 블록 스칼라로 지정합니다. 이 플러그인은 첨부 파일 정의에 대한 IP 주소 할당을 관리합니다.
    참고

    SriovNetwork의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.

    선택적 라이브러리인 app-netutil은 컨테이너의 상위 pod에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.

  4. 다음 명령을 실행하여 SriovNetwork 오브젝트를 생성합니다.

    $ oc create -f intel-dpdk-network.yaml
    Copy to Clipboard Toggle word wrap
  5. 다음 Pod 사양을 생성한 다음 YAML을 intel-dpdk-pod.yaml 파일에 저장합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dpdk-app
      namespace: <target_namespace> 
    1
    
      annotations:
        k8s.v1.cni.cncf.io/networks: intel-dpdk-network
    spec:
      containers:
      - name: testpmd
        image: <DPDK_image> 
    2
    
        securityContext:
          runAsUser: 0
          capabilities:
            add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    3
    
        volumeMounts:
        - mountPath: /mnt/huge 
    4
    
          name: hugepage
        resources:
          limits:
            openshift.io/intelnics: "1" 
    5
    
            memory: "1Gi"
            cpu: "4" 
    6
    
            hugepages-1Gi: "4Gi" 
    7
    
          requests:
            openshift.io/intelnics: "1"
            memory: "1Gi"
            cpu: "4"
            hugepages-1Gi: "4Gi"
        command: ["sleep", "infinity"]
      volumes:
      - name: hugepage
        emptyDir:
          medium: HugePages
    Copy to Clipboard Toggle word wrap
    1
    SriovNetwork 오브젝트 intel-dpdk-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에 Pod를 만들려면 Pod 사양과 SriovNetwork 개체 모두에서 target_namespace를 변경하세요.
    2
    애플리케이션 및 애플리케이션이 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.
    3
    hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
    4
    DPDK 포드의 /mnt/huge 아래에 hugepage 볼륨을 마운트합니다. hugepage 볼륨은 매체가 Hugepages인 emptyDir 볼륨 유형으로 지원됩니다.
    5
    선택사항: DPDK Pod에 할당된 DPDK 장치 수를 지정합니다. 명시적으로 지정되지 않은 경우 이 리소스 요청 및 제한은 SR-IOV 네트워크 리소스 인젝터에 의해 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본 SriovOperatorConfig CR에서 enableInjector 옵션을 false로 설정하여 비활성화할 수 있습니다.
    6
    CPU 수를 지정합니다. DPDK pod는 일반적으로 kubelet에서 배타적 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을 static으로 설정하고 QoS가 보장된 Pod를 생성합니다.
    7
    hugepage 크기 hugepages-1Gi 또는 hugepages-2Mi를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다. 2Mi1Gi hugepage를 별도로 구성합니다. 1Gi hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다. 예를 들어, 커널 인수 default_hugepagesz = 1GB, hugepagesz = 1Ghugepages = 16을 추가하면 시스템 부팅 시 16 * 1Gi hugepage가 할당됩니다.
  6. 다음 명령을 실행하여 DPDK Pod를 생성합니다.

    $ oc create -f intel-dpdk-pod.yaml
    Copy to Clipboard Toggle word wrap

9.3. Mellanox NIC와 함께 DPDK 모드에서 가상 기능 사용

Mellanox NIC를 사용하여 DPDK 모드에서 가상 함수를 사용하여 네트워크 노드 정책을 만들고 DPDK(데이터 플레인 개발 키트) 포드를 만들 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • SR-IOV(Single Root I/O Virtualization) 네트워크 운영자를 설치했습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.

프로세스

  1. 다음 SriovNetworkNodePolicy YAML 구성을 mlx-dpdk-node-policy.yaml 파일에 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: mlx-dpdk-node-policy
      namespace: openshift-sriov-network-operator
    spec:
      resourceName: mlxnics
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true"
      priority: <priority>
      numVfs: <num>
      nicSelector:
        vendor: "15b3"
        deviceID: "1015" 
    1
    
        pfNames: ["<pf_name>", ...]
        rootDevices: ["<pci_bus_id>", "..."]
      deviceType: netdevice 
    2
    
      isRdma: true 
    3
    Copy to Clipboard Toggle word wrap
    1
    SR-IOV 네트워크 장치의 장치 16진수 코드를 지정합니다.
    2
    netdevice에 가상 기능의 드라이버 유형을 지정합니다. Mellanox SR-IOV 가상 기능(VF)은 vfio-pci 장치 유형을 사용하지 않고도 DPDK 모드에서 작동할 수 있습니다. VF 장치는 컨테이너 내부의 커널 네트워크 인터페이스로 나타납니다.
    3
    RDMA(원격 직접 메모리 액세스) 모드를 활성화합니다. 이는 Mellanox 카드가 DPDK 모드에서 작동하는 데 필요합니다.
    참고

    SriovNetworkNodePolicy 개체의 각 옵션에 대한 자세한 설명은 SR-IOV 네트워크 장치 구성을 참조하세요.

    SriovNetworkNodePolicy 개체에 지정된 구성을 적용할 때 SR-IOV 운영자는 노드를 비우고, 어떤 경우에는 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.

    구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.

  2. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f mlx-dpdk-node-policy.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 SriovNetwork YAML 구성을 mlx-dpdk-network.yaml 파일에 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: mlx-dpdk-network
      namespace: openshift-sriov-network-operator
    spec:
      networkNamespace: <target_namespace>
      ipam: |- 
    1
    
    ...
      vlan: <vlan>
      resourceName: mlxnics
    Copy to Clipboard Toggle word wrap
    1
    IP 주소 관리(IPAM) 컨테이너 네트워크 인터페이스(CNI) 플러그인에 대한 구성 객체를 YAML 블록 스칼라로 지정합니다. 이 플러그인은 첨부 파일 정의에 대한 IP 주소 할당을 관리합니다.
    참고

    SriovNetwork 개체의 각 옵션에 대한 자세한 설명은 SR-IOV 네트워크 장치 구성을 참조하세요.

    app-netutil 옵션 라이브러리는 컨테이너의 부모 Pod에 대한 네트워크 정보를 수집하기 위한 여러 가지 API 메서드를 제공합니다.

  4. 다음 명령을 실행하여 SriovNetwork 오브젝트를 생성합니다.

    $ oc create -f mlx-dpdk-network.yaml
    Copy to Clipboard Toggle word wrap
  5. 다음 Pod YAML 구성을 mlx-dpdk-pod.yaml 파일에 저장합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dpdk-app
      namespace: <target_namespace> 
    1
    
      annotations:
        k8s.v1.cni.cncf.io/networks: mlx-dpdk-network
    spec:
      containers:
      - name: testpmd
        image: <DPDK_image> 
    2
    
        securityContext:
          runAsUser: 0
          capabilities:
            add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    3
    
        volumeMounts:
        - mountPath: /mnt/huge 
    4
    
          name: hugepage
        resources:
          limits:
            openshift.io/mlxnics: "1" 
    5
    
            memory: "1Gi"
            cpu: "4" 
    6
    
            hugepages-1Gi: "4Gi" 
    7
    
          requests:
            openshift.io/mlxnics: "1"
            memory: "1Gi"
            cpu: "4"
            hugepages-1Gi: "4Gi"
        command: ["sleep", "infinity"]
      volumes:
      - name: hugepage
        emptyDir:
          medium: HugePages
    Copy to Clipboard Toggle word wrap
    1
    SriovNetwork 오브젝트 mlx-dpdk-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에 Pod를 생성하려면 Pod 사양과 SriovNetwork 개체 모두에서 target_namespace를 변경합니다.
    2
    애플리케이션 및 애플리케이션이 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.
    3
    hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
    4
    /mnt/huge 아래의 DPDK 포드에 hugepage 볼륨을 마운트합니다. hugepage 볼륨은 매체가 Hugepages인 emptyDir 볼륨 유형으로 지원됩니다.
    5
    선택사항: DPDK Pod에 할당되는 DPDK 장치 수를 지정합니다. 명시적으로 지정되지 않은 경우 이 리소스 요청 및 제한은 SR-IOV 네트워크 리소스 인젝터에 의해 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본 SriovOperatorConfig CR에서 enableInjector 옵션을 false로 설정하여 비활성화할 수 있습니다.
    6
    CPU 수를 지정합니다. DPDK 포드는 일반적으로 kubelet에서 독점적인 CPU가 할당되어야 합니다. 이렇게 하려면 CPU 관리자 정책을 정적 으로 설정하고 QoS(서비스 품질)가 보장된 포드를 만듭니다.
    7
    hugepage 크기 hugepages-1Gi 또는 hugepages-2Mi를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다. 2Mi1Gi hugepage를 별도로 구성합니다. 1Gi hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다.
  6. 다음 명령을 실행하여 DPDK Pod를 생성합니다.

    $ oc create -f mlx-dpdk-pod.yaml
    Copy to Clipboard Toggle word wrap

DPDK 애플리케이션은 virtio-user를 예외 경로로 사용하여 로그 메시지와 같은 특정 유형의 패킷을 커널에 주입하여 처리할 수 있습니다. 이 기능에 대한 자세한 내용은 Virtio_user를 예외 경로로 참조하세요.

OpenShift Container Platform 버전 4.14 이상에서는 권한이 없는 Pod를 사용하여 Tap CNI 플러그인과 함께 DPDK 애플리케이션을 실행할 수 있습니다. 이 기능을 사용하려면 SriovNetworkNodePolicy 개체 내에서 needVhostNet 매개변수를 true 로 설정하여 vhost-net 장치를 마운트해야 합니다.

그림 9.1. DPDK 및 TAP 구성 예시

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • SR-IOV Network Operator가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • 모든 노드에서 setsebools container_use_devices=on 이 루트로 설정되어 있는지 확인하세요.

    참고

    SELinux 부울 값을 설정하려면 Machine Config Operator를 사용하세요.

프로세스

  1. 다음 예시와 같은 내용을 포함하는 test-namespace.yaml 과 같은 파일을 만듭니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: test-namespace
      labels:
        pod-security.kubernetes.io/enforce: privileged
        pod-security.kubernetes.io/audit: privileged
        pod-security.kubernetes.io/warn: privileged
        security.openshift.io/scc.podSecurityLabelSync: "false"
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 새 네임스페이스 객체를 만듭니다.

    $ oc apply -f test-namespace.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 예시와 같은 내용을 포함하는 sriov-node-network-policy.yaml 과 같은 파일을 만듭니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
     name: sriovnic
     namespace: openshift-sriov-network-operator
    spec:
     deviceType: netdevice 
    1
    
     isRdma: true 
    2
    
     needVhostNet: true 
    3
    
     nicSelector:
       vendor: "15b3" 
    4
    
       deviceID: "101b" 
    5
    
       rootDevices: ["00:05.0"]
     numVfs: 10
     priority: 99
     resourceName: sriovnic
     nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true"
    Copy to Clipboard Toggle word wrap
    1
    이는 해당 프로필이 Mellanox 네트워크 인터페이스 컨트롤러(NIC)에 맞게 특별히 제작되었음을 나타냅니다.
    2
    isRdma를 true 로 설정하는 것은 Mellanox NIC에만 필요합니다.
    3
    이렇게 하면 /dev/net/tun/dev/vhost-net 장치가 컨테이너에 마운트되어 애플리케이션이 탭 장치를 생성하고 해당 탭 장치를 DPDK 워크로드에 연결할 수 있습니다.
    4
    선택 사항: SR-IOV 네트워크 장치의 벤더 16진수 코드입니다. 값 15b3은 Mellanox NIC와 연결됩니다.
    5
    선택사항: SR-IOV 네트워크 장치의 장치 16진수 코드입니다.
  4. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f sriov-node-network-policy.yaml
    Copy to Clipboard Toggle word wrap
  5. 다음 SriovNetwork 객체를 만든 다음 YAML을 sriov-network-attachment.yaml 파일에 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
     name: sriov-network
     namespace: openshift-sriov-network-operator
    spec:
     networkNamespace: test-namespace
     resourceName: sriovnic
     spoofChk: "off"
     trust: "on"
    Copy to Clipboard Toggle word wrap
    참고

    SriovNetwork의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.

    선택적 라이브러리인 app-netutil은 컨테이너의 상위 pod에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.

  6. 다음 명령을 실행하여 SriovNetwork 오브젝트를 생성합니다.

    $ oc create -f sriov-network-attachment.yaml
    Copy to Clipboard Toggle word wrap
  7. 다음 예시와 같은 내용으로 네트워크 연결 정의를 정의하는 tap-example.yaml 과 같은 파일을 만듭니다.

    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
     name: tap-one
     namespace: test-namespace 
    1
    
    spec:
     config: '{
       "cniVersion": "0.4.0",
       "name": "tap",
       "plugins": [
         {
            "type": "tap",
            "multiQueue": true,
            "selinuxcontext": "system_u:system_r:container_t:s0"
         },
         {
           "type":"tuning",
           "capabilities":{
             "mac":true
           }
         }
       ]
     }'
    Copy to Clipboard Toggle word wrap
    1
    SriovNetwork 개체가 생성된 것과 동일한 target_namespace를 지정합니다.
  8. 다음 명령을 실행하여 NetworkAttachmentDefinition 객체를 만듭니다.

    $ oc apply -f tap-example.yaml
    Copy to Clipboard Toggle word wrap
  9. 다음 예시와 같은 내용을 포함하는 dpdk-pod-rootless.yaml 과 같은 파일을 만듭니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dpdk-app
      namespace: test-namespace 
    1
    
      annotations:
        k8s.v1.cni.cncf.io/networks: '[
          {"name": "sriov-network", "namespace": "test-namespace"},
          {"name": "tap-one", "interface": "ext0", "namespace": "test-namespace"}]'
    spec:
      nodeSelector:
        kubernetes.io/hostname: "worker-0"
      securityContext:
          fsGroup: 1001 
    2
    
          runAsGroup: 1001 
    3
    
          seccompProfile:
            type: RuntimeDefault
      containers:
      - name: testpmd
        image: <DPDK_image> 
    4
    
        securityContext:
          capabilities:
            drop: ["ALL"] 
    5
    
            add: 
    6
    
              - IPC_LOCK
              - NET_RAW #for mlx only 
    7
    
          runAsUser: 1001 
    8
    
          privileged: false 
    9
    
          allowPrivilegeEscalation: true 
    10
    
          runAsNonRoot: true 
    11
    
        volumeMounts:
        - mountPath: /mnt/huge 
    12
    
          name: hugepages
        resources:
          limits:
            openshift.io/sriovnic: "1" 
    13
    
            memory: "1Gi"
            cpu: "4" 
    14
    
            hugepages-1Gi: "4Gi" 
    15
    
          requests:
            openshift.io/sriovnic: "1"
            memory: "1Gi"
            cpu: "4"
            hugepages-1Gi: "4Gi"
        command: ["sleep", "infinity"]
      runtimeClassName: performance-cnf-performanceprofile 
    16
    
      volumes:
      - name: hugepages
        emptyDir:
          medium: HugePages
    Copy to Clipboard Toggle word wrap
    1
    SriovNetwork 개체가 생성된 것과 동일한 target_namespace를 지정합니다. 다른 네임스페이스에 Pod를 만들려면 Pod 사양과 SriovNetwork 개체 모두에서 target_namespace를 변경합니다.
    2
    볼륨에 마운트된 디렉토리와 해당 볼륨에 생성된 파일의 그룹 소유권을 설정합니다.
    3
    컨테이너를 실행하는 데 사용되는 기본 그룹 ID를 지정합니다.
    4
    애플리케이션이 포함된 DPDK 이미지와 애플리케이션에서 사용하는 DPDK 라이브러리를 지정합니다.
    5
    컨테이너의 securityContext에서 모든 기능( ALL )을 제거한다는 것은 컨테이너가 일반 작업에 필요한 것 이상의 특별한 권한을 갖지 않는다는 것을 의미합니다.
    6
    hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다. 이러한 기능도 setcap 명령을 사용하여 바이너리 파일에 설정해야 합니다.
    7
    Mellanox 네트워크 인터페이스 컨트롤러(NIC)에는 NET_RAW 기능이 필요합니다.
    8
    컨테이너를 실행하는 데 사용되는 사용자 ID를 지정합니다.
    9
    이 설정은 포드 내의 컨테이너에 호스트 시스템에 대한 특권 액세스 권한이 부여되지 않아야 함을 나타냅니다.
    10
    이 설정을 사용하면 컨테이너가 처음에 할당받은 루트가 아닌 권한보다 더 높은 권한으로 권한을 확대할 수 있습니다.
    11
    이 설정은 컨테이너가 루트가 아닌 사용자로 실행되도록 보장합니다. 이를 통해 최소 권한의 원칙을 강화하고 컨테이너가 손상될 수 있는 잠재적 영향을 제한하며 공격 표면을 줄이는 데 도움이 됩니다.
    12
    DPDK 포드의 /mnt/huge 아래에 hugepage 볼륨을 마운트합니다. hugepage 볼륨은 매체가 Hugepages인 emptyDir 볼륨 유형으로 지원됩니다.
    13
    선택 사항: DPDK 포드에 할당된 DPDK 장치 수를 지정합니다. 명시적으로 지정하지 않으면 이 리소스 요청 및 제한은 SR-IOV 네트워크 리소스 인젝터에 의해 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본 SriovOperatorConfig CR에서 enableInjector 옵션을 false로 설정하여 비활성화할 수 있습니다.
    14
    CPU 수를 지정합니다. DPDK pod는 일반적으로 kubelet에서 배타적 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을 static으로 설정하고 QoS가 보장된 Pod를 생성합니다.
    15
    hugepage 크기 hugepages-1Gi 또는 hugepages-2Mi를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다. 2Mi1Gi hugepage를 별도로 구성합니다. 1Gi hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다. 예를 들어, 커널 인수 default_hugepagesz = 1GB, hugepagesz = 1Ghugepages = 16을 추가하면 시스템 부팅 시 16 * 1Gi hugepage가 할당됩니다.
    16
    성능 프로필 이름이 cnf-performance profile 이 아닌 경우 해당 문자열을 올바른 성능 프로필 이름으로 바꾸세요.
  10. 다음 명령을 실행하여 DPDK Pod를 생성합니다.

    $ oc create -f dpdk-pod-rootless.yaml
    Copy to Clipboard Toggle word wrap

9.5. 특정 DPDK 라인 속도 달성 개요

특정 데이터 플레인 개발 키트(DPDK) 라인 속도를 달성하려면 노드 튜닝 운영자를 배포하고 SR-IOV(단일 루트 I/O 가상화)를 구성합니다. 다음 리소스에 대한 DPDK 설정도 조정해야 합니다.

  • 격리된 CPU
  • 거대한 페이지
  • 토폴로지 스케줄러
참고

이전 버전의 OpenShift Container Platform에서는 Performance Addon Operator를 사용하여 OpenShift Container Platform 애플리케이션의 저지연 성능을 달성하기 위한 자동 튜닝을 구현했습니다. OpenShift Container Platform 4.11 이상에서는 이 기능이 Node Tuning Operator의 일부입니다.

DPDK 테스트 환경

다음 다이어그램은 트래픽 테스트 환경의 구성 요소를 보여줍니다.

  • 트래픽 생성기 : 대량의 패킷 트래픽을 생성할 수 있는 애플리케이션입니다.
  • SR-IOV 지원 NIC : SR-IOV와 호환되는 네트워크 인터페이스 카드입니다. 이 카드는 물리적 인터페이스에서 여러 가지 가상 기능을 실행합니다.
  • 물리적 기능(PF) : SR-IOV 인터페이스를 지원하는 네트워크 어댑터의 PCI Express(PCIe) 기능입니다.
  • 가상 기능(VF) : SR-IOV를 지원하는 네트워크 어댑터의 가벼운 PCIe 기능입니다. VF는 네트워크 어댑터의 PCIe PF와 연결됩니다. VF는 네트워크 어댑터의 가상화된 인스턴스를 나타냅니다.
  • 스위치 : 네트워크 스위치. 노드는 연속적으로 연결될 수도 있습니다.
  • testpmd : DPDK에 포함된 예제 애플리케이션입니다. testpmd 애플리케이션을 사용하면 패킷 전달 모드에서 DPDK를 테스트할 수 있습니다. testpmd 애플리케이션은 DPDK 소프트웨어 개발 키트(SDK)를 사용하여 본격적인 애플리케이션을 빌드하는 방법의 예이기도 합니다.
  • 작업자 0작업자 1 : OpenShift 컨테이너 플랫폼 노드.

9.6. SR-IOV 및 노드 튜닝 연산자를 사용하여 DPDK 라인 속도 달성

노드 튜닝 연산자를 사용하면 격리된 CPU, 거대 페이지 및 토폴로지 스케줄러를 구성할 수 있습니다. 그런 다음 SR-IOV(Single Root I/O Virtualization)와 함께 노드 튜닝 연산자를 사용하여 특정 DPDK(Data Plane Development Kit) 라인 속도를 달성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • SR-IOV Network Operator가 설치되어 있습니다.
  • 클러스터 관리자 권한이 있는 사용자로 로그인했습니다.
  • 독립형 노드 튜닝 운영자를 배포했습니다.

    참고

    이전 버전의 OpenShift Container Platform에서는 Performance Addon Operator를 사용하여 OpenShift 애플리케이션의 저지연 성능을 달성하기 위한 자동 튜닝을 구현했습니다. OpenShift Container Platform 4.11 이상에서는 이 기능이 Node Tuning Operator의 일부입니다.

프로세스

  1. 다음 예제를 기반으로 PerformanceProfile 객체를 만듭니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: performance
    spec:
      globallyDisableIrqLoadBalancing: true
      cpu:
        isolated: 21-51,73-103 
    1
    
        reserved: 0-20,52-72 
    2
    
      hugepages:
        defaultHugepagesSize: 1G 
    3
    
        pages:
          - count: 32
            size: 1G
      net:
        userLevelNetworking: true
      numa:
        topologyPolicy: "single-numa-node"
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
    Copy to Clipboard Toggle word wrap
    1
    시스템에서 하이퍼스레딩이 활성화된 경우, 격리 되고 예약된 CPU 그룹에 관련 심볼릭 링크를 할당합니다. 시스템에 여러 개의 비균일 메모리 액세스 노드(NUMA)가 포함되어 있는 경우 두 NUMA의 CPU를 두 그룹에 할당합니다. 이 작업에는 성과 프로필 생성기를 사용할 수도 있습니다. 자세한 내용은 성과 프로필 만들기를 참조하세요.
    2
    또한, 예약된 CPU 수에 맞춰 대기열이 설정될 장치 목록을 지정할 수도 있습니다. 자세한 내용은 노드 튜닝 연산자를 사용하여 NIC 대기열 줄이기를 참조하세요.
    3
    필요한 거대페이지의 수와 크기를 할당합니다. 거대한 페이지에 대한 NUMA 구성을 지정할 수 있습니다. 기본적으로 시스템은 시스템의 모든 NUMA 노드에 짝수를 할당합니다. 필요한 경우 노드에 대한 실시간 커널 사용을 요청할 수 있습니다. 자세한 내용은 실시간 기능을 갖춘 근로자 프로비저닝을 참조하세요.
  2. yaml 파일을 mlx-dpdk-perfprofile-policy.yaml 로 저장합니다.
  3. 다음 명령을 사용하여 성능 프로필을 적용합니다.

    $ oc create -f mlx-dpdk-perfprofile-policy.yaml
    Copy to Clipboard Toggle word wrap

9.6.1. 컨테이너 애플리케이션에서 사용하는 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 워크로드에 데이터를 전달할 수 있습니다.

9.6.2. 가상 함수를 위한 SR-IOV 네트워크 운영자 예시

SR-IOV(단일 루트 I/O 가상화) 네트워크 운영자를 사용하여 노드의 SR-IOV 지원 물리적 기능 NIC에서 가상 기능(VF)을 할당하고 구성할 수 있습니다.

Operator 배포에 대한 자세한 내용은 SR-IOV 네트워크 Operator 설치를 참조하세요. SR-IOV 네트워크 장치 구성에 대한 자세한 내용은 SR-IOV 네트워크 장치 구성을 참조하세요.

Intel VF와 Mellanox VF에서 DPDK(Data Plane Development Kit) 워크로드를 실행하는 데에는 몇 가지 차이점이 있습니다. 이 섹션에서는 두 가지 VF 유형에 대한 개체 구성 예를 제공합니다. 다음은 Intel NIC에서 DPDK 애플리케이션을 실행하는 데 사용되는 sriovNetworkNodePolicy 개체의 예입니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci 
1

  needVhostNet: true 
2

  nicSelector:
    pfNames: ["ens3f0"]
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci
  needVhostNet: true
  nicSelector:
    pfNames: ["ens3f1"]
  nodeSelector:
  node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_2
Copy to Clipboard Toggle word wrap
1
Intel NIC의 경우 deviceType은 vfio-pci 여야 합니다.
2
DPDK 워크로드와 커널 통신이 필요한 경우 needVhostNet: true를 추가합니다. 이렇게 하면 /dev/net/tun/dev/vhost-net 장치가 컨테이너에 마운트되어 애플리케이션이 탭 장치를 생성하고 해당 탭 장치를 DPDK 워크로드에 연결할 수 있습니다.

다음은 Mellanox NIC에 대한 sriovNetworkNodePolicy 개체의 예입니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice 
1

  isRdma: true 
2

  nicSelector:
    rootDevices:
      - "0000:5e:00.1"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-2
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  nicSelector:
    rootDevices:
      - "0000:5e:00.0"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_2
Copy to Clipboard Toggle word wrap
1
Mellanox 장치의 경우 deviceTypenetdevice 여야 합니다.
2
Mellanox 장치의 경우 isRdma는 true 여야 합니다. Mellanox 카드는 Flow Bifurcation을 사용하여 DPDK 애플리케이션에 연결됩니다. 이 메커니즘은 Linux 사용자 공간과 커널 공간 간의 트래픽을 분할하고 라인 속도 처리 기능을 향상시킬 수 있습니다.

9.6.3. SR-IOV 네트워크 운영자 예시

다음은 sriovNetwork 객체의 정의 예입니다. 이 경우 Intel과 Mellanox 구성은 동일합니다.

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-1
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.1.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}' 
1

  networkNamespace: dpdk-test 
2

  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_1 
3

---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-2
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.2.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}'
  networkNamespace: dpdk-test
  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_2
Copy to Clipboard Toggle word wrap
1
Whereabouts와 같은 다른 IP 주소 관리(IPAM) 구현을 사용할 수 있습니다. 자세한 내용은 Whereabouts를 사용한 동적 IP 주소 할당 구성을 참조하세요.
2
네트워크 연결 정의가 생성될 networkNamespace 를 요청해야 합니다. openshift-sriov-network-operator 네임스페이스 아래에 sriovNetwork CR을 만들어야 합니다.
3
resourceName 값은 sriovNetworkNodePolicy 에서 생성된 resourceName 값과 일치해야 합니다.

9.6.4. DPDK 기반 워크로드 예시

다음은 DPDK(Data Plane Development Kit) 컨테이너의 예입니다.

apiVersion: v1
kind: Namespace
metadata:
  name: dpdk-test
---
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[ 
1

     {
      "name": "dpdk-network-1",
      "namespace": "dpdk-test"
     },
     {
      "name": "dpdk-network-2",
      "namespace": "dpdk-test"
     }
   ]'
    irq-load-balancing.crio.io: "disable" 
2

    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
  labels:
    app: dpdk
  name: testpmd
  namespace: dpdk-test
spec:
  runtimeClassName: performance-performance 
3

  containers:
    - command:
        - /bin/bash
        - -c
        - sleep INF
      image: registry.redhat.io/openshift4/dpdk-base-rhel8
      imagePullPolicy: Always
      name: dpdk
      resources: 
4

        limits:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
        requests:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
      securityContext:
        capabilities:
          add:
            - IPC_LOCK
            - SYS_RESOURCE
            - NET_RAW
            - NET_ADMIN
        runAsUser: 0
      volumeMounts:
        - mountPath: /mnt/huge
          name: hugepages
  terminationGracePeriodSeconds: 5
  volumes:
    - emptyDir:
        medium: HugePages
      name: hugepages
Copy to Clipboard Toggle word wrap
1
필요한 SR-IOV 네트워크를 요청하세요. 장치에 대한 리소스는 자동으로 주입됩니다.
2
CPU 및 IRQ 부하 분산 기반을 비활성화합니다. 자세한 내용은 개별 포드에 대한 인터럽트 처리 비활성화를 참조하세요.
3
runtimeClass를 performance-performance 로 설정합니다. runtimeClass를 HostNetwork 또는 privileged 로 설정하지 마세요.
4
보장된 서비스 품질(QoS)로 포드를 시작하려면 요청과 제한에 대해 동일한 수의 리소스를 요청합니다.
참고

SLEEP 으로 Pod를 시작한 다음 Pod에 exec를 실행하여 testpmd 또는 DPDK 워크로드를 시작하지 마세요. exec 프로세스가 어떤 CPU에도 고정되지 않으므로 추가적인 인터럽트가 발생할 수 있습니다.

9.6.5. testpmd 스크립트 예시

다음은 testpmd를 실행하기 위한 스크립트 예입니다.

#!/bin/bash
set -ex
export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus)
echo ${CPU}

dpdk-testpmd -l ${CPU} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_1} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_2} -n 4 -- -i --nb-cores=15 --rxd=4096 --txd=4096 --rxq=7 --txq=7 --forward-mode=mac --eth-peer=0,50:00:00:00:00:01 --eth-peer=1,50:00:00:00:00:02
Copy to Clipboard Toggle word wrap

이 예제에서는 두 개의 서로 다른 sriovNetwork CR을 사용합니다. 환경 변수에는 포드에 할당된 가상 함수(VF) PCI 주소가 포함되어 있습니다. Pod 정의에서 동일한 네트워크를 사용하는 경우 pciAddress를 분할해야 합니다. 트래픽 생성기의 올바른 MAC 주소를 구성하는 것이 중요합니다. 이 예제에서는 사용자 지정 MAC 주소를 사용합니다.

9.7. Mellanox NIC와 함께 RDMA 모드에서 가상 기능 사용

중요

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

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

OpenShift Container Platform에서 RDMA를 사용할 때 RoCE(RDMA over Converged Ethernet)가 지원되는 유일한 모드입니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • SR-IOV Network Operator 설치.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 다음 SriovNetworkNodePolicy 오브젝트를 생성한 다음 YAML을 mlx-rdma-node-policy.yaml 파일에 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: mlx-rdma-node-policy
      namespace: openshift-sriov-network-operator
    spec:
      resourceName: mlxnics
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true"
      priority: <priority>
      numVfs: <num>
      nicSelector:
        vendor: "15b3"
        deviceID: "1015" 
    1
    
        pfNames: ["<pf_name>", ...]
        rootDevices: ["<pci_bus_id>", "..."]
      deviceType: netdevice 
    2
    
      isRdma: true 
    3
    Copy to Clipboard Toggle word wrap
    1
    SR-IOV 네트워크 장치의 장치 16진수 코드를 지정합니다.
    2
    netdevice에 가상 기능의 드라이버 유형을 지정합니다.
    3
    RDMA 모드를 활성화합니다.
    참고

    SriovNetworkNodePolicy의 각 옵션에 대한 자세한 설명은 Configuring SR-IOV network devices 섹션을 참조하십시오.

    SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.

    구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.

  2. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f mlx-rdma-node-policy.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 SriovNetwork 오브젝트를 생성한 다음 YAML을 mlx-rdma-network.yaml 파일에 저장합니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: mlx-rdma-network
      namespace: openshift-sriov-network-operator
    spec:
      networkNamespace: <target_namespace>
      ipam: |- 
    1
    
    # ...
      vlan: <vlan>
      resourceName: mlxnics
    Copy to Clipboard Toggle word wrap
    1
    ipam CNI 플러그인에 대한 구성 객체를 YAML 블록 스칼라로 지정합니다. 이 플러그인은 첨부 파일 정의에 대한 IP 주소 할당을 관리합니다.
    참고

    SriovNetwork의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.

    선택적 라이브러리인 app-netutil은 컨테이너의 상위 pod에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.

  4. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

    $ oc create -f mlx-rdma-network.yaml
    Copy to Clipboard Toggle word wrap
  5. 다음 Pod 사양을 생성한 다음 YAML을 mlx-rdma-pod.yaml 파일에 저장합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: rdma-app
      namespace: <target_namespace> 
    1
    
      annotations:
        k8s.v1.cni.cncf.io/networks: mlx-rdma-network
    spec:
      containers:
      - name: testpmd
        image: <RDMA_image> 
    2
    
        securityContext:
          runAsUser: 0
          capabilities:
            add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    3
    
        volumeMounts:
        - mountPath: /mnt/huge 
    4
    
          name: hugepage
        resources:
          limits:
            memory: "1Gi"
            cpu: "4" 
    5
    
            hugepages-1Gi: "4Gi" 
    6
    
          requests:
            memory: "1Gi"
            cpu: "4"
            hugepages-1Gi: "4Gi"
        command: ["sleep", "infinity"]
      volumes:
      - name: hugepage
        emptyDir:
          medium: HugePages
    Copy to Clipboard Toggle word wrap
    1
    SriovNetwork 오브젝트 mlx-rdma-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에 Pod를 만들려면 Pod 사양과 SriovNetwork 개체 모두에서 target_namespace를 변경하세요.
    2
    애플리케이션 및 애플리케이션에서 사용하는 RDMA 라이브러리를 포함하는 RDMA 이미지를 지정합니다.
    3
    hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
    4
    /mnt/huge 아래의 RDMA 포드에 hugepage 볼륨을 마운트합니다. hugepage 볼륨은 매체가 Hugepages인 emptyDir 볼륨 유형으로 지원됩니다.
    5
    CPU 수를 지정합니다. RDMA Pod는 일반적으로 kubelet에서 전용 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을 static으로 설정하고 QoS가 Guaranteed Pod를 생성합니다.
    6
    hugepage 크기 hugepages-1Gi 또는 hugepages-2Mi를 지정하고 RDMA Pod에 할당할 hugepage 수량을 지정합니다. 2Mi1Gi hugepage를 별도로 구성합니다. 1Gi hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다.
  6. 다음 명령을 실행하여 RDMA Pod를 생성합니다.

    $ oc create -f mlx-rdma-pod.yaml
    Copy to Clipboard Toggle word wrap

다음 testpmd 포드는 대규모 페이지, 예약된 CPU 및 SR-IOV 포트를 사용하여 컨테이너를 생성하는 방법을 보여줍니다.

testpmd pod의 예

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-dpdk
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/dpdk1: 1 
1

      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/dpdk1: 1
    volumeMounts:
      - mountPath: /mnt/huge
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile 
2

  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
Copy to Clipboard Toggle word wrap

1
이 예에서 dpdk1 이라는 이름은 사용자가 생성한 SriovNetworkNodePolicy 리소스입니다. 이 이름을 사용자가 만든 리소스의 이름으로 대체할 수 있습니다.
2
성능 프로필 이름이 cnf-performance profile 이 아닌 경우 해당 문자열을 올바른 성능 프로필 이름으로 바꾸세요.

10장. 포드 레벨 본딩 사용

Pod 수준의 본딩은 고가용성과 처리량이 필요한 Pod 내부의 워크로드를 활성화하는 데 중요합니다. 포드 수준 본딩을 사용하면 커널 모드 인터페이스에서 여러 개의 단일 루트 I/O 가상화(SR-IOV) 가상 함수 인터페이스에서 본드 인터페이스를 생성할 수 있습니다. SR-IOV 가상 기능은 Pod에 전달되고 커널 드라이버에 연결됩니다.

포드 수준 본딩이 필요한 한 가지 시나리오는 서로 다른 물리적 기능의 여러 SR-IOV 가상 기능에서 본딩 인터페이스를 만드는 것입니다. 호스트에서 서로 다른 두 개의 물리적 기능으로부터 본드 인터페이스를 생성하면 포드 수준에서 높은 가용성과 처리량을 달성할 수 있습니다.

다음 문서의 작업을 수행하기 전에 SR-IOV 네트워크 운영자가 설치되어 있는지 확인하세요.

SR-IOV 네트워크, 네트워크 정책, 네트워크 연결 정의 및 Pod 생성과 같은 작업에 대한 지침은 SR-IOV 네트워크 장치 구성을 참조하세요.

10.1. 두 개의 SR-IOV 인터페이스에서 본드 인터페이스 구성

본딩을 사용하면 여러 네트워크 인터페이스를 하나의 논리적인 "본딩된" 인터페이스로 집계할 수 있습니다. Bond Container Network Interface(Bond-CNI)는 컨테이너에 Bond 기능을 제공합니다.

Bond-CNI는 SR-IOV(Single Root I/O Virtualization) 가상 함수를 사용하여 생성하고 이를 컨테이너 네트워크 네임스페이스에 배치할 수 있습니다.

OpenShift Container Platform은 SR-IOV 가상 함수를 사용하는 Bond-CNI만 지원합니다. SR-IOV 네트워크 운영자는 가상 기능을 관리하는 데 필요한 SR-IOV CNI 플러그인을 제공합니다. 다른 CNI 또는 인터페이스 유형은 지원되지 않습니다.

사전 요구 사항

  • 컨테이너에서 가상 기능을 얻으려면 SR-IOV 네트워크 운영자를 설치하고 구성해야 합니다.
  • SR-IOV 인터페이스를 구성하려면 각 인터페이스에 대한 SR-IOV 네트워크와 정책을 만들어야 합니다.
  • SR-IOV 네트워크 운영자는 SR-IOV 네트워크 및 정의된 정책을 기반으로 각 SR-IOV 인터페이스에 대한 네트워크 연결 정의를 만듭니다.
  • SR-IOV 가상 함수의 경우 linkState가 기본값인 auto 로 설정됩니다.

10.1.1. 본드 네트워크 첨부 정의 생성

이제 SR-IOV 가상 함수를 사용할 수 있으므로 본드 네트워크 연결 정의를 만들 수 있습니다.

apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: bond-net1
      namespace: demo
    spec:
      config: '{
      "type": "bond", 
1

      "cniVersion": "0.3.1",
      "name": "bond-net1",
      "mode": "active-backup", 
2

      "failOverMac": 1, 
3

      "linksInContainer": true, 
4

      "miimon": "100",
      "mtu": 1500,
      "links": [ 
5

            {"name": "net1"},
            {"name": "net2"}
        ],
      "ipam": {
            "type": "host-local",
            "subnet": "10.56.217.0/24",
            "routes": [{
            "dst": "0.0.0.0/0"
            }],
            "gateway": "10.56.217.1"
        }
      }'
Copy to Clipboard Toggle word wrap
1
cni-type은 항상 bond 로 설정됩니다.
2
모드 속성은 본딩 모드를 지정합니다.
참고

지원되는 본딩 모드는 다음과 같습니다.

  • 균형-rr - 0
  • 활성 백업 - 1
  • 밸런스-xor -2

balance-rr 또는 balance-xor 모드의 경우 SR-IOV 가상 함수에 대한 신뢰 모드를 켜짐 으로 설정해야 합니다.

3
장애 조치(failover) 속성은 액티브 백업 모드에 필수이며 1로 설정해야 합니다.
4
linksInContainer=true 플래그는 필요한 인터페이스가 컨테이너 내부에서 발견된다는 것을 Bond CNI에 알립니다. 기본적으로 Bond CNI는 SRIOV 및 Multus와의 통합에 적합하지 않은 호스트에서 이러한 인터페이스를 찾습니다.
5
링크 섹션은 본드를 생성하는 데 사용될 인터페이스를 정의합니다. 기본적으로 Multus는 연결된 인터페이스의 이름을 "net"과 1부터 시작하는 연속된 숫자로 지정합니다.

10.1.2. 본드 인터페이스를 사용하여 포드 생성

  1. 예를 들어 podbonding.yaml 이라는 이름의 YAML 파일로 포드를 만들어 설정을 테스트합니다. 파일의 내용은 다음과 같습니다.

    apiVersion: v1
        kind: Pod
        metadata:
          name: bondpod1
          namespace: demo
          annotations:
            k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1 
    1
    
        spec:
          containers:
          - name: podexample
            image: quay.io/openshift/origin-network-interface-bond-cni:4.11.0
            command: ["/bin/bash", "-c", "sleep INF"]
    Copy to Clipboard Toggle word wrap
    1
    네트워크 주석에 주목하세요. 여기에는 SR-IOV 네트워크 연결 2개와 본드 네트워크 연결 1개가 포함되어 있습니다. 본드 부착은 두 개의 SR-IOV 인터페이스를 본드 포트 인터페이스로 사용합니다.
  2. 다음 명령을 실행하여 yaml을 적용합니다.

    $ oc apply -f podbonding.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 사용하여 Pod 인터페이스를 검사하세요.

    $ oc rsh -n demo bondpod1
    sh-4.4#
    sh-4.4# ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    valid_lft forever preferred_lft forever
    3: eth0@if150: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP
    link/ether 62:b1:b5:c8:fb:7a brd ff:ff:ff:ff:ff:ff
    inet 10.244.1.122/24 brd 10.244.1.255 scope global eth0
    valid_lft forever preferred_lft forever
    4: net3: <BROADCAST,MULTICAST,UP,LOWER_UP400> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff 
    1
    
    inet 10.56.217.66/24 scope global bond0
    valid_lft forever preferred_lft forever
    43: net1: <BROADCAST,MULTICAST,UP,LOWER_UP800> mtu 1500 qdisc mq master bond0 state UP qlen 1000
    link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff 
    2
    
    44: net2: <BROADCAST,MULTICAST,UP,LOWER_UP800> mtu 1500 qdisc mq master bond0 state UP qlen 1000
    link/ether 9e:23:69:42:fb:8a brd ff:ff:ff:ff:ff:ff 
    3
    Copy to Clipboard Toggle word wrap
    1
    본드 인터페이스는 자동으로 net3 으로 명명됩니다. 특정 인터페이스 이름을 설정하려면 포드의 k8s.v1.cni.cncf.io/networks 주석에 @name 접미사를 추가합니다.
    2
    net1 인터페이스는 SR-IOV 가상 함수를 기반으로 합니다.
    3
    net2 인터페이스는 SR-IOV 가상 함수를 기반으로 합니다.
    참고

    Pod 주석에 인터페이스 이름이 구성되지 않은 경우 인터페이스 이름은 자동으로 net<n> 으로 지정되며 <n>1 부터 시작합니다.

  4. 선택 사항: 예를 들어 bond0 과 같은 특정 인터페이스 이름을 설정하려면 k8s.v1.cni.cncf.io/networks 주석을 편집하고 다음과 같이 bond0을 인터페이스 이름으로 설정합니다.

    annotations:
            k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1@bond0
    Copy to Clipboard Toggle word wrap

11장. 하드웨어 오프로드 구성

클러스터 관리자는 호환 노드에서 하드웨어 오프로드를 구성하여 데이터 처리 성능을 높이고 호스트 CPU의 부하를 줄일 수 있습니다.

다음 문서의 작업을 수행하기 전에 SR-IOV 네트워크 운영자가 설치되어 있는지 확인하세요.

11.1. 하드웨어 오프로딩에 관하여

Open vSwitch 하드웨어 오프로드는 네트워크 작업을 CPU에서 다른 곳으로 옮겨 네트워크 인터페이스 컨트롤러의 전용 프로세서로 오프로드하여 처리하는 방법입니다. 결과적으로 클러스터는 더 빠른 데이터 전송 속도, 감소된 CPU 작업 부하, 낮은 컴퓨팅 비용의 이점을 얻을 수 있습니다.

이 기능의 핵심 요소는 SmartNIC라고 하는 최신 네트워크 인터페이스 컨트롤러입니다. SmartNIC은 계산량이 많은 네트워크 처리 작업을 처리할 수 있는 네트워크 인터페이스 컨트롤러입니다. 전용 그래픽 카드가 그래픽 성능을 향상시킬 수 있는 것과 마찬가지로 SmartNIC는 네트워크 성능을 향상시킬 수 있습니다. 각각의 경우, 전용 프로세서는 특정 유형의 처리 작업에 대한 성능을 향상시킵니다.

OpenShift Container Platform에서는 호환되는 SmartNIC이 있는 베어 메탈 노드에 대해 하드웨어 오프로드를 구성할 수 있습니다. 하드웨어 오프로드는 SR-IOV 네트워크 운영자에 의해 구성되고 활성화됩니다.

하드웨어 오프로드는 모든 작업 부하나 애플리케이션 유형과 호환되지 않습니다. 다음 두 가지 통신 유형만 지원됩니다.

  • 포드 투 포드
  • Pod-to-service, 서비스가 일반 Pod에 의해 지원되는 ClusterIP 서비스인 경우

모든 경우에 하드웨어 오프로드는 해당 포드와 서비스가 호환되는 SmartNIC이 있는 노드에 할당된 경우에만 발생합니다. 예를 들어, 하드웨어 오프로드가 있는 노드의 포드가 일반 노드의 서비스와 통신을 시도한다고 가정해 보겠습니다. 일반 노드에서는 모든 처리가 커널에서 이루어지므로, 포드-서비스 통신의 전반적인 성능은 해당 일반 노드의 최대 성능으로 제한됩니다. 하드웨어 오프로딩은 DPDK 애플리케이션과 호환되지 않습니다.

노드에서 하드웨어 오프로드를 활성화했지만 사용할 Pod를 구성하지 않으면 Pod 트래픽의 처리량 성능이 저하될 수 있습니다. OpenShift Container Platform에서 관리하는 Pod에 대해서는 하드웨어 오프로드를 구성할 수 없습니다.

11.2. 지원되는 장치

다음 네트워크 인터페이스 컨트롤러에서 하드웨어 오프로드가 지원됩니다.

Expand
표 11.1. 지원되는 네트워크 인터페이스 컨트롤러
제조업체모델벤더 ID장치 ID

Mellanox

MT27800 제품군 [ConnectX-5]

15b3

1017

Mellanox

MT28880 제품군 [ConnectX-5 Ex]

15b3

1019

Mellanox

MT2892 제품군 [ConnectX‑6 Dx]

15b3

101d

Mellanox

MT2894 제품군 [ConnectX-6 Lx]

15b3

101f

Mellanox

ConnectX-6 NIC 모드의 MT42822 BlueField-2

15b3

a2d6

11.3. 사전 요구 사항

11.4. SR-IOV 네트워크 운영자를 systemd 모드로 설정

하드웨어 오프로드를 지원하려면 먼저 SR-IOV 네트워크 운영자를 systemd 모드로 설정해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자 역할이 있는 사용자로 클러스터에 액세스할 수 있습니다.

프로세스

  1. 모든 SR-IOV Operator 구성 요소를 배포하기 위해 SriovOperatorConfig 사용자 지정 리소스(CR)를 만듭니다.

    1. 다음 YAML을 포함하는 sriovOperatorConfig.yaml 이라는 파일을 만듭니다.

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovOperatorConfig
      metadata:
        name: default 
      1
      
        namespace: openshift-sriov-network-operator
      spec:
        enableInjector: true
        enableOperatorWebhook: true
        configurationMode: "systemd" 
      2
      
        logLevel: 2
      Copy to Clipboard Toggle word wrap
      1
      SriovOperatorConfig 리소스에 유효한 이름은 기본값 뿐이며 Operator가 배포된 네임스페이스에 있어야 합니다.
      2
      SR-IOV 네트워크 운영자를 systemd 모드로 설정하는 것은 Open vSwitch 하드웨어 오프로드에만 해당됩니다.
    2. 다음 명령을 실행하여 리소스를 생성합니다.

      $ oc apply -f sriovOperatorConfig.yaml
      Copy to Clipboard Toggle word wrap

11.5. 하드웨어 오프로드를 위한 머신 구성 풀 구성

하드웨어 오프로드를 활성화하려면 이제 전용 머신 구성 풀을 만들고 SR-IOV 네트워크 운영자와 함께 작동하도록 구성해야 합니다.

사전 요구 사항

  1. SR-IOV 네트워크 운영자가 설치되고 systemd 모드로 설정되었습니다.

프로세스

  1. 하드웨어 오프로드를 사용하려는 머신에 대한 머신 구성 풀을 만듭니다.

    1. 다음 예시와 같은 내용을 포함하는 mcp-offloading.yaml 과 같은 파일을 만듭니다.

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: mcp-offloading 
      1
      
      spec:
        machineConfigSelector:
          matchExpressions:
            - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,mcp-offloading]} 
      2
      
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/mcp-offloading: "" 
      3
      Copy to Clipboard Toggle word wrap
      1 2
      하드웨어 오프로드를 위한 머신 구성 풀의 이름입니다.
      3
      이 노드 역할 레이블은 머신 구성 풀에 노드를 추가하는 데 사용됩니다.
    2. 머신 구성 풀에 대한 구성을 적용합니다.

      $ oc create -f mcp-offloading.yaml
      Copy to Clipboard Toggle word wrap
  2. 머신 구성 풀에 노드를 추가합니다. 각 노드에 풀의 노드 역할 레이블을 지정합니다.

    $ oc label node worker-2 node-role.kubernetes.io/mcp-offloading=""
    Copy to Clipboard Toggle word wrap
  3. 선택 사항: 새 풀이 생성되었는지 확인하려면 다음 명령을 실행하세요.

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME       STATUS   ROLES                   AGE   VERSION
    master-0   Ready    master                  2d    v1.32.3
    master-1   Ready    master                  2d    v1.32.3
    worker-0   Ready    worker                  2d    v1.32.3
    worker-1   Ready    worker                  2d    v1.32.3
    worker-2   Ready    mcp-offloading,worker   47h   v1.32.3
    Copy to Clipboard Toggle word wrap

  4. SriovNetworkPoolConfig 사용자 정의 리소스에 이 머신 구성 풀을 추가합니다.

    1. 다음 예시와 같은 내용을 포함하는 sriov-pool-config.yaml 과 같은 파일을 만듭니다.

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetworkPoolConfig
      metadata:
        name: sriovnetworkpoolconfig-offload
        namespace: openshift-sriov-network-operator
      spec:
        ovsHardwareOffloadConfig:
          name: mcp-offloading 
      1
      Copy to Clipboard Toggle word wrap
      1
      하드웨어 오프로드를 위한 머신 구성 풀의 이름입니다.
    2. 설정을 적용합니다.

      $ oc create -f <SriovNetworkPoolConfig_name>.yaml
      Copy to Clipboard Toggle word wrap
      참고

      SriovNetworkPoolConfig 개체에 지정된 구성을 적용하면 SR-IOV 운영자가 머신 구성 풀의 노드를 비우고 다시 시작합니다.

      구성 변경 사항이 적용되려면 몇 분이 걸릴 수 있습니다.

11.6. SR-IOV 네트워크 노드 정책 구성

SR-IOV 네트워크 노드 정책을 생성하여 노드에 대한 SR-IOV 네트워크 장치 구성을 생성할 수 있습니다. 하드웨어 오프로딩을 활성화하려면 .spec.eSwitchMode 필드를 "switchdev" 값으로 정의해야 합니다.

다음 절차에서는 하드웨어 오프로드를 통해 네트워크 인터페이스 컨트롤러에 대한 SR-IOV 인터페이스를 생성합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 다음 예시와 같은 내용을 포함하는 sriov-node-policy.yaml 과 같은 파일을 만듭니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: sriov-node-policy 
    1
    
      namespace: openshift-sriov-network-operator
    spec:
      deviceType: netdevice 
    2
    
      eSwitchMode: "switchdev" 
    3
    
      nicSelector:
        deviceID: "1019"
        rootDevices:
        - 0000:d8:00.0
        vendor: "15b3"
        pfNames:
        - ens8f0
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: "true"
      numVfs: 6
      priority: 5
      resourceName: mlxnics
    Copy to Clipboard Toggle word wrap
    1
    사용자 정의 리소스 오브젝트의 이름입니다.
    2
    필수 항목입니다. vfio-pci 에서는 하드웨어 오프로드가 지원되지 않습니다.
    3
    필수 항목입니다.
  2. 정책에 대한 구성을 적용합니다.

    $ oc create -f sriov-node-policy.yaml
    Copy to Clipboard Toggle word wrap
    참고

    SriovNetworkPoolConfig 개체에 지정된 구성을 적용하면 SR-IOV 운영자가 머신 구성 풀의 노드를 비우고 다시 시작합니다.

    구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.

11.6.1. OpenStack을 위한 SR-IOV 네트워크 노드 정책의 예

다음 예제에서는 Red Hat OpenStack Platform(RHOSP)에서 하드웨어 오프로드를 갖춘 네트워크 인터페이스 컨트롤러(NIC)에 대한 SR-IOV 인터페이스를 설명합니다.

RHOSP에서 하드웨어 오프로드가 가능한 NIC용 SR-IOV 인터페이스

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: ${name}
  namespace: openshift-sriov-network-operator
spec:
  deviceType: switchdev
  isRdma: true
  nicSelector:
    netFilter: openstack/NetworkID:${net_id}
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: 'true'
  numVfs: 1
  priority: 99
  resourceName: ${name}
Copy to Clipboard Toggle word wrap

11.7. 가상 함수를 사용하여 네트워크 트래픽 성능 개선

이 절차에 따라 OVN-Kubernetes 관리 포트에 가상 기능을 할당하고 네트워크 트래픽 성능을 높이세요.

이 절차를 통해 두 개의 풀이 생성됩니다. 첫 번째 풀에는 OVN-Kubernetes에서 사용되는 가상 함수가 있고, 두 번째 풀에는 나머지 가상 함수가 포함됩니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 다음 명령을 실행하여 SmartNIC이 있는 각 작업자 노드에 network.operator.openshift.io/smart-nic 레이블을 추가합니다.

    $ oc label node <node-name> network.operator.openshift.io/smart-nic=
    Copy to Clipboard Toggle word wrap

    oc get nodes 명령을 사용하여 사용 가능한 노드 목록을 가져옵니다.

  2. 다음 예와 같은 내용을 사용하여 관리 포트에 대한 sriov-node-mgmt-vf-policy.yaml 이라는 이름의 정책을 만듭니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: sriov-node-mgmt-vf-policy
      namespace: openshift-sriov-network-operator
    spec:
      deviceType: netdevice
      eSwitchMode: "switchdev"
      nicSelector:
        deviceID: "1019"
        rootDevices:
        - 0000:d8:00.0
        vendor: "15b3"
        pfNames:
        - ens8f0#0-0 
    1
    
      nodeSelector:
        network.operator.openshift.io/smart-nic: ""
      numVfs: 6 
    2
    
      priority: 5
      resourceName: mgmtvf
    Copy to Clipboard Toggle word wrap
    1
    이 장치를 사용 사례에 적합한 네트워크 장치로 교체하세요. pfNames 값의 #0-0 부분은 OVN-Kubernetes에서 사용되는 단일 가상 함수를 예약합니다.
    2
    여기에 제공된 값은 예시입니다. 이 값을 요구 사항에 맞는 값으로 바꾸세요. 자세한 내용은 추가 리소스 섹션의 SR-IOV 네트워크 노드 구성 객체를 참조하세요.
  3. 다음 예와 같은 내용을 포함하는 sriov-node-policy.yaml 이라는 정책을 만듭니다.

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy
    metadata:
      name: sriov-node-policy
      namespace: openshift-sriov-network-operator
    spec:
      deviceType: netdevice
      eSwitchMode: "switchdev"
      nicSelector:
        deviceID: "1019"
        rootDevices:
        - 0000:d8:00.0
        vendor: "15b3"
        pfNames:
        - ens8f0#1-5 
    1
    
      nodeSelector:
        network.operator.openshift.io/smart-nic: ""
      numVfs: 6 
    2
    
      priority: 5
      resourceName: mlxnics
    Copy to Clipboard Toggle word wrap
    1
    이 장치를 사용 사례에 적합한 네트워크 장치로 교체하세요.
    2
    여기에 제공된 값은 예시입니다. 이 값을 sriov-node-mgmt-vf-policy.yaml 파일에 지정된 값으로 바꾸세요. 자세한 내용은 추가 리소스 섹션의 SR-IOV 네트워크 노드 구성 객체를 참조하세요.
    참고

    sriov-node-mgmt-vf-policy.yaml 파일의 pfNamesresourceName 키 값은 sriov-node-policy.yaml 파일의 값과 다릅니다.

  4. 두 정책 모두에 구성을 적용합니다.

    $ oc create -f sriov-node-policy.yaml
    Copy to Clipboard Toggle word wrap
    $ oc create -f sriov-node-mgmt-vf-policy.yaml
    Copy to Clipboard Toggle word wrap
  5. 관리 구성을 위해 클러스터에 CNO(클러스터 네트워크 운영자) ConfigMap을 만듭니다.

    1. 다음 내용으로 hardware-offload-config.yaml 이라는 ConfigMap을 만듭니다.

      apiVersion: v1
      kind: ConfigMap
      metadata:
          name: hardware-offload-config
          namespace: openshift-network-operator
      data:
          mgmt-port-resource-name: openshift.io/mgmtvf
      Copy to Clipboard Toggle word wrap
    2. ConfigMap에 대한 구성을 적용합니다.

      $ oc create -f hardware-offload-config.yaml
      Copy to Clipboard Toggle word wrap

11.8. 네트워크 연결 정의 생성

머신 구성 풀과 SR-IOV 네트워크 노드 정책을 정의한 후, 지정한 네트워크 인터페이스 카드에 대한 네트워크 연결 정의를 생성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 다음 예시와 같은 내용을 담은 net-attach-def.yaml 과 같은 파일을 만듭니다.

    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: net-attach-def 
    1
    
      namespace: net-attach-def 
    2
    
      annotations:
        k8s.v1.cni.cncf.io/resourceName: openshift.io/mlxnics 
    3
    
    spec:
      config: '{"cniVersion":"0.3.1","name":"ovn-kubernetes","type":"ovn-k8s-cni-overlay","ipam":{},"dns":{}}'
    Copy to Clipboard Toggle word wrap
    1
    네트워크 연결 정의에 대한 이름입니다.
    2
    네트워크 연결 정의에 대한 네임스페이스입니다.
    3
    이는 SriovNetworkNodePolicy 개체에서 지정한 spec.resourceName 필드의 값입니다.
  2. 네트워크 연결 정의에 대한 구성을 적용합니다.

    $ oc create -f net-attach-def.yaml
    Copy to Clipboard Toggle word wrap

검증

  • 다음 명령을 실행하여 새로운 정의가 있는지 확인하세요.

    $ oc get net-attach-def -A
    Copy to Clipboard Toggle word wrap

    출력 예

    NAMESPACE         NAME             AGE
    net-attach-def    net-attach-def   43h
    Copy to Clipboard Toggle word wrap

11.9. 포드에 네트워크 연결 정의 추가

머신 구성 풀, SriovNetworkPoolConfigSriovNetworkNodePolicy 사용자 정의 리소스, 네트워크 연결 정의를 만든 후에는 네트워크 연결 정의를 포드 사양에 추가하여 이러한 구성을 포드에 적용할 수 있습니다.

프로세스

  • Pod 사양에서 .metadata.annotations.k8s.v1.cni.cncf.io/networks 필드를 추가하고 하드웨어 오프로드를 위해 생성한 네트워크 연결 정의를 지정합니다.

    ....
    metadata:
      annotations:
        v1.multus-cni.io/default-network: net-attach-def/net-attach-def 
    1
    Copy to Clipboard Toggle word wrap
    1
    값은 하드웨어 오프로드를 위해 생성한 네트워크 연결 정의의 이름과 네임스페이스여야 합니다.

12장. Bluefield-2를 DPU에서 NIC로 전환

Bluefield-2 네트워크 장치를 DPU(데이터 처리 장치) 모드에서 NIC(네트워크 인터페이스 컨트롤러) 모드로 전환할 수 있습니다.

다음 문서의 작업을 수행하기 전에 SR-IOV 네트워크 운영자가 설치되어 있는지 확인하세요.

12.1. Bluefield-2를 DPU 모드에서 NIC 모드로 전환

다음 절차에 따라 Bluefield-2를 DPU(데이터 처리 장치) 모드에서 NIC(네트워크 인터페이스 컨트롤러) 모드로 전환하세요.

중요

현재는 Bluefield-2를 DPU에서 NIC 모드로 전환하는 것만 지원됩니다. NIC 모드에서 DPU 모드로 전환하는 것은 지원되지 않습니다.

사전 요구 사항

  • SR-IOV Network Operator가 설치되어 있습니다. 자세한 내용은 "SR-IOV 네트워크 운영자 설치"를 참조하세요.
  • Bluefield-2를 최신 펌웨어로 업데이트했습니다. 자세한 내용은 NVIDIA BlueField-2용 펌웨어를 참조하세요.

프로세스

  1. 다음 명령을 입력하여 각 컴퓨팅 노드에 다음 레이블을 추가합니다. 각 컴퓨팅 노드에 대해 명령을 실행해야 합니다.

    $ oc label node <node_name> node-role.kubernetes.io/sriov=
    Copy to Clipboard Toggle word wrap

다음과 같습니다.

node_name
컴퓨팅 노드의 이름을 나타냅니다.
  1. 예를 들어 SR-IOV 네트워크 운영자에 대한 머신 구성 풀을 생성합니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfigPool
    metadata:
      name: sriov
    spec:
      machineConfigSelector:
        matchExpressions:
        - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,sriov]}
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/sriov: ""
    Copy to Clipboard Toggle word wrap
  2. 다음 machineconfig.yaml 파일을 컴퓨팅 노드에 적용합니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: sriov
      name: 99-bf2-dpu
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,ZmluZF9jb250YWluZXIoKSB7CiAgY3JpY3RsIHBzIC1vIGpzb24gfCBqcSAtciAnLmNvbnRhaW5lcnNbXSB8IHNlbGVjdCgubWV0YWRhdGEubmFtZT09InNyaW92LW5ldHdvcmstY29uZmlnLWRhZW1vbiIpIHwgLmlkJwp9CnVudGlsIG91dHB1dD0kKGZpbmRfY29udGFpbmVyKTsgW1sgLW4gIiRvdXRwdXQiIF1dOyBkbwogIGVjaG8gIndhaXRpbmcgZm9yIGNvbnRhaW5lciB0byBjb21lIHVwIgogIHNsZWVwIDE7CmRvbmUKISBzdWRvIGNyaWN0bCBleGVjICRvdXRwdXQgL2JpbmRhdGEvc2NyaXB0cy9iZjItc3dpdGNoLW1vZGUuc2ggIiRAIgo=
            mode: 0755
            overwrite: true
            path: /etc/default/switch_in_sriov_config_daemon.sh
        systemd:
          units:
          - name: dpu-switch.service
            enabled: true
            contents: |
              [Unit]
              Description=Switch BlueField2 card to NIC/DPU mode
              RequiresMountsFor=%t/containers
              Wants=network.target
              After=network-online.target kubelet.service
              [Service]
              SuccessExitStatus=0 120
              RemainAfterExit=True
              ExecStart=/bin/bash -c '/etc/default/switch_in_sriov_config_daemon.sh nic || shutdown -r now' 
    1
    
              Type=oneshot
              [Install]
              WantedBy=multi-user.target
    Copy to Clipboard Toggle word wrap
    1
    선택 사항: 특정 카드의 PCI 주소를 선택적으로 지정할 수 있습니다(예: ExecStart=/bin/bash -c '/etc/default/switch_in_sriov_config_daemon.sh nic 0000:5e:00.0 || echo done' ) . 기본적으로 첫 번째 장치가 선택됩니다. 장치가 두 개 이상인 경우 사용할 PCI 주소를 지정해야 합니다. PCI 주소는 Bluefield-2를 DPU 모드에서 NIC 모드로 전환하는 모든 노드에서 동일해야 합니다.
  3. 컴퓨팅 노드가 다시 시작될 때까지 기다리세요. 재시작 후, 컴퓨팅 노드의 Bluefield-2 네트워크 장치가 NIC 모드로 전환됩니다.
  4. 선택 사항: 최신 Bluefield-2 펌웨어 릴리스에서는 NIC 모드로 전환하려면 하드웨어를 다시 시작해야 하므로 호스트 하드웨어를 다시 시작해야 할 수도 있습니다.

Legal Notice

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat