하드웨어 네트워크
OpenShift Container Platform에서 하드웨어별 네트워킹 기능 구성
초록
1장. SR-IOV(Single Root I/O Virtualization) 하드웨어 네트워크 정보 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV(Single Root I/O Virtualization) 사양은 단일 장치를 여러 Pod와 공유할 수 있는 PCI 장치 할당 유형의 표준입니다.
SR-IOV Operator 를 사용하여 클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치를 구성할 수 있습니다.
SR-IOV를 사용하면 호스트 노드에서 물리적 기능(PF)으로 인식되는 호환 네트워크 장치를 여러 VF(가상 기능)로 분할할 수 있습니다. VF는 다른 네트워크 장치와 같이 사용됩니다. 장치의 SR-IOV 네트워크 장치 드라이버는 컨테이너에서 VF가 노출되는 방식을 결정합니다.
-
netdevice드라이버: 컨테이너의netns에 있는 일반 커널 네트워크 장치 -
vfio-pci드라이버: 컨테이너에 마운트된 문자 장치
높은 대역폭 또는 짧은 대기 시간이 필요한 애플리케이션을 위해 베어 메탈 또는 RHOSP(Red Hat OpenStack Platform) 인프라에 설치된 OpenShift Container Platform 클러스터에서 추가 네트워크와 함께 SR-IOV 네트워크 장치를 사용할 수 있습니다.
SR-IOV 네트워크에 대한 다중 네트워크 정책을 구성할 수 있습니다. 이에 대한 지원은 기술 프리뷰이며 SR-IOV 추가 네트워크는 커널 NIC에서만 지원됩니다. DPDK(Data Plane Development Kit) 애플리케이션에서는 지원되지 않습니다.
SR-IOV 네트워크에서 다중 네트워크 정책을 생성하면 다중 네트워크 정책이 구성되지 않은 SR-IOV 네트워크와 비교하여 애플리케이션에 동일한 성능을 제공하지 못할 수 있습니다.
SR-IOV 네트워크의 다중 네트워크 정책은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
다음 명령을 사용하여 노드에서 SR-IOV를 활성화할 수 있습니다.
oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
1.2. SR-IOV 네트워크 장치를 관리하는 구성 요소 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV 네트워크 Operator는 SR-IOV 스택의 구성 요소를 생성하고 관리합니다. Operator는 다음 기능을 수행합니다.
- SR-IOV 네트워크 장치 검색 및 관리 오케스트레이션
-
SR-IOV 컨테이너 네트워크 인터페이스(CNI)에 대한
NetworkAttachmentDefinition사용자 정의 리소스 생성 - SR-IOV 네트워크 장치 플러그인의 구성 생성 및 업데이트
-
노드별
SriovNetworkNodeState사용자 정의 리소스 생성 -
각
SriovNetworkNodeState사용자 정의 리소스에서spec.interfaces필드 업데이트
Operator는 다음 구성 요소를 프로비저닝합니다.
- SR-IOV 네트워크 구성 데몬
- SR-IOV 네트워크 Operator가 시작될 때 작업자 노드에 배포되는 데몬 세트입니다. 데몬은 클러스터에서 SR-IOV 네트워크 장치를 검색하고 초기화합니다.
- SR-IOV 네트워크 Operator webhook
- Operator 사용자 정의 리소스의 유효성을 검증하고 설정되지 않은 필드에 적절한 기본값을 설정하는 동적 승인 컨트롤러 webhook.
- SR-IOV 네트워크 리소스 인젝터
-
SR-IOV VF와 같은 사용자 정의 네트워크 리소스에 대한 요청 및 제한으로 Kubernetes pod 사양을 패치하는 기능을 제공하는 동적 승인 컨트롤러 webhook. SR-IOV 네트워크 리소스 인젝터는 Pod의 첫 번째 컨테이너에만
리소스필드를 자동으로 추가합니다. - SR-IOV 네트워크 장치 플러그인
- SR-IOV 네트워크 VF(가상 기능) 리소스를 검색, 광고 및 할당하는 장치 플러그인입니다. 장치 플러그인은 Kubernetes에서 일반적으로 물리적 장치에서 제한된 리소스를 사용할 수 있도록 사용됩니다. 장치 플러그인은 Kubernetes 스케줄러에서 리소스 가용성을 인식하여 스케줄러가 충분한 리소스가 있는 노드에서 Pod를 예약할 수 있도록 합니다.
- SR-IOV CNI 플러그인
- SR-IOV 네트워크 장치 플러그인에서 할당된 VF 인터페이스를 pod에 직접 연결하는 CNI 플러그인입니다.
- SR-IOV InfiniBand CNI 플러그인
- SR-IOV 네트워크 장치 플러그인에서 할당된 IB(InfiniBand) VF 인터페이스를 pod에 직접 연결하는 CNI 플러그인입니다.
SR-IOV 네트워크 리소스 인젝터 및 SR-IOV 네트워크 Operator webhook는 기본적으로 활성화되어 있으며 기본 SriovOperatorConfig CR을 편집하여 비활성화할 수 있습니다. SR-IOV 네트워크 Operator Admission Controller 웹 후크를 비활성화할 때 주의하십시오. 문제 해결 또는 지원되지 않는 장치를 사용하려는 경우 특정 상황에서 Webhook를 비활성화할 수 있습니다.
1.2.1. 지원되는 플랫폼 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV Network Operator는 다음 플랫폼에서 지원됩니다.
- 베어 메탈
- Red Hat OpenStack Platform (RHOSP)
1.2.2. 지원되는 장치 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform에서는 다음 네트워크 인터페이스 컨트롤러를 지원합니다.
| 제조업체 | 모델 | 벤더 ID | 장치 ID |
|---|---|---|---|
| Broadcom | BCM57414 | 14e4 | 16d7 |
| Broadcom | BCM57508 | 14e4 | 1750 |
| Broadcom | BCM57504 | 14e4 | 1751 |
| Intel | X710 | 8086 | 1572 |
| Intel | X710 Backplane | 8086 | 1581 |
| Intel | X710 Base T | 8086 | 15FF |
| 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 Backplane | 8086 | 1599 |
| Intel | E823L Backplane | 8086 | 124c |
| Intel | Ice E823L SFP | 8086 | 124d |
| Marvell | OCTEON Fusion CNF105XX | 177d | ba00 |
| Marvell | OCTEON10 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 | MT42822 BlueField-2 in ConnectX-6 NIC 모드 | 15b3 | a2d6 |
| Pensando [1] | ionic 드라이버용 DSC-25 듀얼 포트 25G 분산 서비스 카드 | 0x1dd8 | 0x1002 |
| Pensando [1] | ionic 드라이버용 DSC-100 듀얼 포트 100G 분산 서비스 카드 | 0x1dd8 | 0x1003 |
| Silicom | STS 제품군 | 8086 | 1591 |
- OpenShift SR-IOV는 지원되지만 SR-IOV를 사용할 때 SR-IOV CNI 구성 파일을 사용하여 고정 VF(가상 기능) 미디어 액세스 제어(MAC) 주소를 설정해야 합니다.
지원되는 카드 및 호환 가능한 OpenShift Container Platform 버전의 최신 목록은 Openshift SR-IOV(Single Root I/O Virtualization) 및 PTP 하드웨어 네트워크 지원 매트릭스 를 참조하십시오.
1.4. 다음 단계 링크 복사링크가 클립보드에 복사되었습니다!
- SR-IOV Network Operator 구성
- SR-IOV 네트워크 장치 구성
- OpenShift Virtualization을 사용하는 경우: 가상 머신을 SR-IOV 네트워크에 연결
- SR-IOV 네트워크 연결 구성
- 이더넷 네트워크 연결: SR-IOV 추가 네트워크에 Pod 추가
- InfiniBand 네트워크 연결: SR-IOV 추가 네트워크에 Pod 추가
2장. SR-IOV 네트워크 장치 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치를 구성할 수 있습니다.
다음 문서에서 작업을 수행하기 전에 SR-IOV Network Operator를 설치 했는지 확인합니다.
2.1. SR-IOV 네트워크 노드 구성 오브젝트 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV 네트워크 노드 정책을 생성하여 노드의 SR-IOV 네트워크 장치 구성을 지정합니다. 정책의 API 오브젝트는 sriovnetwork.openshift.io API 그룹의 일부입니다.
다음 YAML은 SR-IOV 네트워크 노드 정책을 설명합니다.
- 1
- 사용자 정의 리소스 오브젝트의 이름입니다.
- 2
- SR-IOV Network Operator가 설치된 네임스페이스입니다.
- 3
- SR-IOV 네트워크 장치 플러그인의 리소스 이름입니다. 리소스 이름에 대한 SR-IOV 네트워크 노드 정책을 여러 개 생성할 수 있습니다.
이름을 지정할 때
resourceName에 허용되는 구문 표현식^[a-zA-Z0-9_]+$를 사용해야 합니다. - 4
- 노드 선택기는 구성할 노드를 지정합니다. 선택한 노드의 SR-IOV 네트워크 장치만 구성됩니다. SR-IOV CNI(Container Network Interface) 플러그인 및 장치 플러그인은 선택한 노드에만 배포됩니다.중요
SR-IOV Network Operator는 노드 네트워크 구성 정책을 순서대로 노드에 적용합니다. 노드 네트워크 구성 정책을 적용하기 전에 SR-IOV Network Operator는 노드의 MCP(Machine config pool)가
Degraded또는 Update와 같은 비정상적인 상태에 있는지확인합니다. 노드가 비정상 MCP에 있는 경우 MCP가 정상 상태로 돌아올 때까지 클러스터의 모든 대상 노드에 노드 네트워크 구성 정책을 적용하는 프로세스입니다.비정상 MCP의 노드가 다른 MCP의 노드를 포함하여 다른 노드에 대한 노드 네트워크 구성 정책의 애플리케이션을 차단하지 않도록 하려면 각 MCP에 대한 별도의 노드 네트워크 구성 정책을 생성해야 합니다.
- 5
- 선택 사항: 우선순위는
0에서99사이의 정수 값입니다. 작은 값은 우선순위가 높습니다. 예를 들어 우선순위10은 우선순위99보다 높습니다. 기본값은99입니다. - 6
- 선택 사항: 물리적 기능의 최대 전송 단위(MTU) 및 모든 가상 기능입니다. 최대 MTU 값은 네트워크 인터페이스 컨트롤러(NIC) 모델마다 다를 수 있습니다.중요
기본 네트워크 인터페이스에서 가상 기능을 생성하려면 MTU가 클러스터 MTU와 일치하는 값으로 설정되어 있는지 확인합니다.
함수가 pod에 할당되는 동안 단일 가상 기능의 MTU를 수정하려면 SR-IOV 네트워크 노드 정책에 MTU 값을 비워 둡니다. 그렇지 않으면 SR-IOV Network Operator에서 가상 기능의 MTU를 SR-IOV 네트워크 노드 정책에 정의된 MTU 값으로 되돌립니다. 이로 인해 노드 드레이닝이 트리거될 수 있습니다.
- 7
- 선택 사항: pod에
/dev/vhost-net장치를 마운트하려면needVhostNet을true로 설정합니다. DPDK(Data Plane Development Kit)와 함께 마운트된/dev/vhost-net장치를 사용하여 트래픽을 커널 네트워크 스택으로 전달합니다. - 8
- SR-IOV 물리적 네트워크 장치에 생성할 VF(가상 기능) 수입니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는
127보다 클 수 없습니다. - 9
- external
Managed필드는 SR-IOV Network Operator가 모두 관리되는지 또는 VF(가상 기능) 서브 세트만 관리하는지 여부를 나타냅니다. 값을false로 설정하면 SR-IOV Network Operator가 PF의 모든 VF를 관리하고 구성합니다.참고external
Managed가true로 설정된 경우SriovNetworkNodePolicy리소스를 적용하기 전에 PF(가상 기능)에 VF(가상 기능)를 수동으로 생성해야 합니다. VF가 사전 생성되지 않은 경우 SR-IOV Network Operator의 Webhook에서 정책 요청을 차단합니다.external
Managed가false로 설정되면 SR-IOV Network Operator가 필요한 경우 재설정을 포함하여 VF를 자동으로 생성하고 관리합니다.호스트 시스템에서 VF를 사용하려면 NMState를 통해 생성하고 external
Managed를설정해야 합니다. 이 모드에서 SR-IOV Network Operator는 정책의true로nicSelector필드에 명시적으로 정의된 PF 또는 수동으로 관리되는 VF를 수정하지 않습니다. 그러나 SR-IOV Network Operator는 Pod 보조 인터페이스로 사용되는 VF를 계속 관리합니다. - 10
- NIC 선택기는 이 리소스가 적용되는 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다.
rootDevices를 지정하면vendor,deviceID또는pfNames의 값도 지정해야 합니다.pfNames와rootDevices를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오.netFilter의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다. - 11
- 선택사항: SR-IOV 네트워크 장치의 벤더 16진수 벤더 식별자입니다. 허용되는 값은
8086(Intel) 및15b3(M#159nox)입니다. - 12
- 선택사항: SR-IOV 네트워크 장치의 장치 16진수 장치 식별자입니다. 예를 들어
101b는 Mellanox ConnectX-6 장치의 장치 ID입니다. - 13
- 선택 사항: 리소스가 적용해야 하는 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.
- 14
- 선택 사항: 리소스가 적용해야 하는 하나 이상의 PCI 버스 주소로 구성된 배열입니다. 예:
0000:02:00.1. - 15
- 선택 사항: 플랫폼별 네트워크 필터입니다. 지원되는 유일한 플랫폼은 RHOSP(Red Hat OpenStack Platform)입니다. 허용 가능한 값은 다음 형식을 사용합니다.
openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx를/var/config/openstack/latest/network_data.json메타데이터 파일의 값으로 바꿉니다. 이 필터를 사용하면 VF가 특정 OpenStack 네트워크와 연결되어 있습니다. Operator는 이 필터를 사용하여 OpenStack 플랫폼에서 제공하는 메타데이터를 기반으로 VF를 적절한 네트워크에 매핑합니다. - 16
- 선택사항: 이 리소스에서 생성된 VF에 대해 구성할 드라이버입니다. 허용되는 값은
netdevice및vfio-pci입니다. 기본값은netdevice입니다.베어 메탈 노드의 DPDK 모드에서 Mellanox NIC가 작동하려면
netdevice드라이버 유형을 사용하고isRdma를true로 설정합니다. - 17
- 선택 사항: 원격 직접 메모리 액세스(RDMA) 모드를 활성화할지 여부를 구성합니다. 기본값은
false입니다.isRdma매개변수가true로 설정된 경우 RDMA 사용 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다.isRdma를true로 설정하고 추가로needVhostNet을true로 설정하여 Fast Datapath DPDK 애플리케이션에서 사용할 Mellanox NIC를 구성합니다.참고intel NIC의 경우
isRdma매개변수를true로 설정할 수 없습니다. - 18
- 선택사항: VF의 링크 유형입니다. 기본값은
eth이더넷입니다. 이 값을 InfiniBand의 'ib'로 변경합니다.linkType을ib로 설정하면isRdma가 SR-IOV Network Operator 웹 후크에 의해 자동으로true로 설정됩니다.linkType을ib로 설정하면deviceType을vfio-pci로 설정해서는 안 됩니다.장치 플러그인에서 보고한 사용 가능한 장치 수가 올바르지 않을 수 있으므로 SriovNetworkNodePolicy의 linkType을
eth로 설정하지 마십시오. - 19
- 선택 사항: 하드웨어 오프로드를 활성화하려면
eSwitchMode필드를"switchdev"로 설정해야 합니다. 하드웨어 오프로드에 대한 자세한 내용은 "하드웨어 오프로드 구성"을 참조하십시오. - 20
- 선택 사항: SR-IOV 네트워크 리소스의 NUMA 노드를 토폴로지 관리자로 알리려면 값을
true로 설정합니다. 기본값은false입니다.
2.1.1. SR-IOV 네트워크 노드 구성 예 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제에서는 InfiniBand 장치의 구성을 설명합니다.
InfiniBand 장치의 구성 예
다음 예제에서는 RHOSP 가상 머신의 SR-IOV 네트워크 장치에 대한 구성을 설명합니다.
가상 머신의 SR-IOV 장치 구성 예
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 오브젝트
2.1.3. SR-IOV 장치의 VF(가상 기능) 파티셔닝 링크 복사링크가 클립보드에 복사되었습니다!
경우에 따라 동일한 물리적 기능(PF)에서 많은 리소스 풀로 VF(가상 기능)를 분할할 수 있습니다. 예를 들어, 일부 VF를 기본 드라이버로 로드하고 나머지 VF를vfio-pci 드라이버로 로드할 수 있습니다.
예를 들어 다음 YAML은 VF 2에서 7까지의 netpf0 인터페이스에 대한 선택기를 보여줍니다.
pfNames: ["netpf0#2-7"]
pfNames: ["netpf0#2-7"]
다음과 같습니다.
netpf0- PF 인터페이스의 이름입니다.
2- 범위에 포함된 첫 번째 VF 인덱스(0 기반)입니다.
7- 범위에 포함된 마지막 VF 인덱스(0 기반)입니다.
다음 요구 사항을 충족하는 다양한 정책 CR을 사용하여 동일한 PF에서 VF를 선택할 수 있습니다.
-
numVfs값은 동일한 PF를 선택하는 정책과 유사해야 합니다. -
VF 색인은
0에서<numVfs>-1까지의 범위 내에 있어야 합니다. 예를 들어,numVfs가8로 설정된 정책이 있는 경우<first_vf>값은0보다 작아야 하며<last_vf>는7보다 크지 않아야 합니다. - 다른 정책의 VF 범위는 겹치지 않아야 합니다.
-
<first_vf>는<last_vf>보다 클 수 없습니다.
다음 예는 SR-IOV 장치의 NIC 파티셔닝을 보여줍니다.
정책 policy-net-1 은 기본 VF 드라이버와 함께 PF net pf 을 정의합니다. 정책 0 의 VF 0을 포함하는 리소스 풀 net -1policy-net-1-dpdk 는 vfio VF 드라이버와 함께 PF netpf0 의 VF 8 ~15 를 포함하는 리소스 풀 net-1-dpdk 를 정의합니다.
정책 policy-net-1:
정책 policy-net-1-dpdk:
인터페이스가 성공적으로 분할되었는지 확인
다음 명령을 실행하여 SR-IOV 장치의 VF(가상 기능)로 분할된 인터페이스가 있는지 확인합니다.
ip link show <interface>
$ ip link show <interface>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;interface>를 SR-IOV 장치의 VF로 분할할 때 지정한 인터페이스로 바꿉니다(예:ens3f1).
출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.4. OpenStack에서 SR-IOV를 사용하는 클러스터의 테스트 Pod 템플릿 링크 복사링크가 클립보드에 복사되었습니다!
다음 testpmd Pod는 대규모 페이지, 예약된 CPU 및 SR-IOV 포트로 컨테이너 생성을 보여줍니다.
testpmd Pod의 예
- 1
- 이 예에서는 성능 프로필의 이름이
cnf-performance 프로필이라고 가정합니다.
2.1.5. OpenStack에서 OVS 하드웨어 오프로드를 사용하는 클러스터의 테스트 포드 템플릿 링크 복사링크가 클립보드에 복사되었습니다!
다음 testpmd Pod는 RHOSP(Red Hat OpenStack Platform)에서 OVS(Open vSwitch) 하드웨어 오프로드를 보여줍니다.
testpmd Pod의 예
- 1
- 성능 프로필의 이름이
cnf-performance 프로필로 지정되지 않은 경우 해당 문자열을 올바른 성능 프로필 이름으로 교체합니다.
2.1.6. Downward API 에 대한 대규보 페이지 리소스 주입 링크 복사링크가 클립보드에 복사되었습니다!
Pod 사양에 대규모 페이지에 대한 리소스 요청 또는 제한이 포함된 경우 Network Resources Injector는 컨테이너에 대규모 페이지 정보를 제공하기 위해 Pod 사양에 Downward API 필드를 자동으로 추가합니다.
Network Resources Injector는 podnetinfo라는 볼륨을 추가하고 Pod의 각 컨테이너에 대해 /etc/podnetinfo에 마운트됩니다. 볼륨은 Downward API를 사용하며 대규모 페이지 요청 및 제한에 대한 파일을 포함합니다. 파일 이름 지정 규칙은 다음과 같습니다.
-
/etc/podnetinfo/hugepages_1G_request_<container-name> -
/etc/podnetinfo/hugepages_1G_limit_<container-name> -
/etc/podnetinfo/hugepages_2M_request_<container-name> -
/etc/podnetinfo/hugepages_2M_limit_<container-name>
이전 목록에 지정된 경로는 app-netutil 라이브러리와 호환됩니다. 기본적으로 라이브러리는 /etc/podnetinfo 디렉터리에서 리소스 정보를 검색하도록 구성됩니다. Downward API 경로 항목을 수동으로 지정하도록 선택하는 경우 app-netutil 라이브러리는 이전 목록의 경로 외에도 다음 경로를 검색합니다.
-
/etc/podnetinfo/hugepages_request -
/etc/podnetinfo/hugepages_limit -
/etc/podnetinfo/hugepages_1G_request -
/etc/podnetinfo/hugepages_1G_limit -
/etc/podnetinfo/hugepages_2M_request -
/etc/podnetinfo/hugepages_2M_limit
Network Resources Injector에서 생성할 수 있는 경로와 마찬가지로, 이전 목록의 경로는 선택적으로 _<container-name> 접미사로 종료할 수 있습니다.
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=on및iommu=pt가 포함되지 않은 경우에만 재부팅이 수행됩니다.
구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - SR-IOV Network Operator가 설치되어 있습니다.
- 비운 노드에서 제거된 워크로드를 처리하기 위해 클러스터에 사용 가능한 노드가 충분합니다.
- SR-IOV 네트워크 장치 구성에 대한 컨트롤 플레인 노드를 선택하지 않았습니다.
절차
-
SriovNetworkNodePolicy오브젝트를 생성한 후 YAML을<name>-sriov-node-network.yaml파일에 저장합니다.<name>을 이 구성의 이름으로 바꿉니다. -
선택 사항:
SriovNetworkNodePolicy.Spec.NodeSelector를 사용하여 SR-IOV 가능 클러스터 노드에 레이블을 지정하지 않은 경우 레이블을 지정합니다. 노드 레이블 지정에 대한 자세한 내용은 "노드에서 라벨을 업데이트하는 방법 이해"를 참조하십시오. SriovNetworkNodePolicy오브젝트를 생성합니다.oc create -f <name>-sriov-node-network.yaml
$ oc create -f <name>-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow <name>은 이 구성의 이름을 지정합니다.구성 업데이트를 적용하면
sriov-network-operator네임스페이스의 모든 Pod가Running상태로 전환됩니다.SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다.
<node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다.oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. NUMA(Non-Uniform Memory Access) 정렬 SR-IOV Pod 생성 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV 및 제한된 또는 single-numa-node 토폴로지 관리자 정책으로 동일한 NUMA 노드에서 할당된 CPU 리소스를 제한하여 NUMA 정렬 SR-IOV Pod를 생성할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
CPU 관리자 정책을
static으로 구성했습니다. CPU 관리자에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오. 토폴로지 관리자 정책을
single-numa-node로 구성했습니다.참고single-numa-node가 요청을 충족할 수 없는 경우 Topology Manager 정책을restricted로 구성할 수 있습니다. 보다 유연한 SR-IOV 네트워크 리소스 스케줄링은 추가 리소스 섹션에서 NUMA 인식 스케줄링 중 SR-IOV 네트워크 토폴로지 제외 를 참조하십시오.
절차
다음과 같은 SR-IOV Pod 사양을 생성한 다음 YAML을
<name>-sriov-pod.yaml파일에 저장합니다.<name>을 이 Pod의 이름으로 바꿉니다.다음 예는 SR-IOV Pod 사양을 보여줍니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 샘플 SR-IOV Pod를 만듭니다.
oc create -f <filename>
$ oc create -f <filename>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<filename>을 이전 단계에서 생성한 파일 이름으로 바꿉니다.
sample-pod가 보장된 QoS로 구성되어 있는지 확인하십시오.oc describe pod sample-pod
$ oc describe pod sample-podCopy to Clipboard Copied! Toggle word wrap Toggle overflow sample-pod에 전용 CPU가 할당되어 있는지 확인하십시오.oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpusCopy to Clipboard Copied! Toggle word wrap Toggle overflow sample-pod에 할당된 SR-IOV 장치 및 CPU가 동일한 NUMA 노드에 있는지 확인하십시오.oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpusCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4. NUMA 인식 스케줄링의 SR-IOV 네트워크 토폴로지 제외 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV 네트워크의 NUMA(Non-Uniform Memory Access) 노드를 토폴로지 관리자에게 알리면 NUMA 인식 Pod 예약 중에 보다 유연한 SR-IOV 네트워크 배포를 제외할 수 있습니다.
일부 시나리오에서는 단일 NUMA 노드에서 Pod의 CPU 및 메모리 리소스를 최대화하는 것이 우선 순위입니다. 토폴로지 관리자는 Pod의 SR-IOV 네트워크 리소스에 대한 NUMA 노드에 대한 힌트를 제공하지 않기 때문에 토폴로지 관리자는 SR-IOV 네트워크 리소스 및 Pod CPU 및 메모리 리소스를 다른 NUMA 노드에 배포할 수 있습니다. NUMA 노드 간 데이터 전송으로 인해 네트워크 대기 시간에 추가할 수 있습니다. 그러나 워크로드에 최적의 CPU 및 메모리 성능이 필요한 경우에는 이 기능이 허용됩니다.
예를 들어 numa0 과 numa1 이라는 두 개의 NUMA 노드가 있는 컴퓨팅 노드인 compute-1 을 고려해 보십시오. SR-IOV 지원 NIC는 numa0 에 있습니다. Pod 예약에 사용 가능한 CPU는 numa1 에만 있습니다. Topology Manager는 excludeTopology 사양을 true 로 설정하여 Pod의 CPU 및 메모리 리소스를 numa1 에 할당할 수 있으며 동일한 pod의 SR-IOV 네트워크 리소스를 numa0 에 할당할 수 있습니다. 이는 excludeTopology 사양을 true 로 설정한 경우에만 가능합니다. 그렇지 않으면 토폴로지 관리자가 동일한 NUMA 노드에 모든 리소스를 배치하려고 합니다.
2.5. SR-IOV 구성 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV 네트워크 장치를 구성하는 절차를 수행한 후 다음 섹션에서는 일부 오류 조건을 다룹니다.
프로세스
- 노드 상태를 표시하려면 다음 명령을 실행합니다.
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>
$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>
다음과 같습니다.
- <node_name>
- SR-IOV 네트워크 장치가 있는 노드의 이름을 지정합니다.
명령의 출력에 "메모리 할당할 수 없음"이 표시되면 다음 항목을 확인합니다.
- 글로벌 SR-IOV 설정이 노드의 BIOS에서 활성화되어 있는지 확인합니다.
- BIOS에서 노드에 대해 VT-d가 활성화되어 있는지 확인합니다.
2.6. 다음 단계 링크 복사링크가 클립보드에 복사되었습니다!
3장. SR-IOV 이더넷 네트워크 연결 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치에 대한 이더넷 네트워크 연결을 구성할 수 있습니다.
다음 문서에서 작업을 수행하기 전에 SR-IOV Network Operator를 설치 했는지 확인합니다.
3.1. 이더넷 장치 구성 오브젝트 링크 복사링크가 클립보드에 복사되었습니다!
SriovNetwork 오브젝트를 정의하여 이더넷 네트워크 장치를 구성할 수 있습니다.
다음 YAML은 SriovNetwork 오브젝트를 설명합니다.
- 1
- 오브젝트의 이름입니다. SR-IOV Network Operator는 동일한 이름으로
NetworkAttachmentDefinition오브젝트를 생성합니다. - 2
- SR-IOV Network Operator가 설치된 네임스페이스입니다.
- 3
- 이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는
SriovNetworkNodePolicy오브젝트의spec.resourceName매개변수 값입니다. - 4
- SriovNetwork 오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 추가 네트워크에 연결할 수 있습니다.
openshift-sriov-network-operator이외의 네임스페이스에 SR-IOV Network Operator를 설치할 때 이 필드를 구성해서는 안 됩니다. - 5
- 선택 사항: 추가 네트워크에 할당할 VLAN ID를 지정합니다. 기본값인
0은 추가 네트워크에 VLAN ID 태그가 없음을 의미합니다. 지원되는 VLAN ID 값은1에서4094사이입니다. - 6
- 선택사항: VF의 스푸핑 검사 모드입니다. 허용되는 값은 문자열
"on"및"off"입니다.중요SR-IOV Network Operator가 지정한 값을 따옴표로 묶거나 오브젝트를 거부해야 합니다.
- 7
- YAML 블록 스칼라로서의 IPAM CNI 플러그인의 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
- 8
- 선택사항: VF(가상 기능)의 링크 상태입니다. 허용되는 값은
enable,disable및auto입니다. - 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 주소 할당
프로세스
-
type을 whereabouts로설정합니다. 다음 예와 같이
ipRanges를 사용하여 IP 주소를 할당합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Pod에 네트워크를 연결합니다. 자세한 내용은 " 보조 네트워크에 Pod 추가"를 참조하십시오.
- 모든 IP 주소가 할당되었는지 확인합니다.
다음 명령을 실행하여 IP 주소가 메타데이터로 할당되었는지 확인합니다.
$ oc exec -it mypod -- ip a
$ oc exec -it mypod -- ip aCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.2. 네트워크 연결을 위한 IP 주소 할당 구성 링크 복사링크가 클립보드에 복사되었습니다!
보조 네트워크의 경우 DHCP(Dynamic Host Configuration Protocol) 및 고정 할당을 포함하여 다양한 할당 방법을 지원하는 IPAM(IP Address Management) CNI 플러그인을 사용하여 IP 주소를 할당할 수 있습니다.
IP 주소의 동적 할당을 담당하는 DHCP IPAM CNI 플러그인은 다음 두 가지 구성 요소로 작동합니다.
- CNI 플러그인: Kubernetes 네트워킹 스택과 통합하여 IP 주소를 요청 및 릴리스할 수 있습니다.
- DHCP IPAM CNI Daemon: IP 주소 할당 요청을 처리하기 위해 환경의 기존 DHCP 서버와 조정하는 DHCP 이벤트의 리스너입니다. 이 데몬은 DHCP 서버 자체가 아닙니다.
type: dhcp 를 IPAM 구성에 필요한 네트워크의 경우 다음을 확인합니다.
- DHCP 서버가 사용 가능하며 환경에서 실행됩니다.
- DHCP 서버는 클러스터 외부에 있으며 서버가 고객을 위한 기존 네트워크 인프라의 일부를 형성할 것으로 예상합니다.
- DHCP 서버는 노드에 IP 주소를 제공하도록 적절하게 구성됩니다.
환경에서 DHCP 서버를 사용할 수 없는 경우 대신 Whereabouts IPAM CNI 플러그인을 사용하는 것이 좋습니다. Whereabouts CNI는 외부 DHCP 서버 없이도 유사한 IP 주소 관리 기능을 제공합니다.
외부 DHCP 서버가 없거나 고정 IP 주소 관리를 선호하는 경우 Whereabouts CNI 플러그인을 사용합니다. Whereabouts 플러그인에는 오래된 IP 주소 할당을 관리하기 위한 조정기 데몬이 포함되어 있습니다.
별도의 데몬인 DHCP IPAM CNI Daemon을 포함하여 컨테이너 수명 동안 DHCP 리스를 정기적으로 갱신해야 합니다. DHCP IPAM CNI 데몬을 배포하려면 CNO(Cluster Network Operator) 구성을 변경하여 이 데몬의 배포를 보조 네트워크 설정의 일부로 트리거합니다.
3.1.2.1. 고정 IP 주소 할당 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에서는 고정 IP 주소 할당 구성에 대해 설명합니다.
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
IPAM 주소 유형입니다. |
|
|
| 가상 인터페이스에 할당할 IP 주소를 지정하는 오브젝트의 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다. |
|
|
| Pod 내부에서 구성할 경로를 지정하는 오브젝트의 배열입니다. |
|
|
| 선택 사항: DNS 구성을 지정하는 오브젝트 배열입니다. |
address 배열에는 다음 필드가 있는 오브젝트가 필요합니다.
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 |
|
|
| 송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다. |
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
CIDR 형식의 IP 주소 범위(예: 기본 경로의 경우 |
|
|
| 네트워크 트래픽을 라우팅하는 게이트웨이입니다. |
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
| DNS 쿼리가 전송되는 하나 이상의 IP 주소로 이루어진 배열입니다. |
|
|
|
호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 |
|
|
|
DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: |
고정 IP 주소 할당 구성 예
3.1.2.2. DHCP(Dynamic IP 주소) 할당 구성 링크 복사링크가 클립보드에 복사되었습니다!
pod는 생성될 때 원래 DHCP 리스를 얻습니다. 리스는 클러스터에서 실행되는 최소 DHCP 서버 배포를 통해 주기적으로 갱신되어야 합니다.
이더넷 네트워크 연결의 경우 SR-IOV Network Operator는 DHCP 서버 배포를 생성하지 않습니다. Cluster Network Operator는 최소 DHCP 서버 배포를 생성합니다.
DHCP 서버 배포를 트리거하려면 다음 예와 같이 Cluster Network Operator 구성을 편집하여 shim 네트워크 연결을 만들어야 합니다.
shim 네트워크 연결 정의 예
- 1
- 클러스터에 대한 DHCP(Dynamic IP 주소) 할당을 지정합니다.
다음 표에서는 DHCP를 사용한 동적 IP 주소 할당을 위한 구성 매개 변수에 대해 설명합니다.
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
IPAM 주소 유형입니다. |
다음 JSON 예제에서는 DHCP를 사용한 동적 IP 주소 할당을 위한 구성 p를 설명합니다.
DHCP(Dynamic IP 주소) 할당 구성 예
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
3.1.2.3. Whereabouts를 사용한 동적 IP 주소 할당 구성 링크 복사링크가 클립보드에 복사되었습니다!
Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 보조 네트워크에 동적으로 할당할 수 있습니다.
Whereabouts CNI 플러그인은 별도의 NetworkAttachmentDefinition CRD 내에서 동일한 CIDR 범위의 중복 IP 주소 범위 및 구성을 여러 번 지원합니다. 이를 통해 멀티 테넌트 환경에서 유연성 및 관리 기능이 향상됩니다.
3.1.2.3.1. 동적 IP 주소 구성 오브젝트 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에서는 Whereabouts를 사용하여 동적 IP 주소 할당을 위한 구성 오브젝트를 설명합니다.
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
IPAM 주소 유형입니다. 여기서about |
|
|
| CIDR 표기법의 IP 주소 및 범위입니다. IP 주소는 이 주소 범위 내에서 할당됩니다. |
|
|
| 선택 사항: CIDR 표기법의 0개 이상의 IP 주소 및 범위 목록입니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다. |
|
|
| 선택 사항: Pod의 각 그룹 또는 도메인이 동일한 IP 주소 범위를 공유하는 경우에도 자체 IP 주소 집합을 갖도록 합니다. 이 필드를 설정하는 것은 특히 다중 테넌트 환경에서 네트워크를 분리하고 정리하는 데 중요합니다. |
3.1.2.3.2. Whereabouts를 사용하는 동적 IP 주소 할당 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제에서는 Whereabouts를 사용하는 동적 주소 할당 구성을 보여줍니다.
Whereabouts dynamic IP address assignment
3.1.2.3.3. IP 주소 범위가 겹치는 Whereabouts를 사용하는 동적 IP 주소 할당 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제에서는 다중 테넌트 네트워크에 겹치는 IP 주소 범위를 사용하는 동적 IP 주소 할당을 보여줍니다.
NetworkAttachmentDefinition 1
- 1
- 선택 사항: 설정된 경우
NetworkAttachmentDefinition 2의network_name과 일치해야 합니다.
NetworkAttachmentDefinition 2
- 1
- 선택 사항: 설정된 경우
NetworkAttachmentDefinition 1의network_name과 일치해야 합니다.
3.2. SR-IOV 추가 네트워크 구성 링크 복사링크가 클립보드에 복사되었습니다!
SriovNetwork 오브젝트를 생성하여 SR-IOV 하드웨어를 사용하는 추가 네트워크를 구성할 수 있습니다. SriovNetwork 오브젝트를 생성하면 SR-IOV Network Operator가 NetworkAttachmentDefinition 오브젝트를 자동으로 생성합니다.
SriovNetwork 오브젝트가 running 상태의 Pod에 연결된 경우 해당 오브젝트를 수정하거나 삭제하지 마십시오.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다.
프로세스
SriovNetwork오브젝트를 생성한 다음<name>.yaml파일에 YAML을 저장합니다. 여기서<name>은 이 추가 네트워크의 이름입니다. 오브젝트 사양은 다음 예와 유사할 수 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 오브젝트를 생성하려면 다음 명령을 입력합니다:
oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 여기서
<name>은 추가 네트워크의 이름을 지정합니다.선택사항: 이전 단계에서 생성한
SriovNetwork오브젝트에 연결된NetworkAttachmentDefinition오브젝트가 존재하는지 확인하려면 다음 명령을 입력합니다.<namespace>를SriovNetwork오브젝트에 지정한 networkNamespace로 바꿉니다.oc get net-attach-def -n <namespace>
$ oc get net-attach-def -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3. SR-IOV 네트워크를 VRF에 할당 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 CNI VRF 플러그인을 사용하여 SR-IOV 네트워크 인터페이스를 VRF 도메인에 할당할 수 있습니다.
이렇게 하려면 SriovNetwork 리소스의 선택적 metaPlugins 매개변수에 VRF 구성을 추가합니다.
VRF를 사용하는 애플리케이션은 특정 장치에 바인딩해야 합니다. 일반적인 사용은 소켓에 SO_BINDTODEVICE 옵션을 사용하는 것입니다. SO_BINDTODEVICE는 소켓을 전달된 인터페이스 이름(예: eth1)에 지정된 장치에 바인딩합니다. SO_BINDTODEVICE를 사용하려면 애플리케이션에 CAP_NET_RAW 기능이 있어야 합니다.
OpenShift Container Platform Pod에서는 ip vrf exec 명령을 통해 VRF를 사용할 수 없습니다. VRF를 사용하려면 애플리케이션을 VRF 인터페이스에 직접 바인딩합니다.
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 클러스터에 로그인합니다.
프로세스
추가 SR-IOV 네트워크 연결에 대한
SriovNetworkCR(사용자 정의 리소스)을 생성하고 다음 예제 CR과 같이metaPlugins구성을 삽입합니다. YAML을sriov-network-attachment.yaml파일로 저장합니다.SriovNetworkCR(사용자 정의 리소스) 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow SriovNetwork리소스를 생성합니다.oc create -f sriov-network-attachment.yaml
$ oc create -f sriov-network-attachment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkAttachmentDefinition CR이 성공적으로 생성되었는지 확인
SR-IOV Network Operator가 다음 명령을 실행하여
NetworkAttachmentDefinitionCR을 생성했는지 확인합니다. 예상되는 출력에는 CryostatD CR의 이름과 생성 기간이 분 단위로 표시됩니다.oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<namespace>를 네트워크 연결을 구성할 때 지정한 네임스페이스(예:additional-sriov-network-1)로 바꿉니다.
참고SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.
추가 SR-IOV 네트워크 연결에 성공했는지 확인
VRF CNI가 올바르게 구성되어 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.
- VRF CNI를 사용하는 SR-IOV 네트워크를 생성합니다.
- 포드에 네트워크를 할당합니다.
Pod 네트워크 연결이 SR-IOV 추가 네트워크에 연결되어 있는지 확인합니다. 원격 쉘이 포드에 로그인했는지 확인하고 다음 명령을 실행합니다. 예상되는 출력에는 라우팅 테이블에 VRF 인터페이스의 이름과 고유 ID가 표시됩니다.
ip vrf show
$ ip vrf showCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 VRF 인터페이스가 보조 인터페이스의
마스터인지 확인합니다.ip link
$ ip linkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예:
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master UP 모드
3.4. 이더넷 기반 SR-IOV 연결을 위한 런타임 구성 링크 복사링크가 클립보드에 복사되었습니다!
추가 네트워크에 pod를 연결할 때 런타임 구성을 지정하여 pod에 대한 특정 사용자 정의를 수행할 수 있습니다. 예를 들어 특정 MAC 하드웨어 주소를 요청할 수 있습니다.
Pod 사양에서 주석을 설정하여 런타임 구성을 지정합니다. 주석 키는 k8s.v1.cni.cncf.io/networks이며 런타임 구성을 설명하는 JSON 오브젝트를 허용합니다.
이더넷 기반 SR-IOV 네트워크 연결을 위한 런타임 구성 예
- 1
- SR-IOV 네트워크 연결 정의 CR의 이름입니다. 예제 값은
ibl입니다. - 2
- 선택사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 MAC 주소입니다. 이 기능을 사용하려면
SriovNetwork오브젝트에{ "mac": true }도 지정해야 합니다. 예제 값은c2:11:22:33:44:55:66:77입니다. - 3
- 선택사항: SR-IOV 네트워크 연결 정의 CR에 정의된 리소스 유형에서 할당된 SR-IOV 장치의 IP 주소입니다. IPv4 및 IPv6 주소가 모두 지원됩니다. 이 기능을 사용하려면
SriovNetwork오브젝트에{ "ips": true }도 지정해야 합니다. 예제 값은192.168.10.1/24", "2001::1/64.
3.5. 보조 네트워크에 pod 추가 링크 복사링크가 클립보드에 복사되었습니다!
보조 네트워크에 pod를 추가할 수 있습니다. Pod는 기본 네트워크를 통해 정상적인 클러스터 관련 네트워크 트래픽을 계속 전송합니다.
Pod가 생성되면 보조 네트워크가 포드에 연결됩니다. 그러나 pod가 이미 있는 경우 보조 네트워크를 연결할 수 없습니다.
Pod는 보조 네트워크와 동일한 네임스페이스에 있어야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. - 클러스터에 로그인합니다.
프로세스
Pod오브젝트에 주석을 추가합니다. 다음 주석 형식 중 하나만 사용할 수 있습니다.사용자 정의 없이 보조 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다. &
lt;network>를 Pod와 연결할 보조 네트워크의 이름으로 바꿉니다.metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 두 개 이상의 보조 네트워크를 지정하려면 각 네트워크를 쉼표로 구분합니다. 쉼표 사이에 공백을 포함하지 마십시오. 동일한 보조 네트워크를 여러 번 지정하면 Pod에 해당 네트워크에 여러 개의 네트워크 인터페이스가 연결됩니다.
사용자 지정으로 보조 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Pod를 생성하려면 다음 명령을 입력합니다.
<name>을 Pod 이름으로 교체합니다.oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 선택사항:
PodCR에 주석이 있는지 확인하려면 다음 명령을 입력하고<name>을 Pod 이름으로 교체합니다.oc get pod <name> -o yaml
$ oc get pod <name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예에서
example-podPod는net1보조 네트워크에 연결되어 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
k8s.v1.cni.cncf.io/network-status매개변수는 JSON 오브젝트 배열입니다. 각 오브젝트는 Pod에 연결된 보조 네트워크의 상태를 설명합니다. 주석 값은 일반 텍스트 값으로 저장됩니다.
3.5.1. vfio-pci SR-IOV 장치의 MTU를 Pod에 노출 링크 복사링크가 클립보드에 복사되었습니다!
추가 네트워크에 Pod를 추가한 후 SR-IOV 네트워크에 MTU를 사용할 수 있는지 확인할 수 있습니다.
프로세스
다음 명령을 실행하여 pod 주석에 MTU가 포함되어 있는지 확인합니다.
oc describe pod example-pod
$ oc describe pod example-podCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예제에서는 샘플 출력을 보여줍니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 pod 내부의
/etc/podnetinfo/에서 MTU를 사용할 수 있는지 확인합니다.oc exec example-pod -n sriov-tests -- cat /etc/podnetinfo/annotations | grep mtu
$ oc exec example-pod -n sriov-tests -- cat /etc/podnetinfo/annotations | grep mtuCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예제에서는 샘플 출력을 보여줍니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.6. SR-IOV 네트워크 정책 업데이트 중 병렬 노드 드레이닝 구성 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 SR-IOV Network Operator는 모든 정책이 변경되기 전에 노드에서 워크로드를 드레이닝합니다. Operator는 한 번에 하나의 노드인 이 작업을 수행하여 재구성이 워크로드에 영향을 미치지 않도록 합니다.
대규모 클러스터에서 노드를 순차적으로 드레이닝하는 것은 시간이 오래 걸리는데 몇 시간 또는 며칠이 걸릴 수 있습니다. 시간에 민감한 환경에서는 SriovNetworkPoolConfig CR(사용자 정의 리소스)에서 병렬 노드를 드레이닝하여 SR-IOV 네트워크 구성을 더 빠르게 롤아웃할 수 있습니다.
병렬 드레이닝을 구성하려면 SriovNetworkPoolConfig CR을 사용하여 노드 풀을 생성합니다. 그런 다음 풀에 노드를 추가하고 Operator가 병렬로 드레이닝할 수 있는 풀의 최대 노드 수를 정의할 수 있습니다. 이 방법을 사용하면 실행 중인 워크로드를 처리할 수 있는 충분한 노드가 풀에 남아 있도록 동시에 재구성할 수 있도록 병렬 드레이닝을 활성화할 수 있습니다.
노드는 하나의 SR-IOV 네트워크 풀 구성에만 속할 수 있습니다. 노드가 풀의 일부가 아닌 경우 노드는 한 번에 하나의 노드를 드레이닝하는 구성과 함께 가상 기본 풀에 추가됩니다.
드레이닝 프로세스 중에 노드가 다시 시작될 수 있습니다.
이 절차를 수행하려면 SR-IOV 리소스를 생성한 다음 병렬로 노드를 드레이닝해야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다. - SR-IOV Network Operator 설치.
- 노드에는 SR-IOV를 지원하는 하드웨어가 있습니다.
프로세스
SriovNetworkPoolConfig리소스를 정의하는 YAML 파일을 생성합니다.sriov-nw-pool.yaml파일 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetworkPoolConfig오브젝트의 이름을 지정합니다.- 2
- SR-IOV Network Operator가 설치된 네임스페이스를 지정합니다.
- 3
- 업데이트 중에 풀에서 사용할 수 없는 노드에 대해 정수 숫자 또는 백분율 값을 지정합니다. 예를 들어 10개의 노드가 있고 사용할 수 없는 최대 노드를 2개로 설정하면 언제든지 2개의 노드만 병렬로 드레이닝되어 워크로드를 처리하기 위해 8개의 노드를 유지할 수 있습니다.
- 4
- 노드 선택기를 사용하여 풀을 추가할 노드를 지정합니다. 이 예제에서는
worker역할이 있는 모든 노드를 풀에 추가합니다.
다음 명령을 실행하여
SriovNetworkPoolConfig리소스를 생성합니다.oc create -f sriov-nw-pool.yaml
$ oc create -f sriov-nw-pool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 comand를 실행하여
sriov-test네임스페이스를 생성합니다.oc create namespace sriov-test
$ oc create namespace sriov-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow SriovNetworkNodePolicy리소스를 정의하는 YAML 파일을 생성합니다.sriov-node-policy.yaml파일의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
SriovNetworkNodePolicy리소스를 생성합니다.oc create -f sriov-node-policy.yaml
$ oc create -f sriov-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow SriovNetwork리소스를 정의하는 YAML 파일을 생성합니다.sriov-network.yaml파일 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
SriovNetwork리소스를 생성합니다.oc create -f sriov-network.yaml
$ oc create -f sriov-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 생성한 노드 풀을 확인합니다.
oc get sriovNetworkpoolConfig -n openshift-sriov-network-operator
$ oc get sriovNetworkpoolConfig -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력에는
작업자역할이 있는 모든 노드와 노드풀의 기간(예:67s)이 포함된 노드 풀의 이름이 표시됩니다.SriovNetworkNodePolicy리소스의 가상 함수 수를 업데이트하여 클러스터에서 워크로드 드레이닝을 트리거합니다.oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'$ oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 대상 클러스터에서 드레이닝 상태를 확인합니다.
oc get sriovNetworkNodeState -n openshift-sriov-network-operator
$ oc get sriovNetworkNodeState -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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 3d10hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 드레이닝 프로세스가 완료되면
SYNC STATUS가Succeeded로 변경되고DESIRED SYNC STATE및CURRENT 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가 설치되어 있습니다.
프로세스
SriovNetworkNodePolicyCR을 생성합니다.다음 YAML을
sriov-network-node-policy.yaml파일에 저장하고 YAML의 값을 해당 환경과 일치하도록 교체합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고많은
SriovNetworkNodePolicy리소스가 SR-IOV 네트워크 리소스를 대상으로 하는 경우SriovNetworkNodePolicy리소스에excludeTopology사양과 동일한 값이 있어야 합니다. 그러지 않으면 충돌하는 정책이 거부됩니다.다음 명령을 실행하여
SriovNetworkNodePolicy리소스를 생성합니다. 성공적인 출력에는SriovNetworkNodePolicy리소스의 이름과생성된상태가 나열됩니다.oc create -f sriov-network-node-policy.yaml
$ oc create -f sriov-network-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SriovNetworkCR을 생성합니다.다음 YAML을
sriov-network.yaml파일에 저장하고 YAML의 값을 해당 환경과 일치하도록 교체합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
SriovNetwork리소스를 생성합니다. 성공적인 출력에는SriovNetwork리소스의 이름과생성된상태가 나열됩니다.oc create -f sriov-network.yaml
$ oc create -f sriov-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Pod를 생성하고 이전 단계의 SR-IOV 네트워크 리소스를 할당합니다.
다음 YAML을
sriov-network-pod.yaml파일에 저장하고 YAML의 값을 해당 환경과 일치하도록 교체합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetworkNodePolicy리소스를 사용하는SriovNetwork리소스의 이름입니다.
다음 명령을 실행하여
Pod리소스를 생성합니다. 예상되는 출력에는Pod리소스의 이름과생성된상태가 표시됩니다.oc create -f sriov-network-pod.yaml
$ oc create -f sriov-network-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 Pod의 상태를 확인하고 <
pod_name>을 Pod 이름으로 교체합니다.oc get pod <pod_name>
$ oc get pod <pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE test-deployment-sriov-76cbbf4756-k9v72 1/1 Running 0 45h
NAME READY STATUS RESTARTS AGE test-deployment-sriov-76cbbf4756-k9v72 1/1 Running 0 45hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 대상 Pod로 디버그 세션을 열어 SR-IOV 네트워크 리소스가 메모리 및 CPU 리소스와 다른 노드에 배포되었는지 확인합니다.
다음 명령을 실행하여 Pod로 디버그 세션을 열고 <pod_name>을 대상 Pod 이름으로 교체합니다.
oc debug pod/<pod_name>
$ oc debug pod/<pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 디버그 쉘 내에서
/host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의/host에 호스트의 root 파일 시스템을 마운트합니다. root 디렉토리를/host로 변경하면 호스트 파일 시스템에서 바이너리를 실행할 수 있습니다.chroot /host
$ chroot /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 CPU 할당에 대한 정보를 확인합니다.
lscpu | grep NUMA
$ lscpu | grep NUMACopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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,...
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 Copied! Toggle word wrap Toggle overflow cat /proc/self/status | grep Cpus
$ cat /proc/self/status | grep CpusCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Cpus_allowed: ffff Cpus_allowed_list: 1,3,5,7
Cpus_allowed: ffff Cpus_allowed_list: 1,3,5,7Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상되는 출력에는
NUMAnode1과 같은NUMA노드에 할당되는 CPU(1, 3, 5 및 7)가 표시됩니다. SR-IOV 네트워크 리소스는NUMA node0과 같은 다른NUMA노드의 NIC를 사용할 수 있습니다.ffff16진수 값은 프로세스를 실행하는 CPU 코어를 나타냅니다.cat /sys/class/net/net1/device/numa_node
$ cat /sys/class/net/net1/device/numa_nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력에는
NUMA노드의 수(예:0)가 표시됩니다.참고excludeTopology사양을True로 설정하면 필요한 리소스가 동일한 NUMA 노드에 존재할 수 있습니다.
4장. SR-IOV InfiniBand 네트워크 연결 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치에 대한 IB(InfiniBand) 네트워크 연결을 구성할 수 있습니다.
다음 문서에서 작업을 수행하기 전에 SR-IOV Network Operator를 설치 했는지 확인합니다.
4.1. InfiniBand 장치 구성 오브젝트 링크 복사링크가 클립보드에 복사되었습니다!
SriovIBNetwork 오브젝트를 정의하여 IB(InfiniBand) 네트워크 장치를 구성할 수 있습니다.
다음 YAML은 SriovIBNetwork 오브젝트를 설명합니다.
- 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 주소 할당
프로세스
-
type을 whereabouts로설정합니다. 다음 예와 같이
ipRanges를 사용하여 IP 주소를 할당합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Pod에 네트워크를 연결합니다. 자세한 내용은 " 보조 네트워크에 Pod 추가"를 참조하십시오.
- 모든 IP 주소가 할당되었는지 확인합니다.
다음 명령을 실행하여 IP 주소가 메타데이터로 할당되었는지 확인합니다.
$ oc exec -it mypod -- ip a
$ oc exec -it mypod -- ip aCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.2. 네트워크 연결을 위한 IP 주소 할당 구성 링크 복사링크가 클립보드에 복사되었습니다!
보조 네트워크의 경우 DHCP(Dynamic Host Configuration Protocol) 및 고정 할당을 포함하여 다양한 할당 방법을 지원하는 IPAM(IP Address Management) CNI 플러그인을 사용하여 IP 주소를 할당할 수 있습니다.
IP 주소의 동적 할당을 담당하는 DHCP IPAM CNI 플러그인은 다음 두 가지 구성 요소로 작동합니다.
- CNI 플러그인: Kubernetes 네트워킹 스택과 통합하여 IP 주소를 요청 및 릴리스할 수 있습니다.
- DHCP IPAM CNI Daemon: IP 주소 할당 요청을 처리하기 위해 환경의 기존 DHCP 서버와 조정하는 DHCP 이벤트의 리스너입니다. 이 데몬은 DHCP 서버 자체가 아닙니다.
type: dhcp 를 IPAM 구성에 필요한 네트워크의 경우 다음을 확인합니다.
- DHCP 서버가 사용 가능하며 환경에서 실행됩니다.
- DHCP 서버는 클러스터 외부에 있으며 서버가 고객을 위한 기존 네트워크 인프라의 일부를 형성할 것으로 예상합니다.
- DHCP 서버는 노드에 IP 주소를 제공하도록 적절하게 구성됩니다.
환경에서 DHCP 서버를 사용할 수 없는 경우 대신 Whereabouts IPAM CNI 플러그인을 사용하는 것이 좋습니다. Whereabouts CNI는 외부 DHCP 서버 없이도 유사한 IP 주소 관리 기능을 제공합니다.
외부 DHCP 서버가 없거나 고정 IP 주소 관리를 선호하는 경우 Whereabouts CNI 플러그인을 사용합니다. Whereabouts 플러그인에는 오래된 IP 주소 할당을 관리하기 위한 조정기 데몬이 포함되어 있습니다.
별도의 데몬인 DHCP IPAM CNI Daemon을 포함하여 컨테이너 수명 동안 DHCP 리스를 정기적으로 갱신해야 합니다. DHCP IPAM CNI 데몬을 배포하려면 CNO(Cluster Network Operator) 구성을 변경하여 이 데몬의 배포를 보조 네트워크 설정의 일부로 트리거합니다.
4.1.2.1. 고정 IP 주소 할당 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에서는 고정 IP 주소 할당 구성에 대해 설명합니다.
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
IPAM 주소 유형입니다. |
|
|
| 가상 인터페이스에 할당할 IP 주소를 지정하는 오브젝트의 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다. |
|
|
| Pod 내부에서 구성할 경로를 지정하는 오브젝트의 배열입니다. |
|
|
| 선택 사항: DNS 구성을 지정하는 오브젝트 배열입니다. |
address 배열에는 다음 필드가 있는 오브젝트가 필요합니다.
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 |
|
|
| 송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다. |
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
CIDR 형식의 IP 주소 범위(예: 기본 경로의 경우 |
|
|
| 네트워크 트래픽을 라우팅하는 게이트웨이입니다. |
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
| DNS 쿼리가 전송되는 하나 이상의 IP 주소로 이루어진 배열입니다. |
|
|
|
호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 |
|
|
|
DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: |
고정 IP 주소 할당 구성 예
4.1.2.2. DHCP(Dynamic IP 주소) 할당 구성 링크 복사링크가 클립보드에 복사되었습니다!
pod는 생성될 때 원래 DHCP 리스를 얻습니다. 리스는 클러스터에서 실행되는 최소 DHCP 서버 배포를 통해 주기적으로 갱신되어야 합니다.
이더넷 네트워크 연결의 경우 SR-IOV Network Operator는 DHCP 서버 배포를 생성하지 않습니다. Cluster Network Operator는 최소 DHCP 서버 배포를 생성합니다.
DHCP 서버 배포를 트리거하려면 다음 예와 같이 Cluster Network Operator 구성을 편집하여 shim 네트워크 연결을 만들어야 합니다.
shim 네트워크 연결 정의 예
- 1
- 클러스터에 대한 DHCP(Dynamic IP 주소) 할당을 지정합니다.
다음 표에서는 DHCP를 사용한 동적 IP 주소 할당을 위한 구성 매개 변수에 대해 설명합니다.
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
IPAM 주소 유형입니다. |
다음 JSON 예제에서는 DHCP를 사용한 동적 IP 주소 할당을 위한 구성 p를 설명합니다.
DHCP(Dynamic IP 주소) 할당 구성 예
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
4.1.2.3. Whereabouts를 사용한 동적 IP 주소 할당 구성 링크 복사링크가 클립보드에 복사되었습니다!
Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 보조 네트워크에 동적으로 할당할 수 있습니다.
Whereabouts CNI 플러그인은 별도의 NetworkAttachmentDefinition CRD 내에서 동일한 CIDR 범위의 중복 IP 주소 범위 및 구성을 여러 번 지원합니다. 이를 통해 멀티 테넌트 환경에서 유연성 및 관리 기능이 향상됩니다.
4.1.2.3.1. 동적 IP 주소 구성 오브젝트 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에서는 Whereabouts를 사용하여 동적 IP 주소 할당을 위한 구성 오브젝트를 설명합니다.
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
IPAM 주소 유형입니다. 여기서about |
|
|
| CIDR 표기법의 IP 주소 및 범위입니다. IP 주소는 이 주소 범위 내에서 할당됩니다. |
|
|
| 선택 사항: CIDR 표기법의 0개 이상의 IP 주소 및 범위 목록입니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다. |
|
|
| 선택 사항: Pod의 각 그룹 또는 도메인이 동일한 IP 주소 범위를 공유하는 경우에도 자체 IP 주소 집합을 갖도록 합니다. 이 필드를 설정하는 것은 특히 다중 테넌트 환경에서 네트워크를 분리하고 정리하는 데 중요합니다. |
4.1.2.3.2. Whereabouts를 사용하는 동적 IP 주소 할당 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제에서는 Whereabouts를 사용하는 동적 주소 할당 구성을 보여줍니다.
Whereabouts dynamic IP address assignment
4.1.2.3.3. IP 주소 범위가 겹치는 Whereabouts를 사용하는 동적 IP 주소 할당 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제에서는 다중 테넌트 네트워크에 겹치는 IP 주소 범위를 사용하는 동적 IP 주소 할당을 보여줍니다.
NetworkAttachmentDefinition 1
- 1
- 선택 사항: 설정된 경우
NetworkAttachmentDefinition 2의network_name과 일치해야 합니다.
NetworkAttachmentDefinition 2
- 1
- 선택 사항: 설정된 경우
NetworkAttachmentDefinition 1의network_name과 일치해야 합니다.
4.2. SR-IOV 추가 네트워크 구성 링크 복사링크가 클립보드에 복사되었습니다!
SriovIBNetwork 오브젝트를 생성하여 SR-IOV 하드웨어를 사용하는 추가 네트워크를 구성할 수 있습니다. SriovIBNetwork 오브젝트를 생성하면 SR-IOV Network Operator가 NetworkAttachmentDefinition 오브젝트를 자동으로 생성합니다.
SriovIBNetwork 오브젝트가 running 상태의 Pod에 연결된 경우 수정하거나 삭제하지 마십시오.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다.
프로세스
SriovIBNetwork오브젝트를 생성한 다음<name>.yaml파일에 YAML을 저장합니다. 여기서<name>은 이 추가 네트워크의 이름입니다. 오브젝트 사양은 다음 예와 유사할 수 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 오브젝트를 생성하려면 다음 명령을 입력합니다:
oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 여기서
<name>은 추가 네트워크의 이름을 지정합니다.선택 사항: 이전 단계에서 생성한
SriovIBNetwork오브젝트에 연결된NetworkAttachmentDefinition오브젝트가 존재하는지 확인하려면 다음 명령을 입력합니다.<namespace>를SriovIBNetwork오브젝트에 지정한 networkNamespace로 바꿉니다.oc get net-attach-def -n <namespace>
$ oc get net-attach-def -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3. InfiniBand 기반 SR-IOV 연결을 위한 런타임 구성 링크 복사링크가 클립보드에 복사되었습니다!
추가 네트워크에 pod를 연결할 때 런타임 구성을 지정하여 pod에 대한 특정 사용자 정의를 수행할 수 있습니다. 예를 들어 특정 MAC 하드웨어 주소를 요청할 수 있습니다.
Pod 사양에서 주석을 설정하여 런타임 구성을 지정합니다. 주석 키는 k8s.v1.cni.cncf.io/networks이며 런타임 구성을 설명하는 JSON 오브젝트를 허용합니다.
다음 JSON은 InfiniBand 기반 SR-IOV 네트워크 연결에 대한 런타임 구성 옵션을 설명합니다.
런타임 구성 예
4.4. 보조 네트워크에 pod 추가 링크 복사링크가 클립보드에 복사되었습니다!
보조 네트워크에 pod를 추가할 수 있습니다. Pod는 기본 네트워크를 통해 정상적인 클러스터 관련 네트워크 트래픽을 계속 전송합니다.
Pod가 생성되면 보조 네트워크가 포드에 연결됩니다. 그러나 pod가 이미 있는 경우 보조 네트워크를 연결할 수 없습니다.
Pod는 보조 네트워크와 동일한 네임스페이스에 있어야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. - 클러스터에 로그인합니다.
프로세스
Pod오브젝트에 주석을 추가합니다. 다음 주석 형식 중 하나만 사용할 수 있습니다.사용자 정의 없이 보조 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다. &
lt;network>를 Pod와 연결할 보조 네트워크의 이름으로 바꿉니다.metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 두 개 이상의 보조 네트워크를 지정하려면 각 네트워크를 쉼표로 구분합니다. 쉼표 사이에 공백을 포함하지 마십시오. 동일한 보조 네트워크를 여러 번 지정하면 Pod에 해당 네트워크에 여러 개의 네트워크 인터페이스가 연결됩니다.
사용자 지정으로 보조 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Pod를 생성하려면 다음 명령을 입력합니다.
<name>을 Pod 이름으로 교체합니다.oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 선택사항:
PodCR에 주석이 있는지 확인하려면 다음 명령을 입력하고<name>을 Pod 이름으로 교체합니다.oc get pod <name> -o yaml
$ oc get pod <name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예에서
example-podPod는net1보조 네트워크에 연결되어 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
k8s.v1.cni.cncf.io/network-status매개변수는 JSON 오브젝트 배열입니다. 각 오브젝트는 Pod에 연결된 보조 네트워크의 상태를 설명합니다. 주석 값은 일반 텍스트 값으로 저장됩니다.
4.4.1. vfio-pci SR-IOV 장치의 MTU를 Pod에 노출 링크 복사링크가 클립보드에 복사되었습니다!
추가 네트워크에 Pod를 추가한 후 SR-IOV 네트워크에 MTU를 사용할 수 있는지 확인할 수 있습니다.
프로세스
다음 명령을 실행하여 pod 주석에 MTU가 포함되어 있는지 확인합니다.
oc describe pod example-pod
$ oc describe pod example-podCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예제에서는 샘플 출력을 보여줍니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 pod 내부의
/etc/podnetinfo/에서 MTU를 사용할 수 있는지 확인합니다.oc exec example-pod -n sriov-tests -- cat /etc/podnetinfo/annotations | grep mtu
$ oc exec example-pod -n sriov-tests -- cat /etc/podnetinfo/annotations | grep mtuCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예제에서는 샘플 출력을 보여줍니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5장. SR-IOV 네트워크의 인터페이스 수준 네트워크 sysctl 설정 및 모든 멀티 캐스트 모드 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 SR-IOV 네트워크 장치에 연결된 Pod에 대한 CNI(Container Network Interface) 메타 플러그인을 사용하여 인터페이스 수준 네트워크 sysctl 및 무차별 모드, all-multicast 모드, MTU 및 MAC 주소와 같은 여러 인터페이스 속성을 변경할 수 있습니다.
다음 문서에서 작업을 수행하기 전에 SR-IOV Network Operator를 설치 했는지 확인합니다.
5.1. SR-IOV가 활성화된 NIC를 사용하여 노드에 레이블 지정 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV 가능 노드에서만 SR-IOV를 활성화하려면 이 작업을 수행하는 몇 가지 방법이 있습니다.
-
NFD(Node Feature Discovery) Operator를 설치합니다. NFD는 SR-IOV가 활성화된 NIC의 존재를 감지하고
node.alpha.kubernetes-incubator.io/nfd-network-sriov.enabled = true로 노드에 레이블을 지정합니다. 각 노드에 대해
SriovNetworkNodeStateCR을 검사합니다.interfaces스탠자에는 작업자 노드에서 SR-IOV Network Operator가 검색한 모든 SR-IOV 장치 목록이 포함됩니다. 다음 명령을 사용하여 각 노드에feature.node.kubernetes.io/network-sriov.able: "true"로 레이블을 지정합니다.$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고원하는 이름으로 노드에 레이블을 지정할 수 있습니다.
5.2. sysctl 플래그 1개 설정 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV 네트워크 장치에 연결된 Pod의 인터페이스 수준 네트워크 sysctl 설정을 설정할 수 있습니다.
이 예에서는 생성된 가상 인터페이스에서 net.ipv4.conf.IFNAME.accept_redirects 가 1 로 설정됩니다.
sysctl-tuning-test 는 이 예제에서 사용되는 네임스페이스입니다.
다음 명령을 사용하여
sysctl-tuning-test네임스페이스를 생성합니다.oc create namespace sysctl-tuning-test
$ oc create namespace sysctl-tuning-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.1. SR-IOV 네트워크 장치를 사용하여 노드에서 하나의 sysctl 플래그 설정 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV Network Operator는 SriovNetworkNodePolicy.sriovnetwork.openshift.io CRD(사용자 정의 리소스 정의)를 OpenShift Container Platform에 추가합니다. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성하여 SR-IOV 네트워크 장치를 구성할 수 있습니다.
SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 재부팅할 수 있습니다.
구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.
SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성하려면 다음 절차를 따르십시오.
프로세스
SriovNetworkNodePolicyCR(사용자 정의 리소스)을 생성합니다. 예를 들어 다음 YAML을policyoneflag-sriov-node-network.yaml파일로 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 수는
127보다 클 수 없습니다. - 7
- NIC 선택기는 Operator가 구성할 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다.
rootDevices를 지정하면vendor,deviceID또는pfNames의 값도 지정해야 합니다.pfNames와rootDevices를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오.netFilter의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다. - 8
- 선택사항: 장치에 대해 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.
- 9
- 선택사항: 가상 기능의 드라이버 유형입니다. 허용되는 값은
netdevice입니다. 베어 메탈 노드의 DPDK 모드에서 Mellanox NIC가 작동하려면isRdma를true로 설정합니다. - 10
- 선택 사항: 원격 직접 메모리 액세스(RDMA) 모드를 활성화할지 여부를 구성합니다. 기본값은
false입니다.isRdma매개변수가true로 설정된 경우 RDMA 사용 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다.isRdma를true로 설정하고 추가로needVhostNet을true로 설정하여 Fast Datapath DPDK 애플리케이션에서 사용할 Mellanox NIC를 구성합니다.
참고vfio-pci드라이버 유형은 지원되지 않습니다.SriovNetworkNodePolicy오브젝트를 생성합니다.oc create -f policyoneflag-sriov-node-network.yaml
$ oc create -f policyoneflag-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 구성 업데이트를 적용하면
sriov-network-operator네임스페이스의 모든 Pod가Running상태로 변경됩니다.SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다.
<node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다. 예상 출력은성공으로표시됩니다.oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.2. SR-IOV 네트워크에서 sysctl 구성 링크 복사링크가 클립보드에 복사되었습니다!
SriovNetwork 리소스의 선택적 metaPlugins 매개변수에 튜닝 구성을 추가하여 SR-IOV에서 생성된 가상 인터페이스에 인터페이스별 sysctl 설정을 설정할 수 있습니다.
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(Container Network Interface) 튜닝 플러그인을 사용하여 추가 SR-IOV 네트워크를 생성합니다.
사전 요구 사항
- OpenShift Container Platform CLI, oc를 설치합니다.
- cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.
프로세스
추가 SR-IOV 네트워크 연결에 대한
SriovNetworkCR(사용자 정의 리소스)을 생성하고 다음 예제 CR과 같이metaPlugins구성을 삽입합니다. YAML을sriov-network-interface-sysctl.yaml파일로 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 오브젝트의 이름입니다. SR-IOV Network Operator는 동일한 이름으로 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 매개변수는 장치에 기능을 추가하는 데 사용됩니다. 이 사용 사례에서
type필드를튜닝으로 설정합니다. sysctl 필드에 설정할 인터페이스 수준 네트워크을 지정합니다.sysctl
SriovNetwork리소스를 생성합니다.oc create -f sriov-network-interface-sysctl.yaml
$ oc create -f sriov-network-interface-sysctl.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkAttachmentDefinition CR이 성공적으로 생성되었는지 확인
SR-IOV Network Operator가 다음 명령을 실행하여
NetworkAttachmentDefinitionCR을 생성했는지 확인합니다.oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;namespace>를SriovNetwork오브젝트에 지정한networkNamespace값으로 바꿉니다. 예를 들면sysctl-tuning-test입니다. 예상되는 출력에는 CryostatD CRD의 이름과 생성 기간이 분 단위로 표시됩니다.
참고SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.
추가 SR-IOV 네트워크 연결에 성공했는지 확인
튜닝 CNI가 올바르게 구성되어 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.
PodCR을 생성합니다. 다음 YAML을examplepod.yaml파일로 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 }도 지정해야 합니다.
PodCR을 생성합니다.oc apply -f examplepod.yaml
$ oc apply -f examplepod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Pod가 생성되었는지 확인합니다.
oc get pod -n sysctl-tuning-test
$ oc get pod -n sysctl-tuning-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47s
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Pod에 로그인합니다.
oc rsh -n sysctl-tuning-test tunepod
$ oc rsh -n sysctl-tuning-test tunepodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 구성된 sysctl 플래그의 값을 확인합니다. 다음 명령을 실행하여
net.ipv4.conf.IFNAME.accept_redirects값을 찾습니다.sysctl net.ipv4.conf.net1.accept_redirects
$ sysctl net.ipv4.conf.net1.accept_redirectsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. 본딩된 SR-IOV 인터페이스 플래그와 연결된 Pod의 sysctl 설정 구성 링크 복사링크가 클립보드에 복사되었습니다!
본딩된 SR-IOV 네트워크 장치에 연결된 Pod의 인터페이스 수준 네트워크 sysctl 설정을 설정할 수 있습니다.
이 예제에서 구성할 수 있는 특정 네트워크 인터페이스 수준 sysctl 설정은 본딩된 인터페이스에 설정됩니다.
sysctl-tuning-test 는 이 예제에서 사용되는 네임스페이스입니다.
다음 명령을 사용하여
sysctl-tuning-test네임스페이스를 생성합니다.oc create namespace sysctl-tuning-test
$ oc create namespace sysctl-tuning-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.1. 본딩된 SR-IOV 네트워크 장치를 사용하여 노드에서 모든 sysctl 플래그 설정 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV Network Operator는 SriovNetworkNodePolicy.sriovnetwork.openshift.io CRD(사용자 정의 리소스 정의)를 OpenShift Container Platform에 추가합니다. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성하여 SR-IOV 네트워크 장치를 구성할 수 있습니다.
SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator에서 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다.
구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.
SriovNetworkNodePolicy CR(사용자 정의 리소스)을 생성하려면 다음 절차를 따르십시오.
프로세스
SriovNetworkNodePolicyCR(사용자 정의 리소스)을 생성합니다. 다음 YAML을policyallflags-sriov-node-network.yaml로 저장합니다.policyallflags를 구성 이름으로 교체합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 수는
127보다 클 수 없습니다. - 7
- NIC 선택기는 Operator가 구성할 장치를 식별합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 실수로 장치를 선택하지 않도록 네트워크 장치를 정확하게 파악하는 것이 좋습니다.
rootDevices를 지정하면vendor,deviceID또는pfNames의 값도 지정해야 합니다.pfNames와rootDevices를 동시에 지정하는 경우 동일한 장치를 참조하는지 확인하십시오.netFilter의 값을 지정하는 경우 네트워크 ID가 고유하므로 다른 매개변수를 지정할 필요가 없습니다. - 8
- 선택사항: 장치에 대해 하나 이상의 물리적 기능(PF) 이름으로 구성된 배열입니다.
- 9
- 선택사항: 가상 기능의 드라이버 유형입니다. 허용되는 값은
netdevice입니다. 베어 메탈 노드의 DPDK 모드에서 Mellanox NIC가 작동하려면isRdma를true로 설정합니다. - 10
- 선택 사항: 원격 직접 메모리 액세스(RDMA) 모드를 활성화할지 여부를 구성합니다. 기본값은
false입니다.isRdma매개변수가true로 설정된 경우 RDMA 사용 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다.isRdma를true로 설정하고 추가로needVhostNet을true로 설정하여 Fast Datapath DPDK 애플리케이션에서 사용할 Mellanox NIC를 구성합니다.
참고vfio-pci드라이버 유형은 지원되지 않습니다.SriovNetworkNodePolicy 오브젝트를 생성합니다.
oc create -f policyallflags-sriov-node-network.yaml
$ oc create -f policyallflags-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 구성 업데이트를 적용하면 sriov-network-operator 네임스페이스의 모든 Pod가
Running상태로 변경됩니다.SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다.
<node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다. 예상 출력에 성공이 표시됩니다.oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.2. 결합된 SR-IOV 네트워크에서 sysctl 구성 링크 복사링크가 클립보드에 복사되었습니다!
두 SR-IOV 인터페이스에서 생성된 본딩된 인터페이스에서 인터페이스별 sysctl 설정을 설정할 수 있습니다. 본딩 네트워크 연결 정의의 선택적 Plugins 매개변수에 튜닝 구성을 추가하여 이 작업을 수행합니다.
SR-IOV Network Operator가 관리하는 NetworkAttachmentDefinition 사용자 정의 리소스를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.
특정 인터페이스 수준 네트워크 sysctl 설정을 변경하려면 다음 절차를 사용하여 컨테이너 네트워크 인터페이스(CNI) 튜닝 플러그인으로 SriovNetwork CR(사용자 정의 리소스)을 생성합니다.
사전 요구 사항
- OpenShift Container Platform CLI, oc를 설치합니다.
- cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.
프로세스
다음 예제 CR과 같이 본딩된 인터페이스에 대한
SriovNetworkCR(사용자 정의 리소스)을 생성합니다. YAML을sriov-network-attachment.yaml파일로 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 오브젝트의 이름입니다. SR-IOV Network Operator는 동일한 이름으로 NetworkAttachmentDefinition 오브젝트를 생성합니다.
- 2
- SR-IOV Network Operator가 설치된 네임스페이스입니다.
- 3
- 이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는
SriovNetworkNodePolicy오브젝트의spec.resourceName매개변수 값입니다. - 4
SriovNetwork오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 추가 네트워크에 연결할 수 있습니다.- 5
- 선택사항: 이 추가 네트워크에 구성할 수 있는 기능입니다.
"{"ips": true}"를 지정하여 IP 주소 지원을 활성화하거나"{"mac":true}"를 지정하여 MAC 주소 지원을 활성화할 수 있습니다.
SriovNetwork리소스를 생성합니다.oc create -f sriov-network-attachment.yaml
$ oc create -f sriov-network-attachment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예제 CR과 같이 본딩 네트워크 연결 정의를 생성합니다. YAML을
sriov-bond-network-interface.yaml파일로 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 유형은
본딩입니다. - 2
mode속성은 본딩 모드를 지정합니다. 지원되는 본딩 모드는 다음과 같습니다.-
balance-rr- 0 -
active-backup- 1 balance-xor- 2balance-rr또는balance-xor모드의 경우 SR-IOV 가상 기능에 대해신뢰모드를on으로 설정해야 합니다.
-
- 3
- active-backup 모드에서는
페일오버속성이 필요합니다. - 4
linksInContainer=true플래그는 Bond CNI에 컨테이너 내에서 필요한 인터페이스를 찾을 수 있음을 알립니다. 기본적으로 Bond CNI는 SRIOV 및 Multus와의 통합에 작동하지 않는 호스트에서 이러한 인터페이스를 찾습니다.- 5
links섹션에서는 본딩을 만드는 데 사용할 인터페이스를 정의합니다. 기본적으로 Multus는 연결된 인터페이스의 이름을 "net" 및 연속 번호(한 개부터 시작하여)로 지정합니다.- 6
- YAML 블록 스칼라로서의 IPAM CNI 플러그인의 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다. 이 Pod 예제 IP 주소는 수동으로 구성되므로 이 경우
ipam은 static으로 설정됩니다. - 7
- 장치에 기능을 추가합니다. 예를 들어
type필드를튜닝으로 설정합니다. sysctl 필드에 설정할 인터페이스 수준 네트워크sysctl을 지정합니다. 이 예제에서는 설정할 수 있는 모든 인터페이스 수준 네트워크sysctl설정을 설정합니다.
본딩 네트워크 연결 리소스를 생성합니다.
oc create -f sriov-bond-network-interface.yaml
$ oc create -f sriov-bond-network-interface.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkAttachmentDefinition CR이 성공적으로 생성되었는지 확인
SR-IOV Network Operator가 다음 명령을 실행하여
NetworkAttachmentDefinitionCR을 생성했는지 확인합니다.oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;namespace>를 네트워크 연결을 구성할 때 지정한 networkNamespace로 바꿉니다(예:sysctl-tuning-test). 예상 출력은 CryostatD CRD의 이름과 생성 기간을 분 단위로 표시합니다.
참고SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.
추가 SR-IOV 네트워크 리소스에 성공했는지 확인
튜닝 CNI가 올바르게 구성되어 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.
PodCR을 생성합니다. 예를 들어 다음 YAML을examplepod.yaml파일로 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 }도 지정해야 합니다.
YAML을 적용합니다.
oc apply -f examplepod.yaml
$ oc apply -f examplepod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Pod가 생성되었는지 확인합니다.
oc get pod -n sysctl-tuning-test
$ oc get pod -n sysctl-tuning-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47s
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Pod에 로그인합니다.
oc rsh -n sysctl-tuning-test tunepod
$ oc rsh -n sysctl-tuning-test tunepodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 구성된
sysctl플래그의 값을 확인합니다. 다음 명령을 실행하여net.ipv6.neigh.IFNAME.base_reachable_time_ms값을 찾습니다.sysctl net.ipv6.neigh.bond0.base_reachable_time_ms
$ sysctl net.ipv6.neigh.bond0.base_reachable_time_msCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4. all-multicast 모드 정보 링크 복사링크가 클립보드에 복사되었습니다!
특히 rootless 애플리케이션 컨텍스트에서 모든 멀티 캐스트 모드를 활성화하는 것이 중요합니다. 이 모드를 활성화하지 않으면 Pod의 SCC(보안 컨텍스트 제약 조건)에 NET_ADMIN 기능을 부여해야 합니다. NET_ADMIN 기능을 허용하여 Pod 권한을 부여하여 특정 요구 사항을 초과하는 변경을 수행할 수 있는 경우 보안 취약점을 잠재적으로 노출할 수 있습니다.
튜닝 CNI 플러그인은 all-multicast 모드를 포함하여 여러 인터페이스 속성 변경을 지원합니다. 이 모드를 활성화하면 SR-IOV 네트워크 장치에서 구성된 VF(가상 기능)에서 실행되는 애플리케이션에서 동일한 물리적 기능에 연결된 다른 VF의 애플리케이션에서 멀티 캐스트 트래픽을 수신하도록 허용할 수 있습니다.
5.4.1. SR-IOV 네트워크에서 all-multicast 모드 활성화 링크 복사링크가 클립보드에 복사되었습니다!
다음을 통해 SR-IOV 인터페이스에서 all-multicast 모드를 활성화할 수 있습니다.
-
SriovNetwork리소스의metaPlugins매개변수에 튜닝 구성 추가 튜닝 구성에서
allmulti필드를true로 설정참고신뢰가 활성화된 VF(가상 기능)를 생성해야 합니다.
SR-IOV Network Operator는 추가 네트워크 정의를 관리합니다. 생성할 추가 SR-IOV 네트워크를 지정하면 SR-IOV Network Operator가 NetworkAttachmentDefinition CR(사용자 정의 리소스)을 자동으로 생성합니다.
SR-IOV Network Operator가 관리하는 NetworkAttachmentDefinition 사용자 정의 리소스를 편집하지 마십시오. 편집하면 추가 네트워크의 네트워크 트래픽이 중단될 수 있습니다.
이 지침에 따라 SR-IOV 네트워크에서 all-multicast 모드를 활성화합니다.
사전 요구 사항
- OpenShift Container Platform CLI(oc)가 설치되어 있습니다.
-
cluster-admin권한이 있는 사용자로 OpenShift Container Platform 클러스터에 로그인되어 있습니다. - SR-IOV Network Operator가 설치되어 있습니다.
-
적절한
SriovNetworkNodePolicy오브젝트를 구성했습니다.
프로세스
Mellanox ConnectX-5 장치에 대한
SriovNetworkNodePolicy오브젝트를 정의하는 다음 설정으로 YAML 파일을 생성합니다. YAML 파일을sriovnetpolicy-mlx.yaml로 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
선택 사항: SR-IOV 가능 클러스터 노드에 레이블이 지정되지 않은 경우
SriovNetworkNodePolicy.Spec.NodeSelector라벨을 추가합니다. 노드 레이블 지정에 대한 자세한 내용은 "노드에서 라벨을 업데이트하는 방법 이해"를 참조하십시오. 다음 명령을 실행하여
SriovNetworkNodePolicy오브젝트를 생성합니다.oc create -f sriovnetpolicy-mlx.yaml
$ oc create -f sriovnetpolicy-mlx.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 구성 업데이트를 적용하면
sriov-network-operator네임스페이스의 모든 Pod가Running상태로 자동으로 이동합니다.다음 명령을 실행하여
enable-allmulti-test네임스페이스를 생성합니다.oc create namespace enable-allmulti-test
$ oc create namespace enable-allmulti-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 추가 SR-IOV 네트워크 연결에 대한
SriovNetworkCR(사용자 정의 리소스)을 생성하고 다음 예제 CR YAML과 같이metaPlugins구성을 삽입하고 파일을sriov-enable-all-multicast.yaml로 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 오브젝트의 이름을 지정합니다. SR-IOV Network Operator는 동일한 이름으로
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
- 가상 기능의 신뢰 모드를 지정합니다. 이 값을 "on"으로 설정해야 합니다.
- 8
metaPlugins매개변수를 사용하여 장치에 더 많은 기능을 추가합니다. 이 사용 사례에서type필드를조정하도록 설정하고allmulti필드를 추가하고true로 설정합니다.
다음 명령을 실행하여
SriovNetwork리소스를 생성합니다.oc create -f sriov-enable-all-multicast.yaml
$ oc create -f sriov-enable-all-multicast.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkAttachmentDefinition CR 확인
SR-IOV Network Operator가 다음 명령을 실행하여
NetworkAttachmentDefinitionCR을 생성했는지 확인합니다.oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;namespace>를SriovNetwork오브젝트에 지정한networkNamespace값으로 바꿉니다. 이 예제에서는enable-allmulti-test입니다. 예상되는 출력에는 CryostatD CR의 이름과 생성 기간이 분 단위로 표시됩니다.
참고SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.
다음 명령을 실행하여 SR-IOV 네트워크 리소스에 대한 정보를 표시합니다.
oc get sriovnetwork -n openshift-sriov-network-operator
$ oc get sriovnetwork -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
추가 SR-IOV 네트워크 연결 확인
튜닝 CNI가 올바르게 구성되어 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음 단계를 따르십시오.
PodCR을 생성합니다. 다음 샘플 YAML을examplepod.yaml이라는 파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 }도 지정해야 합니다.
다음 명령을 실행하여
PodCR을 생성합니다.oc apply -f examplepod.yaml
$ oc apply -f examplepod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Pod가 생성되었는지 확인합니다.
oc get pod -n enable-allmulti-test
$ oc get pod -n enable-allmulti-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE samplepod 1/1 Running 0 47s
NAME READY STATUS RESTARTS AGE samplepod 1/1 Running 0 47sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Pod에 로그인합니다.
oc rsh -n enable-allmulti-test samplepod
$ oc rsh -n enable-allmulti-test samplepodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Pod와 관련된 모든 인터페이스를 나열합니다.
ip link
sh-4.4# ip linkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6장. SR-IOV 지원 워크로드에 대한 QinQ 지원 구성 링크 복사링크가 클립보드에 복사되었습니다!
공식적으로 802.1Q-in-802.1Q로 알려진 QinQ는 IEEE 802.1ad에 의해 정의된 네트워킹 기술입니다. IEEE 802.1ad는 IEEE 802.1Q-1998 표준을 확장하고 802.1Q로 이미 태그된 패킷에 802.1Q 태그를 추가로 도입하여 VLAN 기능을 강화합니다. 이 방법을 VLAN 스택 또는 이중 VLAN이라고도 합니다.
다음 문서에서 작업을 수행하기 전에 SR-IOV Network Operator를 설치 했는지 확인합니다.
6.1. 802.1Q-in-802.1Q 지원 정보 링크 복사링크가 클립보드에 복사되었습니다!
기존 VLAN 설정에서 프레임에는 일반적으로 VLAN-100과 같은 단일 VLAN 태그와 QoS(Quality of Service) 비트 및 프로토콜 정보와 같은 기타 메타데이터가 포함됩니다. QinQ에는 서비스 공급자가 사용할 외부 태그를 지정하여 유연성을 제공하고 내부 태그는 고객의 VLAN 전용 상태로 유지되는 두 번째 VLAN 태그가 도입되었습니다.
QinQ를 사용하면 이중 VLAN 태그를 사용하여 중첩된 VLAN을 쉽게 생성할 수 있으므로 네트워크 환경 내에서 트래픽을 세분화하고 격리할 수 있습니다. 이 접근 방식은 공통 인프라를 통해 VLAN 기반 서비스를 여러 고객에게 제공해야 하는 서비스 공급자 네트워크에서 특히 중요하며 트래픽 분리 및 격리를 보장합니다.
다음 다이어그램에서는 OpenShift Container Platform에서 SR-IOV 및 QinQ를 사용하여 컨테이너화된 워크로드의 고급 네트워크 분할 및 격리를 달성하는 방법을 보여줍니다.
다이어그램에서는 SR-IOV가 지원되는 작업자 노드에서 VLAN 태그 두 개(QinQ)가 작동하는 방법을 보여줍니다. Pod 네임스페이스에 있는 SR-IOV 가상 기능(VF)은 VLAN ID 및 VLAN 프로토콜을 사용하여 SR-IOV CNI(Container Network Interface)에 의해 구성됩니다. 이는 S-tag에 해당합니다. Pod 내부에서 VLAN CNI는 기본 인터페이스 ext0 을 사용하여 하위 인터페이스를 생성합니다. 이 하위 인터페이스는 C-tag에 해당하는 802.1Q 프로토콜을 사용하여 내부 VLAN ID를 추가합니다.
이는 QinQ를 사용하여 네트워크 내에서 트래픽 분할 및 격리를 활성화하는 방법을 보여줍니다. 이더넷 프레임 구조는 오른쪽에 자세히 설명되어 있으며 VLAN 태그, EtherType, IP, TCP 및 Payload 섹션의 포함을 강조 표시합니다. QinQ를 사용하면 트래픽 분리 및 격리를 보장하면서 공유 인프라를 통해 VLAN 기반 서비스를 여러 고객에게 제공할 수 있습니다.
OpenShift Container Platform SR-IOV 솔루션은 이미 SriovNetwork CR(사용자 정의 리소스)에서 VLAN 프로토콜 설정을 지원합니다. VF(가상 기능)는 이 프로토콜을 사용하여 외부 태그라고도 하는 VLAN 태그를 설정할 수 있습니다. 그러면 Pod에서 VLAN CNI 플러그인을 사용하여 내부 태그를 구성할 수 있습니다.
| NIC | 802.1ad/802.1Q | 802.1Q/802.1Q |
|---|---|---|
| Intel X710 | 없음 | 지원됨 |
| Intel E810 | 지원됨 | 지원됨 |
| Mellanox | 없음 | 지원됨 |
6.2. SR-IOV 지원 워크로드에 대한 QinQ 지원 구성 링크 복사링크가 클립보드에 복사되었습니다!
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - SR-IOV Network Operator가 설치되어 있습니다.
프로세스
다음 콘텐츠를 사용하여
sriovnetpolicy-810-sriov-node-network.yaml이라는 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
SriovNetworkNodePolicy오브젝트를 생성합니다.oc create -f sriovnetpolicy-810-sriov-node-network.yaml
$ oc create -f sriovnetpolicy-810-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 별도의 터미널 창을 열고 다음 명령을 실행하여
openshift-sriov-network-operator네임스페이스에 지정된 노드에 대한 SR-IOV 네트워크 노드 상태의 동기화 상태를 모니터링합니다.watch -n 1 'oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath="{.status.syncStatus}"'$ watch -n 1 'oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath="{.status.syncStatus}"'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 동기화 상태는
InProgress에서Succeeded로 변경되었음을 나타냅니다.SriovNetwork오브젝트를 생성하고 인프라에 속하므로 S-tag 또는Service Tag라는 외부 VLAN을 설정합니다.중요스위치의 트렁크 인터페이스에서 VLAN을 구성해야 합니다. 또한 QinQ 태그를 지원하도록 일부 스위치를 추가로 구성해야 할 수도 있습니다.
다음 콘텐츠를 사용하여
nad-sriovnetwork-1ad-810.yaml이라는 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 오브젝트를 생성합니다.
oc create -f nad-sriovnetwork-1ad-810.yaml
$ oc create -f nad-sriovnetwork-1ad-810.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
내부 VLAN을 사용하여
NetworkAttachmentDefinition오브젝트를 생성합니다. 내부 VLAN은 종종 네트워크 기능에 속하므로 C 태그 또는고객태그라고 합니다.다음 콘텐츠를 사용하여
nad-cvlan100.yaml이라는 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Pod 내부의 VF 인터페이스를 지정합니다. 기본 이름은
net1이며 이름은 Pod 주석에 설정되지 않습니다.
다음 명령을 실행하여 YAML 파일을 적용합니다.
oc apply -f nad-cvlan100.yaml
$ oc apply -f nad-cvlan100.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 절차에 따라 노드에서 QinQ가 활성화되어 있는지 확인합니다.
다음 콘텐츠를 사용하여
test-qinq-pod.yaml이라는 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 테스트 Pod를 생성합니다.
oc create -f test-qinq-pod.yaml
$ oc create -f test-qinq-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Pod가 있는 대상 노드에서 디버그 세션에 들어가 다음 명령을 실행하여 네트워크 인터페이스
ens5f0에 대한 정보를 표시합니다.oc debug node/my-cluster-node -- bash -c "ip link show ens5f0"
$ oc debug node/my-cluster-node -- bash -c "ip link show ens5f0"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력의
vlan 프로토콜 802.1adID는 인터페이스가 프로토콜 802.1ad(QinQ)를 사용하여 VLAN 태그 지정을 지원함을 나타냅니다. VLAN ID는 171입니다.
7장. 고성능 멀티 캐스트 사용 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV(Single Root I/O Virtualization) 하드웨어 네트워크에서 멀티 캐스트를 사용할 수 있습니다.
다음 문서에서 작업을 수행하기 전에 SR-IOV Network Operator를 설치 했는지 확인합니다.
7.1. 고성능 멀티 캐스트 링크 복사링크가 클립보드에 복사되었습니다!
OVN-Kubernetes 네트워크 플러그인은 기본 네트워크의 Pod 간 멀티 캐스트를 지원합니다. 이는 고 대역폭 애플리케이션이 아닌 저 대역폭 조정 또는 서비스 검색에 가장 적합합니다. IPTV(Internet Protocol Television) 및 멀티 포인트 화상 회의와 같은 스트리밍 미디어와 같은 애플리케이션의 경우 SR-IOV(Single Root I/O Virtualization) 하드웨어를 사용하여 거의 네이티브와 같은 성능을 제공할 수 있습니다.
멀티 캐스트에 추가 SR-IOV 인터페이스를 사용하는 경우:
- 멀티 캐스트 패키지는 추가 SR-IOV 인터페이스를 통해 pod에서 보내거나 받아야 합니다.
- SR-IOV 인터페이스를 연결하는 물리적 네트워크는 멀티 캐스트 라우팅 및 토폴로지를 결정하며 OpenShift Container Platform에서 제어하지 않습니다.
7.2. 멀티 캐스트에 대한 SR-IOV 인터페이스 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 프로시저는 멀티 캐스트용 SR-IOV 인터페이스 예제를 만듭니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin역할을 가진 사용자로 클러스터에 로그인해야 합니다.
프로세스
SriovNetworkNodePolicy오브젝트를 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow SriovNetwork오브젝트를 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 멀티 캐스트 애플리케이션으로 pod를 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
NET_ADMIN기능은 애플리케이션이 멀티 캐스트 IP 주소를 SR-IOV 인터페이스에 할당해야 하는 경우에만 필요합니다. 그 밖의 경우에는 생략할 수 있습니다.
8장. 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 Network Operator를 설치 했는지 확인합니다.
8.1. Pod에서 가상 함수 사용 예 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV VF가 연결된 pod에서 RDMA(Remote Direct Memory Access) 또는 DPDK(Data Plane Development Kit) 애플리케이션을 실행할 수 있습니다.
이 예는 RDMA 모드에서 VF(가상 기능)를 사용하는 pod를 보여줍니다.
RDMA 모드를 사용하는 Pod 사양
다음 예는 DPDK 모드에서 VF가 있는 pod를 보여줍니다.
DPDK 모드를 사용하는 Pod 사양
8.2. Intel NIC와 함께 DPDK 모드에서 가상 기능 사용 링크 복사링크가 클립보드에 복사되었습니다!
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. - SR-IOV Network Operator 설치.
-
cluster-admin권한이 있는 사용자로 로그인합니다.
프로세스
다음
SriovNetworkNodePolicy오브젝트를 생성한 다음 YAML을intel-dpdk-node-policy.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 가상 기능의 드라이버 유형을
vfio-pci로 지정합니다.
참고SriovNetworkNodePolicy의 각 옵션에 대한 자세한 설명은Configuring SR-IOV network devices섹션을 참조하십시오.SriovNetworkNodePolicy오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.구성 업데이트가 적용되면
openshift-sriov-network-operator네임스페이스의 모든 Pod 상태가Running으로 변경됩니다.다음 명령을 실행하여
SriovNetworkNodePolicy오브젝트를 생성합니다.oc create -f intel-dpdk-node-policy.yaml
$ oc create -f intel-dpdk-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음
SriovNetwork오브젝트를 생성한 다음 YAML을intel-dpdk-network.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ipam CNI 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
참고SriovNetwork의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.선택적 라이브러리인 app-netutil은 컨테이너의 상위 pod에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.
다음 명령을 실행하여
SriovNetwork오브젝트를 생성합니다.oc create -f intel-dpdk-network.yaml
$ oc create -f intel-dpdk-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음
Pod사양을 생성한 다음 YAML을intel-dpdk-pod.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetwork오브젝트intel-dpdk-network가 생성되는 동일한target_namespace를 지정합니다. 다른 네임스페이스에서 Pod를 생성하려면Pod사양과SriovNetwork오브젝트 모두에서target_namespace를 변경합니다.- 2
- 애플리케이션 및 애플리케이션이 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.
- 3
- hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
- 4
/mnt/huge의 DPDK Pod에 hugepage 볼륨을 마운트합니다. hugepage 볼륨은 매체가Hugepages인 emptyDir 볼륨 유형으로 지원됩니다.- 5
- 선택사항: DPDK Pod에 할당된 DPDK 장치 수를 지정합니다. 명시적으로 지정되지 않은 경우 이 리소스 요청 및 제한은 SR-IOV 네트워크 리소스 인젝터에 의해 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본
SriovOperatorConfigCR에서enableInjector옵션을false로 설정하여 비활성화할 수 있습니다. - 6
- CPU 수를 지정합니다. DPDK pod는 일반적으로 kubelet에서 배타적 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을
static으로 설정하고 QoS가보장된 Pod를 생성합니다. - 7
- hugepage 크기
hugepages-1Gi또는hugepages-2Mi를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다.2Mi및1Gihugepage를 별도로 구성합니다.1Gihugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다. 예를 들어, 커널 인수default_hugepagesz = 1GB,hugepagesz = 1G및hugepages = 16을 추가하면 시스템 부팅 시16 * 1Gihugepage가 할당됩니다.
다음 명령을 실행하여 DPDK Pod를 생성합니다.
oc create -f intel-dpdk-pod.yaml
$ oc create -f intel-dpdk-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.3. Mellanox NIC와 함께 DPDK 모드에서 가상 기능 사용 링크 복사링크가 클립보드에 복사되었습니다!
Mellanox NIC와 함께 DPDK 모드에서 가상 기능을 사용하여 네트워크 노드 정책을 생성하고 DPDK(Data Plane Development Kit) Pod를 생성할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. - SR-IOV(Single Root I/O Virtualization) Network Operator가 설치되어 있습니다.
-
cluster-admin권한이 있는 사용자로 로그인했습니다.
프로세스
다음
SriovNetworkNodePolicyYAML 구성을mlx-dpdk-node-policy.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고SriovNetworkNodePolicy오브젝트의 각 옵션에 대한 자세한 설명은 SR-IOV 네트워크 장치 구성 을 참조하십시오.SriovNetworkNodePolicy오브젝트에 지정된 구성을 적용하면 SR-IOV Operator에서 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.구성 업데이트가 적용되면
openshift-sriov-network-operator네임스페이스의 모든 Pod 상태가Running으로 변경됩니다.다음 명령을 실행하여
SriovNetworkNodePolicy오브젝트를 생성합니다.oc create -f mlx-dpdk-node-policy.yaml
$ oc create -f mlx-dpdk-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음
SriovNetworkYAML 구성을mlx-dpdk-network.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- IPAM(IP Address Management) CNI(Container Network Interface) 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
참고SriovNetwork오브젝트 의 각 옵션에 대한 자세한 설명은 SR-IOV 네트워크 장치 구성 을 참조하십시오.app-netutil옵션 라이브러리는 컨테이너의 상위 포드에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.다음 명령을 실행하여
SriovNetwork오브젝트를 생성합니다.oc create -f mlx-dpdk-network.yaml
$ oc create -f mlx-dpdk-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음
PodYAML 구성을mlx-dpdk-pod.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetwork오브젝트mlx-dpdk-network가 생성되는 동일한target_namespace를 지정합니다. 다른 네임스페이스에서 Pod를 생성하려면Pod사양과SriovNetwork오브젝트 모두에서target_namespace를 변경합니다.- 2
- 애플리케이션 및 애플리케이션에서 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.
- 3
- hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
- 4
- hugepage 볼륨을
/mnt/huge아래의 DPDK Pod에 마운트합니다. hugepage 볼륨은 medium가Hugepages인emptyDir볼륨 유형으로 지원됩니다. - 5
- 선택 사항: DPDK Pod에 할당된 DPDK 장치 수를 지정합니다. 명시적으로 지정하지 않으면 SR-IOV 네트워크 리소스 인젝터에 의해 이 리소스 요청 및 제한이 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본
SriovOperatorConfigCR에서enableInjector옵션을false로 설정하여 비활성화할 수 있습니다. - 6
- CPU 수를 지정합니다. DPDK Pod는 일반적으로 kubelet에서 전용 CPU를 할당해야 합니다. 이렇게 하려면 CPU 관리자 정책을
static으로 설정하고 QoS(Quality of Service)가있는 Pod를 생성합니다. - 7
- hugepage 크기
hugepages-1Gi또는hugepages-2Mi를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다.2Mi및1Gihugepage를 별도로 구성합니다.1Gihugepages를 구성하려면 커널 인수를 노드에 추가해야 합니다.
다음 명령을 실행하여 DPDK Pod를 생성합니다.
oc create -f mlx-dpdk-pod.yaml
$ oc create -f mlx-dpdk-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4. Cryostat CNI를 사용하여 커널 액세스로 루트리스 DPDK 워크로드 실행 링크 복사링크가 클립보드에 복사되었습니다!
DPDK 애플리케이션은 virtio-user 를 예외 경로로 사용하여 로그 메시지와 같은 특정 유형의 패킷을 처리를 위해 커널에 삽입할 수 있습니다. 이 기능에 대한 자세한 내용은 Exception Path로 Virtio_user 를 참조하십시오.
OpenShift Container Platform 버전 4.14 이상에서는 권한이 없는 Pod를 사용하여 탭 CNI 플러그인과 함께 DPDK 애플리케이션을 실행할 수 있습니다. 이 기능을 활성화하려면 SriovNetworkNodePolicy 오브젝트 내에서 needVhostNet 매개변수를 true 로 설정하여 vhost-net 장치를 마운트해야 합니다.
그림 8.1. DPDK 및 Cryostat 예제 구성
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. - SR-IOV Network Operator가 설치되어 있습니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다. setsebools container_use_devices=on이 모든 노드에서 root로 설정되어 있는지 확인합니다.참고Machine Config Operator를 사용하여 이 SELinux 부울을 설정합니다.
프로세스
다음 예와 같은 콘텐츠를 사용하여
test-namespace.yaml과 같은 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 새
Namespace오브젝트를 생성합니다.oc apply -f test-namespace.yaml
$ oc apply -f test-namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예와 같은 콘텐츠를 사용하여
sriov-node-network-policy.yaml과 같은 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 이는 프로파일이 Mellanox Network Interface Controller(NIC)에 맞게 조정됨을 나타냅니다.
- 2
isRdma를true로 설정하는 것은 Mellanox NIC에만 필요합니다.- 3
- 그러면 애플리케이션이 탭 장치를 생성하고 탭 장치를 DPDK 워크로드에 연결할 수 있도록
/dev/net/tun및/dev/vhost-net장치를 컨테이너에 마운트합니다. - 4
- SR-IOV 네트워크 장치의 벤더 16진수 코드입니다. 값 15b3은 Mellanox NIC와 연결되어 있습니다.
- 5
- SR-IOV 네트워크 장치의 장치 16진수 코드입니다.
다음 명령을 실행하여
SriovNetworkNodePolicy오브젝트를 생성합니다.oc create -f sriov-node-network-policy.yaml
$ oc create -f sriov-node-network-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음
SriovNetwork오브젝트를 생성한 다음 YAML을sriov-network-attachment.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고SriovNetwork의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.선택적 라이브러리인
app-netutil은 컨테이너의 상위 pod에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.다음 명령을 실행하여
SriovNetwork오브젝트를 생성합니다.oc create -f sriov-network-attachment.yaml
$ oc create -f sriov-network-attachment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예와 같은 콘텐츠를 사용하여 네트워크 연결 정의를 정의하는
tap-example.yaml과 같은 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetwork오브젝트가 생성되는 동일한target_namespace를 지정합니다.
다음 명령을 실행하여
NetworkAttachmentDefinition오브젝트를 생성합니다.oc apply -f tap-example.yaml
$ oc apply -f tap-example.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예와 같은 콘텐츠를 사용하여
dpdk-pod-rootless.yaml과 같은 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
- 이 설정은 Pod 내의 컨테이너 또는 컨테이너에 호스트 시스템에 대한 권한 액세스 권한을 부여하지 않아야 함을 나타냅니다.
- 10
- 이 설정을 사용하면 컨테이너가 할당되었을 수 있는 초기 루트 권한이 아닌 초기 권한을 에스컬레이션할 수 있습니다.
- 11
- 이 설정을 사용하면 컨테이너가 루트가 아닌 사용자로 실행됩니다. 이렇게 하면 컨테이너 손상 및 공격 면적 감소의 잠재적인 영향을 제한하여 최소 권한 원칙을 적용하는 데 도움이 됩니다.
- 12
/mnt/huge의 DPDK Pod에 hugepage 볼륨을 마운트합니다. hugepage 볼륨은 매체가Hugepages인 emptyDir 볼륨 유형으로 지원됩니다.- 13
- 선택 사항: DPDK Pod에 할당된 DPDK 장치 수를 지정합니다. 명시적으로 지정하지 않으면 SR-IOV 네트워크 리소스 인젝터에 의해 이 리소스 요청 및 제한이 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본
SriovOperatorConfigCR에서enableInjector옵션을false로 설정하여 비활성화할 수 있습니다. - 14
- CPU 수를 지정합니다. DPDK pod는 일반적으로 kubelet에서 배타적 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을
static으로 설정하고 QoS가보장된 Pod를 생성합니다. - 15
- hugepage 크기
hugepages-1Gi또는hugepages-2Mi를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다.2Mi및1Gihugepage를 별도로 구성합니다.1Gihugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다. 예를 들어, 커널 인수default_hugepagesz = 1GB,hugepagesz = 1G및hugepages = 16을 추가하면 시스템 부팅 시16 * 1Gihugepage가 할당됩니다. - 16
- 성능 프로필의 이름이
cnf-performance 프로필로 지정되지 않은 경우 해당 문자열을 올바른 성능 프로필 이름으로 교체합니다.
다음 명령을 실행하여 DPDK Pod를 생성합니다.
oc create -f dpdk-pod-rootless.yaml
$ oc create -f dpdk-pod-rootless.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.5. 특정 DPDK 라인 비율 달성 개요 링크 복사링크가 클립보드에 복사되었습니다!
특정 DPDK(Data Plane Development Kit) 라인 속도를 달성하려면 Node Tuning Operator를 배포하고 SR-IOV(Single Root I/O Virtualization)를 구성합니다. 다음 리소스에 대한 DPDK 설정도 조정해야 합니다.
- 분리된 CPU
- hugepages
- 토폴로지 스케줄러
이전 버전의 OpenShift Container Platform에서는 Performance Addon Operator를 사용하여 OpenShift Container Platform 애플리케이션에 대한 짧은 대기 시간 성능을 달성하기 위해 자동 튜닝을 구현했습니다. OpenShift Container Platform 4.11 이상에서 이 기능은 Node Tuning Operator의 일부입니다.
DPDK 테스트 환경
다음 다이어그램은 트래픽 테스트 환경의 구성 요소를 보여줍니다.
- 트래픽 생성기: 대용량 패킷 트래픽을 생성할 수 있는 애플리케이션입니다.
- SR-IOV-supporting NIC: SR-IOV와 호환되는 네트워크 인터페이스 카드입니다. 이 카드는 물리적 인터페이스에서 여러 가상 기능을 실행합니다.
- 물리적 기능(PF ): SR-IOV 인터페이스를 지원하는 네트워크 어댑터의 PCI Express(PCIe) 기능입니다.
- VF(가상 기능): SR-IOV를 지원하는 네트워크 어댑터의 경량 PCIe 기능입니다. VF는 네트워크 어댑터의 PCIe PF와 연결되어 있습니다. VF는 네트워크 어댑터의 가상화된 인스턴스를 나타냅니다.
- Switch: 네트워크 스위치 노드를 뒤로 연결할 수도 있습니다.
-
testpmd: DPDK에 포함된 예제 애플리케이션입니다.testpmd애플리케이션을 사용하여 패킷 전달 모드에서 DPDK를 테스트할 수 있습니다.testpmd애플리케이션은 DPDK SDK(Software Development Kit)를 사용하여 완전한 애플리케이션을 빌드하는 방법의 예이기도 합니다. - 작업자 0 및 작업자 1: OpenShift Container Platform 노드.
8.6. SR-IOV 및 Node Tuning Operator를 사용하여 DPDK 라인 속도 달성 링크 복사링크가 클립보드에 복사되었습니다!
Node Tuning Operator를 사용하여 분리된 CPU, hugepages 및 토폴로지 스케줄러를 구성할 수 있습니다. 그런 다음 SR-IOV(Single Root I/O Virtualization)와 함께 Node Tuning Operator를 사용하여 특정 DPDK(Data Plane Development Kit) 라인 속도를 얻을 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. - SR-IOV Network Operator가 설치되어 있습니다.
-
cluster-admin권한이 있는 사용자로 로그인했습니다. 독립 실행형 Node Tuning Operator를 배포했습니다.
참고이전 버전의 OpenShift Container Platform에서는 Performance Addon Operator를 사용하여 OpenShift 애플리케이션에 대해 짧은 대기 시간 성능을 달성하기 위해 자동 튜닝을 구현했습니다. OpenShift Container Platform 4.11 이상에서 이 기능은 Node Tuning Operator의 일부입니다.
프로세스
다음 예제를 기반으로
PerformanceProfile오브젝트를 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 시스템에서 하이퍼 스레딩이 활성화된 경우
격리된CPU 그룹과예약된CPU 그룹에 관련 심볼릭 링크를 할당합니다. 시스템에 NUMA(Non-Uniform Memory Access nodes)가 여러 개 포함된 경우 두 NUMA의 CPU를 두 그룹에 할당합니다. 이 작업에 Performance Profile Creator를 사용할 수도 있습니다. 자세한 내용은 성능 프로필 생성을 참조하십시오. - 2
- 대기열을 예약된 CPU 수로 설정할 장치 목록을 지정할 수도 있습니다. 자세한 내용은 Node Tuning Operator를 사용하여 NIC 대기열 단축을 참조하십시오.
- 3
- 필요한 hugepages의 수와 크기를 할당합니다. hugepages에 대한 NUMA 구성을 지정할 수 있습니다. 기본적으로 시스템은 시스템의 모든 NUMA 노드에 짝 숫자를 할당합니다. 필요한 경우 노드에 대한 실시간 커널 사용을 요청할 수 있습니다. 자세한 내용은 실시간 기능이 있는 작업자 프로비저닝 을 참조하십시오.
-
yaml파일을mlx-dpdk-perfprofile-policy.yaml로 저장합니다. 다음 명령을 사용하여 성능 프로필을 적용합니다.
oc create -f mlx-dpdk-perfprofile-policy.yaml
$ oc create -f mlx-dpdk-perfprofile-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.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 워크로드에 데이터를 전달할 수 있습니다.
8.6.2. 가상 기능을 위한 SR-IOV Network Operator의 예 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV(Single Root I/O Virtualization) Network Operator를 사용하여 노드의 SR-IOV 지원 물리적 기능 NIC에서 VF(가상 기능)를 할당하고 구성할 수 있습니다.
Operator 배포에 대한 자세한 내용은 SR-IOV Network Operator 설치를 참조하십시오. SR-IOV 네트워크 장치 구성에 대한 자세한 내용은 SR-IOV 네트워크 장치 구성을 참조하십시오.
Intel VF와 Mellanox VF에서 DPDK(Data Plane Development Kit) 워크로드를 실행하는 데 몇 가지 차이점이 있습니다. 이 섹션에서는 두 VF 유형에 대한 오브젝트 구성 예제를 제공합니다. 다음은 Intel NIC에서 DPDK 애플리케이션을 실행하는 데 사용되는 sriovNetworkNodePolicy 오브젝트의 예입니다.
다음은 Mellanox NIC의 sriovNetworkNodePolicy 오브젝트의 예입니다.
8.6.3. SR-IOV 네트워크 Operator의 예 링크 복사링크가 클립보드에 복사되었습니다!
다음은 sriovNetwork 오브젝트 정의의 예입니다. 이 경우 Intel 및 Mellanox 구성은 동일합니다.
8.6.4. DPDK 기본 워크로드의 예 링크 복사링크가 클립보드에 복사되었습니다!
다음은 DPDK(Data Plane Development Kit) 컨테이너의 예입니다.
SLEEP 로 Pod를 시작한 다음 pod를 실행하여 testpmd 또는 DPDK 워크로드를 시작합니다. exec 프로세스가 CPU에 고정되지 않으므로 추가 인터럽트를 추가할 수 있습니다.
8.6.5. testpmd 스크립트 예 링크 복사링크가 클립보드에 복사되었습니다!
다음은 testpmd 를 실행하기 위한 예제 스크립트입니다.
이 예제에서는 두 개의 다른 sriovNetwork CR을 사용합니다. 환경 변수에는 Pod에 할당된 VF(가상 기능) PCI 주소가 포함되어 있습니다. 포드 정의에서 동일한 네트워크를 사용하는 경우 pciAddress 를 분할해야 합니다. 트래픽 생성기의 올바른 MAC 주소를 구성하는 것이 중요합니다. 이 예에서는 사용자 지정 MAC 주소를 사용합니다.
8.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권한이 있는 사용자로 로그인합니다.
프로세스
다음
SriovNetworkNodePolicy오브젝트를 생성한 다음 YAML을mlx-rdma-node-policy.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고SriovNetworkNodePolicy의 각 옵션에 대한 자세한 설명은Configuring SR-IOV network devices섹션을 참조하십시오.SriovNetworkNodePolicy오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.구성 업데이트가 적용되면
openshift-sriov-network-operator네임스페이스의 모든 Pod 상태가Running으로 변경됩니다.다음 명령을 실행하여
SriovNetworkNodePolicy오브젝트를 생성합니다.oc create -f mlx-rdma-node-policy.yaml
$ oc create -f mlx-rdma-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음
SriovNetwork오브젝트를 생성한 다음 YAML을mlx-rdma-network.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ipam CNI 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
참고SriovNetwork의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.선택적 라이브러리인 app-netutil은 컨테이너의 상위 pod에 대한 네트워크 정보를 수집하기 위한 여러 API 메서드를 제공합니다.
다음 명령을 실행하여
SriovNetworkNodePolicy오브젝트를 생성합니다.oc create -f mlx-rdma-network.yaml
$ oc create -f mlx-rdma-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음
Pod사양을 생성한 다음 YAML을mlx-rdma-pod.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetwork오브젝트mlx-rdma-network가 생성되는 동일한target_namespace를 지정합니다. 다른 네임스페이스에서 Pod를 생성하려면Pod사양과SriovNetwork오브젝트 모두에서target_namespace를 변경합니다.- 2
- 애플리케이션 및 애플리케이션에서 사용하는 RDMA 라이브러리를 포함하는 RDMA 이미지를 지정합니다.
- 3
- hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.
- 4
- hugepage 볼륨을
/mnt/huge아래의 RDMA Pod에 마운트합니다. hugepage 볼륨은 매체가Hugepages인 emptyDir 볼륨 유형으로 지원됩니다. - 5
- CPU 수를 지정합니다. RDMA Pod는 일반적으로 kubelet에서 전용 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을
static으로 설정하고 QoS가GuaranteedPod를 생성합니다. - 6
- hugepage 크기
hugepages-1Gi또는hugepages-2Mi를 지정하고 RDMA Pod에 할당할 hugepage 수량을 지정합니다.2Mi및1Gihugepage를 별도로 구성합니다.1Gihugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다.
다음 명령을 실행하여 RDMA Pod를 생성합니다.
oc create -f mlx-rdma-pod.yaml
$ oc create -f mlx-rdma-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.8. OpenStack에서 OVS-DPDK를 사용하는 클러스터의 테스트 포드 템플릿 링크 복사링크가 클립보드에 복사되었습니다!
다음 testpmd Pod는 대규모 페이지, 예약된 CPU 및 SR-IOV 포트로 컨테이너 생성을 보여줍니다.
testpmd Pod의 예
9장. Pod 수준 본딩 사용 링크 복사링크가 클립보드에 복사되었습니다!
Pod 수준의 본딩은 고가용성과 처리량이 필요한 Pod 내부의 워크로드를 활성화하는 데 중요합니다. Pod 수준 본딩을 사용하면 커널 모드 인터페이스에서 여러 개의 SR-IOV(root I/O Virtualization) 가상 기능 인터페이스에서 본딩 인터페이스를 생성할 수 있습니다. SR-IOV 가상 기능은 Pod에 전달되고 커널 드라이버에 연결됩니다.
Pod 수준 본딩이 필요한 한 가지 시나리오는 다양한 물리적 기능의 여러 SR-IOV 가상 함수에서 본딩 인터페이스를 생성하는 것입니다. 호스트에서 두 가지 물리적 함수에서 본딩 인터페이스를 생성하여 Pod 수준에서 고가용성 및 처리량을 달성할 수 있습니다.
다음 문서에서 작업을 수행하기 전에 SR-IOV Network Operator를 설치 했는지 확인합니다.
SR-IOV 네트워크, 네트워크 정책, 네트워크 연결 정의 및 Pod 생성과 같은 작업에 대한 지침은 SR-IOV 네트워크 장치 구성을 참조하십시오.
9.1. 두 개의 SR-IOV 인터페이스에서 본딩 인터페이스 구성 링크 복사링크가 클립보드에 복사되었습니다!
본딩을 사용하면 여러 네트워크 인터페이스를 단일 논리 "bonded" 인터페이스로 집계할 수 있습니다. 본딩 컨테이너 네트워크 인터페이스(Bond-CNI)는 컨테이너에 본딩 기능을 제공합니다.
bond-CNI는 SR-IOV(Single Root I/O Virtualization) 가상 기능을 사용하여 생성하여 컨테이너 네트워크 네임스페이스에 배치할 수 있습니다.
OpenShift Container Platform은 SR-IOV 가상 기능을 사용하여 Bond-CNI만 지원합니다. SR-IOV Network Operator는 가상 기능을 관리하는 데 필요한 SR-IOV CNI 플러그인을 제공합니다. 기타 CNI 또는 인터페이스 유형은 지원되지 않습니다.
사전 요구 사항
- SR-IOV Network Operator는 컨테이너에서 가상 기능을 가져오도록 설치 및 구성해야 합니다.
- SR-IOV 인터페이스를 구성하려면 각 인터페이스에 SR-IOV 네트워크 및 정책을 생성해야 합니다.
- SR-IOV Network Operator는 정의된 SR-IOV 네트워크 및 정책을 기반으로 각 SR-IOV 인터페이스에 대한 네트워크 연결 정의를 생성합니다.
-
linkState는 SR-IOV 가상 기능의 기본값auto로 설정됩니다.
9.1.1. 본딩 네트워크 연결 정의 생성 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV 가상 기능을 사용할 수 있게 되면 본딩 네트워크 연결 정의를 생성할 수 있습니다.
- 1
- cni-type은 항상
bond로 설정됩니다. - 2
mode속성은 본딩 모드를 지정합니다.참고지원되는 본딩 모드는 다음과 같습니다.
-
balance-rr- 0 -
active-backup- 1 -
balance-xor- 2
balance-rr또는balance-xor모드의 경우 SR-IOV 가상 기능에 대해신뢰모드를on으로 설정해야 합니다.-
- 3
failover속성은 active-backup 모드의 경우 필수이며 1로 설정해야 합니다.- 4
linksInContainer=true플래그는 Bond CNI에 컨테이너 내에서 필요한 인터페이스를 찾을 수 있음을 알립니다. 기본적으로 Bond CNI는 SRIOV 및 Multus와의 통합에 작동하지 않는 호스트에서 이러한 인터페이스를 찾습니다.- 5
links섹션에서는 본딩을 만드는 데 사용할 인터페이스를 정의합니다. 기본적으로 Multus는 연결된 인터페이스의 이름을 "net" 및 연속 번호(한 개부터 시작하여)로 지정합니다.
9.1.2. 본딩 인터페이스를 사용하여 Pod 생성 링크 복사링크가 클립보드에 복사되었습니다!
다음과 유사한 콘텐츠가 있는 pod의 YAML 파일 (예:
podbonding.yaml)을 사용하여 pod를 생성하여 설정을 테스트합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 네트워크 주석: 두 개의 SR-IOV 네트워크 연결과 하나의 본딩 네트워크 연결이 포함되어 있습니다. 본딩 연결에서는 두 개의 SR-IOV 인터페이스를 결합된 포트 인터페이스로 사용합니다.
다음 명령을 실행하여 yaml을 적용합니다.
oc apply -f podbonding.yaml
$ oc apply -f podbonding.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여 Pod 인터페이스를 검사합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고Pod 주석에 인터페이스 이름이 구성되지 않은 경우 인터페이스 이름은
net<n> 로 자동으로 할당되며 <n>은1부터 시작합니다.선택 사항:
bond0과 같은 특정 인터페이스 이름을 설정하려면k8s.v1.cni.cncf.io/networks주석을 편집하고 다음과 같이bond0을 인터페이스 이름으로 설정합니다.annotations: k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1@bond0annotations: k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1@bond0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10장. 하드웨어 오프로드 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 호환 가능한 노드에서 하드웨어 오프로드를 구성하여 데이터 처리 성능을 높이고 호스트 CPU의 부하를 줄일 수 있습니다.
다음 문서에서 작업을 수행하기 전에 SR-IOV Network Operator를 설치 했는지 확인합니다.
10.1. 하드웨어 오프로드 정보 링크 복사링크가 클립보드에 복사되었습니다!
Open vSwitch 하드웨어 오프로드는 CPU에서 벗어나 네트워크 인터페이스 컨트롤러의 전용 프로세서로 오프로드하여 네트워크 작업을 처리하는 방법입니다. 결과적으로 클러스터는 더 빠른 데이터 전송 속도, CPU 워크로드 감소 및 컴퓨팅 비용 절감의 이점을 얻을 수 있습니다.
이 기능의 핵심 요소는 SmartNICs라는 최신 네트워크 인터페이스 컨트롤러 클래스입니다. SmartNIC는 컴퓨팅 집약적인 네트워크 처리 작업을 처리할 수 있는 네트워크 인터페이스 컨트롤러입니다. 전용 그래픽 카드가 그래픽 성능을 향상시킬 수 있는 것과 마찬가지로 SmartNIC는 네트워크 성능을 향상시킬 수 있습니다. 각 경우 전용 프로세서는 특정 유형의 처리 작업에 대한 성능을 향상시킵니다.
OpenShift Container Platform에서는 호환되는 SmartNIC가 있는 베어 메탈 노드에 대한 하드웨어 오프로드를 구성할 수 있습니다. 하드웨어 오프로드는 SR-IOV Network Operator에 의해 구성 및 활성화됩니다.
하드웨어 오프로드는 모든 워크로드 또는 애플리케이션 유형과 호환되지 않습니다. 다음 두 가지 통신 유형만 지원됩니다.
- pod-to-pod
- pod-to-service: 서비스는 일반 Pod에서 지원하는 ClusterIP 서비스
모든 경우에서 하드웨어 오프로드는 호환되는 SmartNIC가 있는 노드에 해당 Pod 및 서비스가 할당된 경우에만 수행됩니다. 예를 들어 하드웨어 오프로드가 있는 노드의 Pod가 일반 노드에서 서비스와 통신하려고 한다고 가정합니다. 일반 노드에서 모든 처리가 커널에서 수행되므로 pod-to-service 통신의 전반적인 성능은 해당 일반 노드의 최대 성능으로 제한됩니다. 하드웨어 오프로드는 DPDK 애플리케이션과 호환되지 않습니다.
노드에서 하드웨어 오프로드를 활성화하지만 사용할 Pod를 구성하지 않으면 Pod 트래픽의 처리량 성능이 저하될 수 있습니다. OpenShift Container Platform에서 관리하는 Pod의 하드웨어 오프로드를 구성할 수 없습니다.
10.2. 지원되는 장치 링크 복사링크가 클립보드에 복사되었습니다!
하드웨어 오프로드는 다음 네트워크 인터페이스 컨트롤러에서 지원됩니다.
| 제조업체 | 모델 | 벤더 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 | MT42822 BlueField-2 in ConnectX-6 NIC 모드 | 15b3 | a2d6 |
10.3. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 클러스터에는 하드웨어 오프로드에 지원되는 네트워크 인터페이스 컨트롤러가 있는 하나 이상의 베어 메탈 머신이 있습니다.
- SR-IOV Network Operator가 설치되어 있어야 합니다.
- 클러스터는 OVN-Kubernetes 네트워크 플러그인 을 사용합니다.
-
OVN-Kubernetes 네트워크 플러그인 구성에서
gatewayConfig.routingViaHost필드가false로 설정됩니다.
10.4. SR-IOV Network Operator를 systemd 모드로 설정 링크 복사링크가 클립보드에 복사되었습니다!
하드웨어 오프로드를 지원하려면 먼저 SR-IOV Network Operator를 systemd 모드로 설정해야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin역할이 있는 사용자로 클러스터에 액세스할 수 있습니다.
프로세스
SriovOperatorConfigCR(사용자 정의 리소스)을 생성하여 모든 SR-IOV Operator 구성 요소를 배포합니다.다음 YAML이 포함된
sriovOperatorConfig.yaml파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 리소스를 생성합니다.
oc apply -f sriovOperatorConfig.yaml
$ oc apply -f sriovOperatorConfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.5. 하드웨어 오프로드를 위한 머신 구성 풀 구성 링크 복사링크가 클립보드에 복사되었습니다!
하드웨어 오프로드를 활성화하기 위해 전용 머신 구성 풀을 생성하고 SR-IOV Network Operator에서 작동하도록 구성합니다.
사전 요구 사항
-
SR-IOV Network Operator가 설치되어
systemd모드로 설정됩니다.
프로세스
에서 하드웨어 오프로드를 사용할 머신의 머신 구성 풀을 생성합니다.
다음 예와 같은 콘텐츠를 사용하여
mcp-offloading.yaml과 같은 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 머신 구성 풀의 구성을 적용합니다.
oc create -f mcp-offloading.yaml
$ oc create -f mcp-offloading.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
머신 구성 풀에 노드를 추가합니다. 각 노드에 풀의 노드 역할 라벨을 지정합니다.
oc label node worker-2 node-role.kubernetes.io/mcp-offloading=""
$ oc label node worker-2 node-role.kubernetes.io/mcp-offloading=""Copy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항: 새 풀이 생성되었는지 확인하려면 다음 명령을 실행합니다.
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 머신 구성 풀을
SriovNetworkPoolConfig사용자 정의 리소스에 추가합니다.다음 예와 같은 콘텐츠를 사용하여
sriov-pool-config.yaml과 같은 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 하드웨어 오프로드를 위한 머신 구성 풀의 이름입니다.
설정을 적용합니다.
oc create -f <SriovNetworkPoolConfig_name>.yaml
$ oc create -f <SriovNetworkPoolConfig_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고SriovNetworkPoolConfig오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 머신 구성 풀에서 노드를 비우고 재시작합니다.구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.
10.6. SR-IOV 네트워크 노드 정책 구성 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV 네트워크 노드 정책을 생성하여 노드의 SR-IOV 네트워크 장치 구성을 생성할 수 있습니다. 하드웨어 오프로드를 활성화하려면 "switchdev" 값으로 .spec.eSwitchMode 필드를 정의해야 합니다.
다음 절차에서는 하드웨어 오프로드를 사용하여 네트워크 인터페이스 컨트롤러에 대한 SR-IOV 인터페이스를 생성합니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
다음 예와 같은 콘텐츠를 사용하여
sriov-node-policy.yaml과 같은 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 정책 구성을 적용합니다.
oc create -f sriov-node-policy.yaml
$ oc create -f sriov-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고SriovNetworkPoolConfig오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 머신 구성 풀에서 노드를 비우고 재시작합니다.구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.
10.6.1. OpenStack의 SR-IOV 네트워크 노드 정책의 예 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제에서는 RHOSP(Red Hat OpenStack Platform)에서 하드웨어 오프로드가 있는 NIC(네트워크 인터페이스 컨트롤러)의 SR-IOV 인터페이스를 설명합니다.
RHOSP에서 하드웨어 오프로드가 있는 NIC용 SR-IOV 인터페이스
10.7. 가상 기능을 사용하여 네트워크 트래픽 성능 개선 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에 따라 OVN-Kubernetes 관리 포트에 가상 기능을 할당하고 네트워크 트래픽 성능을 향상시킵니다.
이 절차에서는 두 개의 풀이 생성됩니다. 첫 번째 풀에는 OVN-Kubernetes에서 사용하는 가상 기능이 있고 두 번째는 나머지 가상 함수로 구성됩니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
다음 명령을 실행하여 SmartNIC를 사용하여 각 작업자 노드에
network.operator.openshift.io/smart-nic레이블을 추가합니다.oc label node <node-name> network.operator.openshift.io/smart-nic=
$ oc label node <node-name> network.operator.openshift.io/smart-nic=Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get nodes명령을 사용하여 사용 가능한 노드 목록을 가져옵니다.다음 예와 같은 콘텐츠를 사용하여 관리 포트에 대해
sriov-node-mgmt-vf-policy.yaml이라는 정책을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예와 같은 콘텐츠를 사용하여
sriov-node-policy.yaml이라는 정책을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고sriov-node-mgmt-vf-policy.yaml파일에는sriov-node-policy.yaml파일과 함께pfNames및resourceName키에 대해 다른 값이 있습니다.두 정책에 모두 구성을 적용합니다.
oc create -f sriov-node-policy.yaml
$ oc create -f sriov-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc create -f sriov-node-mgmt-vf-policy.yaml
$ oc create -f sriov-node-mgmt-vf-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 관리 구성을 위해 클러스터에 CNO(Cluster Network Operator) ConfigMap을 생성합니다.
다음 콘텐츠를 사용하여
hardware-offload-config.yaml이라는 ConfigMap을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow ConfigMap의 구성을 적용합니다.
oc create -f hardware-offload-config.yaml
$ oc create -f hardware-offload-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.8. 네트워크 연결 정의 생성 링크 복사링크가 클립보드에 복사되었습니다!
머신 구성 풀과 SR-IOV 네트워크 노드 정책을 정의한 후 지정한 네트워크 인터페이스 카드에 대한 네트워크 연결 정의를 생성할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
다음 예와 같은 콘텐츠를 사용하여
net-attach-def.yaml과 같은 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 네트워크 연결 정의에 대한 구성을 적용합니다.
oc create -f net-attach-def.yaml
$ oc create -f net-attach-def.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 새 정의가 있는지 확인합니다.
oc get net-attach-def -A
$ oc get net-attach-def -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력에는 새 정의의 네임스페이스, 이름, 기간이 표시됩니다.
10.9. Pod에 네트워크 연결 정의 추가 링크 복사링크가 클립보드에 복사되었습니다!
머신 구성 풀, SriovNetworkPoolConfig 및 SriovNetworkNodePolicy 사용자 정의 리소스 및 네트워크 연결 정의를 생성한 후 Pod 사양에 네트워크 연결 정의를 추가하여 Pod에 이러한 구성을 적용할 수 있습니다.
프로세스
Pod 사양에서
.metadata.annotations.k8s.v1.cni.cncf.io/networks필드를 추가하고 하드웨어 오프로드를 위해 생성한 네트워크 연결 정의를 지정합니다..... metadata: annotations: v1.multus-cni.io/default-network: net-attach-def/net-attach-def.... metadata: annotations: v1.multus-cni.io/default-network: net-attach-def/net-attach-def1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 값은 하드웨어 오프로드를 위해 생성한 네트워크 연결 정의의 이름과 네임스페이스여야 합니다.
11장. Bluefield-2를 DPU에서 NIC로 전환 링크 복사링크가 클립보드에 복사되었습니다!
Bluefield-2 네트워크 장치를 DPDK(데이터 처리 장치) 모드에서 NIC(네트워크 인터페이스 컨트롤러) 모드로 전환할 수 있습니다.
다음 문서에서 작업을 수행하기 전에 SR-IOV Network Operator를 설치 했는지 확인합니다.
11.1. Bluefield-2를 DPU 모드에서 NIC 모드로 전환 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에 따라 Bluefield-2를 데이터 처리 단위(DPU) 모드에서 NIC(네트워크 인터페이스 컨트롤러) 모드로 전환합니다.
현재 Bluefield-2를 DPU에서 NIC 모드로 전환하는 경우에만 지원됩니다. NIC 모드에서 DPU 모드로 전환하는 것은 지원되지 않습니다.
사전 요구 사항
- SR-IOV Network Operator가 설치되어 있습니다. 자세한 내용은 " SR-IOV Network Operator 설치"를 참조하십시오.
- Bluefield-2를 최신 펌웨어로 업데이트했습니다. 자세한 내용은 NVIDIA BlueField-2의 펌웨어를 참조하십시오.
프로세스
다음 명령을 입력하여 각 컴퓨팅 노드에 다음 레이블을 추가합니다. 각 컴퓨팅 노드에 대해 명령을 실행해야 합니다.
oc label node <node_name> node-role.kubernetes.io/sriov=
$ oc label node <node_name> node-role.kubernetes.io/sriov=Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음과 같습니다.
node_name- 컴퓨팅 노드의 이름을 나타냅니다.
SR-IOV Network Operator의 머신 구성 풀을 생성합니다. 예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음
machineconfig.yaml파일을 컴퓨팅 노드에 적용합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 모드로 전환하는 모든 노드에서 동일해야 합니다.
- 컴퓨팅 노드가 다시 시작될 때까지 기다립니다. 다시 시작한 후 컴퓨팅 노드의 Bluefield-2 네트워크 장치가 NIC 모드로 전환됩니다.
- 선택 사항: 최신 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.