다중 CNI 플러그인을 사용하여 OKE에 SR-IOV 사용 네트워크 인터페이스 컨테이너 앱 배치

소개

이 사용지침서에서는 고급 네트워킹 기능을 활용하여 Oracle Cloud Infrastructure Kubernetes Engine(OKE) 내의 가상 인스턴스 작업자 노드에 컨테이너화된 애플리케이션을 배포하는 방법을 살펴봅니다. 특히 컨테이너 네트워크 인터페이스에 대해 단일 루트 I/O 가상화(SR-IOV)를 사용으로 설정하고 컨테이너에 대해 다중 홈 네트워킹을 사용으로 설정하도록 다중 CNI 플러그인을 구성합니다.

SR-IOV와 Multus를 결합하면 AI, 머신 러닝 및 실시간 데이터 처리와 같은 특수 워크로드에 대한 대기 시간이 짧은 고성능 네트워킹을 달성할 수 있습니다. 이 자습서에서는 OKE 환경을 구성하고, SR-IOV가 사용으로 설정된 인터페이스로 작업자 노드를 배치하고, 다중 CNI를 사용하여 POD의 다중 네트워크 인터페이스를 관리하는 단계별 지침을 제공합니다. 고속 패킷 처리를 목표로 하거나 Kubernetes 네트워킹을 미세 조정해야 하는 경우 이 자습서에서는 시작할 도구와 지식을 제공합니다.

참고:

이 자습서를 게시할 때 SR-IOV CNI는 다중 CNI 플러그인과 함께 OKE 클러스터의 일부인 가상 인스턴스의 Pod 또는 컨테이너에서 사용할 수 없습니다.

이 자습서에서는 OKE 클러스터의 일부인 가상 인스턴스의 Pod 또는 컨테이너에서 실행되는 Pod 내에서 SR-IOV 사용 인터페이스를 사용하는 방법을 보여줍니다. 가상 인스턴스에 있는 VNIC(가상 네트워크 인터페이스 카드)를 Pod로 가져오며, SR-IOV CNI 플러그인이 전혀 사용되지 않는 Multus CNI 플러그인을 사용하여 사용할 수 있습니다.

SR-IOV CNI 플러그인은 다중 CNI 플러그인과 함께 OKE 클러스터의 일부인 베어메탈 인스턴스에서 지원됩니다. 이 튜토리얼의 범위를 벗어났습니다.

목표

Multus CNI 플러그인을 사용하여 SR-IOV가 사용으로 설정된 네트워크 인터페이스를 사용하여 OKE 내의 가상 인스턴스 작업자 노드에 컨테이너 앱을 배치합니다.

작업 1: 배스천, 운영자, 3개의 VM 워커 노드 및 Flannel CNI 플러그인을 사용하여 OKE 배치

OKE가 다음 설정으로 배치되었는지 확인합니다.

배스천
연산자
3 VM 워커 노드
Flannel CNI 플러그인

이 설정은 자습서에 자세히 설명되어 있습니다. Oracle Cloud Infrastructure Kubernetes Engine을 사용하여 Terraform으로 Kubernetes 클러스터 배포하기.

다음 이미지는 이 자습서 전체에서 작업할 구성요소에 대한 시각적 개요를 보여줍니다.

작업 2: 각 워커 노드에서 SR-IOV(하드웨어 지원) 네트워킹 사용

주: OKE 클러스터의 일부인 모든 작업자 노드에서 다음 단계를 수행해야 합니다.

다음 이미지는 이 자습서 전체에서 작업할 OKE 클러스터 내의 작업자 노드에 대한 시각적 개요를 보여줍니다.

인스턴스에서 SR-IOV 사용

SSH를 사용하여 인스턴스 또는 워커 노드에 로그인합니다.
1. lspci 명령을 실행하여 모든 VNIC에서 현재 사용되는 네트워크 드라이버를 확인합니다.
2. Virtio 네트워크 드라이버가 사용됩니다.
1. OCI 콘솔의 인스턴스 세부정보 페이지로 이동합니다.
2. 페이지 아래로 이동합니다.
3. NIC 연결 유형은 이제 PARAVIRTUALIZED입니다.
1. OCI 콘솔의 인스턴스 세부정보 페이지로 이동합니다.
2. 추가 작업을 누릅니다.
3. 편집을 누릅니다.
고급 옵션을 표시합니다를 누릅니다.
1. 실행 옵션을 누르고 네트워킹 유형으로 하드웨어 지원(SR-IOV) 네트워킹을 선택합니다.
2. 변경사항 저장를 누릅니다.
인스턴스 재부팅을 눌러 인스턴스 재부팅을 확인합니다.
인스턴스 상태가 STOPPING으로 변경되었습니다.
인스턴스 상태가 STARTING으로 변경되었습니다.
인스턴스 상태가 RUNNING으로 변경되었습니다.
1. 페이지 아래로 이동합니다.
2. NIC 연결 유형은 이제 VFIO입니다.
다음 이미지는 지금까지 구성한 내용을 시각적으로 보여줍니다.

작업 3: SR-IOV 사용 VNIC에 대한 새 서브넷 만들기

SR-IOV 사용 인터페이스에서 사용할 전용 서브넷을 생성합니다.

작업 3.1: 보안 목록 생성

다른 서브넷에 대한 보안 목록을 이미 사용하고 있지만 새로 생성된 SR-IOV 서브넷에 대한 전용 보안 목록도 필요합니다.

OCI 콘솔로 이동합니다.
1. 가상 클라우드 네트워크로 이동합니다.
2. 기존 VCN을 누릅니다.
1. 보안 목록을 누릅니다.
2. 보안 목록 생성을 누릅니다.
수신 규칙 1에 대해 다음 정보를 입력합니다.
1. 이름을 입력합니다.
2. CIDR을 소스 유형으로 선택합니다.
3. 0.0.0.0/0를 소스 CIDR로 입력합니다.
4. All Protocols(모든 프로토콜)를 IP Protocol로 선택합니다.
5. 페이지 아래로 이동합니다.
1. 송신 규칙 1에 대해 다음 정보를 입력합니다.
2. CIDR을 소스 유형으로 선택합니다.
3. 0.0.0.0/0를 소스 CIDR로 입력합니다.
4. All Protocols(모든 프로토콜)를 IP Protocol로 선택합니다.
5. 보안 목록 생성을 누릅니다.
새 보안 목록이 생성되었음을 알 수 있습니다.

작업 3.2: 서브넷 생성

가상 클라우드 네트워크 세부정보 페이지로 이동합니다.
1. 서브넷을 누릅니다.
2. OKE 환경에 대해 이미 생성된 기존 서브넷을 확인합니다.
3. 서브넷 생성을 누릅니다.
1. 이름을 입력합니다.
2. IPv4 CIDR Block을 입력합니다.
3. 페이지 아래로 이동합니다.
1. Private Subnet(개인 서브넷)을 선택합니다.
2. 페이지 아래로 이동합니다.
1. DHCP Options(DHCP 옵션)에 대해 Default DHCP Options(기본 DHCP 옵션)를 선택합니다.
2. 태스크 3.1에서 생성된 보안 목록을 선택합니다.
3. 서브넷 생성을 누릅니다.
네트 서브넷이 생성됩니다.
참고:
- 서브넷 자체에는 SR-IOV가 사용으로 설정된 기술 구성요소가 없습니다.
- 이 자습서에서는 SR-IOV 기술을 사용하여 트래픽을 전송할 수 있도록 표준 OCI 서브넷을 사용하고 있습니다.
다음 이미지는 지금까지 구성한 내용을 시각적으로 보여줍니다.

작업 4: 두번째 VNIC 연결 추가

다음 이미지는 작업자 노드에 두번째 VNIC를 추가하기 전에 작업자 노드 서브넷에 연결된 단일 VNIC가 있는 방법에 대한 시각적 개요를 보여줍니다.

작업자 노드에 두번째 VNIC 연결을 추가하기 전에 네트워크 보안 그룹을 만듭니다.

작업 4.1: NSG(네트워크 보안 그룹) 만들기

이미 다른 VNIC에 NSG를 사용하고 있지만 새로 생성된 VNIC에는 OKE 클러스터의 일부인 기존 가상 인스턴스에 추가하여 해당 부분을 Kubernetes 작업자 노드로 재생할 전용 NSG도 필요합니다. 이 인터페이스는 SR-IOV가 사용으로 설정된 VNIC입니다.

가상 클라우드 네트워크 세부정보 페이지로 이동합니다.
1. 네트워크 보안 그룹으로 이동합니다.
2. 네트워크 보안 그룹 생성을 누릅니다.
다음 규칙을 추가합니다.
1. 수신:
  - 소스 유형 허용: CIDR을 선택합니다.
  - 출처: 0.0.0.0/0를 입력합니다.
  - 대상: 대상을 비워 둡니다.
  - 프로토콜: 모든 프로토콜을 허용합니다.
2. 송신:
  - 소스 유형 허용: CIDR을 선택합니다.
  - 소스: 소스를 비워 둡니다.
  - 대상: 0.0.0.0/0를 입력합니다.
  - 프로토콜: 모든 프로토콜을 허용합니다.
NSG가 생성됩니다. OKE 클러스터의 각 워커 노드에 생성할 새(보조) VNIC에 이 VNIC를 적용합니다.

작업 4.2: VNIC 추가

각 가상 워커 노드 인스턴스로 이동하여 각 워커 노드에 두번째 VNIC를 추가합니다.
1. 각 가상 워커 노드 인스턴스로 이동하고 연결된 VNIC를 누릅니다.
2. 기존 VNIC가 이미 있습니다.
3. Create VNIC(VNIC 만들기)를 눌러 두번째 VNIC를 추가합니다.
1. 이름을 입력합니다.
2. VCN을 선택합니다.
3. 작업 3.2에서 만든 서브넷을 선택합니다.
4. 네트워크 보안 그룹을 사용하여 트래픽 제어를 선택합니다.
5. 작업 4.1에서 만든 NSG를 선택합니다.
6. 페이지 아래로 이동합니다.
1. Select Automatically assign private IPv4 address.
2. 변경사항 저장를 누릅니다.
두번째 VNIC가 생성되고 가상 워커 노드 인스턴스에 연결되며 서브넷에도 연결됩니다.
SSH를 사용하여 인스턴스 또는 워커 노드에 로그인합니다.
1. lspci 명령을 실행하여 모든 VNIC에서 현재 사용되는 네트워크 드라이버를 확인합니다.
2. Mellanox Technologies ConnectX Family mlx5Gen Virtual Function 네트워크 드라이버가 사용됩니다.
Mellanox Technologies ConnectX 제품군 mlx5Gen 가상 기능 네트워크 드라이버는 SR-IOV에서 사용하는 VF(가상 기능) 드라이버입니다. 따라서 VNIC는 VF를 사용하는 SR-IOV에 대해 사용으로 설정됩니다.
다음 이미지는 지금까지 구성한 내용을 시각적으로 보여줍니다.

작업 5: 기본 게이트웨이를 사용하여 새 두번째 VNIC에 IP 주소 지정

이제 두번째 VNIC가 작업 4에서 만들어졌으므로 IP 주소를 지정해야 합니다. 인스턴스에 두번째 인터페이스를 추가하는 경우 첫번째 인터페이스와 동일한 서브넷에 지정하거나 새 서브넷을 선택할 수 있습니다.

두번째 인터페이스에 대해 DHCP가 사용으로 설정되지 않았으므로 IP 주소를 수동으로 지정해야 합니다.

두번째 인터페이스에 대한 IP 주소를 지정하는 방법에는 여러 가지가 있습니다.

방법 1: OCI CLI(Oracle Cloud Infrastructure 명령행 인터페이스)(oci-utils 패키지)를 사용하여 OCI-network-config 명령을 사용하여 OCI 컴퓨트 인스턴스의 두번째 인터페이스에 IP 주소를 지정합니다.
방법 2: OCI CLI(oci-utils 패키지)를 사용하여 ocid 데몬을 사용하여 OCI 컴퓨트 인스턴스의 두번째 인터페이스에 IP 주소를 지정합니다.
방법 3: OCI_Multi_VNIC_Setup 스크립트를 사용합니다.
메소드 4: /etc/sysconfig/network-scripts/ 폴더에 새 VNIC에 대한 인터페이스 구성 파일을 수동으로 만듭니다.

모든 작업자 노드에 대해 보조 vNIC(ens5)에 IP 주소를 지정했습니다. 메소드 3을 사용하여 보조 vNIC(ens5)에 IP 주소를 지정했습니다. 두번째 VNIC에 IP 주소를 지정하는 방법에 대한 자세한 내용은 Assign an IP Address to a Second Interface on an Oracle Linux Instance을 참조하십시오.

IP 주소가 VNIC에 지정되면 두번째 VNIC의 IP 주소가 올바르게 구성되었는지 확인해야 합니다. 또한 모든 노드 풀 작업자 노드에서 SR-IOV를 사용으로 설정했는지 확인할 수 있습니다.

OKE 클러스터는 다음으로 구성됩니다.

노드 풀
NP1	1 x 워커 노드
NP2	3 x 작업자 노드

모든 노드 풀의 모든 워커 노드를 확인합니다.

작업 5.1: 노드 풀 1의 모든 노드 확인(`np1`)

OKE 클러스터에서 노드를 누릅니다.
첫번째 노드 풀(np1)을 누릅니다.
이 노드 풀의 일부인 워커 노드를 누릅니다.
1. NIC 연결 유형은 VFIO입니다. 즉, 이 가상 인스턴스 워커 노드에 대해 SR-IOV가 사용으로 설정됩니다.
2. 이 워커 노드에 대해 두번째 VNIC가 생성되고 연결됩니다.

작업 5.2: 노드 풀 2의 모든 노드 확인(`np2`)

노드를 하나씩 누르고 확인을 시작합니다.
1. NIC 연결 유형은 VFIO입니다. 즉, 이 가상 인스턴스 워커 노드에 대해 SR-IOV가 사용으로 설정됩니다.
2. 이 워커 노드에 대해 두번째 VNIC가 생성되고 연결됩니다.
노드 풀 2(np2) 요약 페이지로 이동합니다. 노드 풀에서 두번째 워커 노드를 누릅니다.
1. NIC 연결 유형은 VFIO입니다. 즉, 이 가상 인스턴스 워커 노드에 대해 SR-IOV가 사용으로 설정됩니다.
2. 이 워커 노드에 대해 두번째 VNIC가 생성되고 연결됩니다.
노드 풀 2(np2) 요약 페이지로 이동합니다. 노드 풀에서 세번째 워커 노드를 누릅니다.
1. NIC 연결 유형은 VFIO입니다. 즉, 이 가상 인스턴스 워커 노드에 대해 SR-IOV가 사용으로 설정됩니다.
2. 이 워커 노드에 대해 두번째 VNIC가 생성되고 연결됩니다.

SSH를 사용하여 Kubernetes Operator에 로그인합니다.

kubectl get nodes 명령을 실행하여 모든 워커 노드의 목록 및 IP 주소를 검색합니다.

[opc@o-sqrtga ~]$ kubectl get nodes
NAME           STATUS   ROLES   AGE   VERSION
10.0.112.134   Ready    node    68d   v1.30.1
10.0.66.97     Ready    node    68d   v1.30.1
10.0.73.242    Ready    node    68d   v1.30.1
10.0.89.50     Ready    node    68d   v1.30.1
[opc@o-sqrtga ~]$

모든 작업자 노드에 SSH를 쉽게 연결할 수 있도록 다음 테이블을 생성했습니다.

워커 노드 이름	ens3 IP	SSH 명령 작업 노드
cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0	10.0.112.134	`ssh -i id_rsa opc@10.0.112.134`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1	10.0.66.97	`ssh -i id_rsa opc@10.0.66.97`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0	10.0.73.242	`ssh -i id_rsa opc@10.0.73.242`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2	10.0.89.50	`ssh -i id_rsa opc@10.0.89.50`

모든 가상 작업자 노드에 SSH를 사용하기 전에 사용 가능한 개인 키가 올바른지 확인하십시오.
ssh -i <private key> opc@<ip-address> 명령을 실행하여 모든 작업자 노드로 SSH를 실행합니다.

cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 워커 노드에서 ip a 명령을 실행합니다.

IP 주소가 성공적으로 구성된 경우 ens5(두번째 VNIC)에 SR-IOV 인터페이스에 대해 작업 3.2에서 생성된 서브넷 범위의 IP 주소가 있습니다.

[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:59:58 brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.112.134/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 85530sec preferred_lft 85530sec
   inet6 fe80::17ff:fe00:5958/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:d4:a2 brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.30/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::8106:c09e:61fa:1d2a/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 3a:b7:fb:e6:2e:cf brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.0/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::38b7:fbff:fee6:2ecf/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether de:35:f5:51:85:5d brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.1/25 brd 10.244.1.127 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::dc35:f5ff:fe51:855d/64 scope link
      valid_lft forever preferred_lft forever
6: veth1cdaac17@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 76:e2:92:ad:37:40 brd ff:ff:ff:ff:ff:ff link-netns 1935ba66-34cc-4468-8abb-f66add46d08b
   inet6 fe80::74e2:92ff:fead:3740/64 scope link
      valid_lft forever preferred_lft forever
7: vethbcd391ab@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 9a:9a:0f:d6:48:17 brd ff:ff:ff:ff:ff:ff link-netns 3f02d5fd-596e-4b9f-8a35-35f2f946901b
   inet6 fe80::989a:fff:fed6:4817/64 scope link
      valid_lft forever preferred_lft forever
8: vethc15fa705@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 3a:d2:c8:66:d1:0b brd ff:ff:ff:ff:ff:ff link-netns f581b7f2-cfa0-46eb-b0aa-37001a11116d
   inet6 fe80::38d2:c8ff:fe66:d10b/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$

cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 워커 노드에서 ip a 명령을 실행합니다.

IP 주소가 성공적으로 구성된 경우 ens5(두번째 VNIC)에 SR-IOV 인터페이스에 대해 작업 3.2에서 생성된 서브넷 범위의 IP 주소가 있습니다.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:16:ca brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.66.97/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 85859sec preferred_lft 85859sec
   inet6 fe80::17ff:fe00:16ca/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:7b:4f brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.15/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::87eb:4195:cacf:a6da/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 02:92:e7:f5:8e:29 brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.128/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::92:e7ff:fef5:8e29/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether f6:08:06:e2:bc:9d brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.129/25 brd 10.244.1.255 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::f408:6ff:fee2:bc9d/64 scope link
      valid_lft forever preferred_lft forever
6: veth5db97290@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether c2:e0:b5:7e:ce:ed brd ff:ff:ff:ff:ff:ff link-netns 3682b5cd-9039-4931-aecc-b50d46dabaf1
   inet6 fe80::c0e0:b5ff:fe7e:ceed/64 scope link
      valid_lft forever preferred_lft forever
7: veth6fd818a5@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 3e:a8:7d:84:d3:b9 brd ff:ff:ff:ff:ff:ff link-netns 08141d6b-5ec0-4f3f-a312-a00b30f82ade
   inet6 fe80::3ca8:7dff:fe84:d3b9/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$

cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 워커 노드에서 ip a 명령을 실행합니다.

IP 주소가 성공적으로 구성된 경우 ens5(두번째 VNIC)에 SR-IOV 인터페이스에 대해 작업 3.2에서 생성된 서브넷 범위의 IP 주소가 있습니다.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:49:9c brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.73.242/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 86085sec preferred_lft 86085sec
   inet6 fe80::17ff:fe00:499c/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:b7:51 brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.14/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::bc31:aa09:4e05:9ab7/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 9a:c7:1b:30:e8:9a brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.0/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::98c7:1bff:fe30:e89a/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether 2a:2b:cb:fb:15:82 brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.1/25 brd 10.244.0.127 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::282b:cbff:fefb:1582/64 scope link
      valid_lft forever preferred_lft forever
6: veth06343057@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether ca:70:83:13:dc:ed brd ff:ff:ff:ff:ff:ff link-netns fb0f181f-7c3a-4fb6-8bf0-5a65d39486c1
   inet6 fe80::c870:83ff:fe13:dced/64 scope link
      valid_lft forever preferred_lft forever
7: veth8af17165@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether c6:a0:be:75:9b:d9 brd ff:ff:ff:ff:ff:ff link-netns c07346e6-33f5-4e80-ba5e-74f7487b5daa
   inet6 fe80::c4a0:beff:fe75:9bd9/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$

cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 워커 노드에서 ip a 명령을 실행합니다.

IP 주소가 성공적으로 구성된 경우 ens5(두번째 VNIC)에 SR-IOV 인터페이스에 대해 작업 3.2에서 생성된 서브넷 범위의 IP 주소가 있습니다.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:ac:7c brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.89.50/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 86327sec preferred_lft 86327sec
   inet6 fe80::17ff:fe00:ac7c/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:4c:0d brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.16/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::91eb:344e:829e:35de/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether aa:31:9f:d0:b3:3c brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.128/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::a831:9fff:fed0:b33c/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether b2:0d:c0:de:02:61 brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.129/25 brd 10.244.0.255 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::b00d:c0ff:fede:261/64 scope link
      valid_lft forever preferred_lft forever
6: vethb37e8987@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 7a:93:1d:2a:33:8c brd ff:ff:ff:ff:ff:ff link-netns ab3262ca-4a80-4b02-a39f-4209d003f148
   inet6 fe80::7893:1dff:fe2a:338c/64 scope link
      valid_lft forever preferred_lft forever
7: veth73a651ce@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether ae:e4:97:89:ba:6e brd ff:ff:ff:ff:ff:ff link-netns 9307bfbd-8165-46bf-916c-e1180b6cbd83
   inet6 fe80::ace4:97ff:fe89:ba6e/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$

모든 IP 주소가 두번째 VNIC(ens5)에 구성되었는지 확인했습니다. 정보를 사용하여 다음 표를 만들 수 있습니다.

ens3 IP	ens3 GW	ens5 IP	ens5 GW
10.0.112.134	10.0.64.1	10.0.3.30/27	10.0.3.1
10.0.66.97	10.0.64.1	10.0.3.15/27	10.0.3.1
10.0.73.242	10.0.64.1	10.0.3.14/27	10.0.3.1
10.0.89.50	10.0.64.1	10.0.3.16/27	10.0.3.1

다음 이미지는 지금까지 구성한 내용을 시각적으로 보여줍니다.

작업 6: 워커 노드에 메타 플러그인 CNI(다중 CNI) 설치

멀티스 CNI는 여러 네트워크 인터페이스를 하나의 포드에 연결할 수 있는 Kubernetes 컨테이너 네트워크 인터페이스(CNI) 플러그인입니다.

Multus CNI 작동 방식

메타 플러그인으로 작동: Multus는 네트워킹 자체를 제공하지 않고 대신 다른 CNI 플러그인을 호출합니다.
다중 네트워크 인터페이스 생성: 각 포드는 여러 CNI 플러그인(예: Flannel, Calico, SR-IOV)을 결합하여 둘 이상의 네트워크 인터페이스를 가질 수 있습니다.
구성 파일 사용: 기본 네트워크는 기본 CNI를 사용하여 설정되고 추가 네트워크는 CRD(사용자 정의 리소스 정의)를 기반으로 연결됩니다.

왜 Multus CNI가 필요한가

다중 네트워크 격리: 별도의 관리 및 데이터 평면이 필요한 작업 로드에 유용합니다.
고성능 네트워킹: SR-IOV 또는 DPDK를 사용하여 직접 하드웨어 액세스를 사용으로 설정합니다.
파드를 위한 멀티홈: 여러 네트워크 인터페이스가 필수적인 네트워크 기능 가상화(NFV) 및 통신 사용 사례를 지원합니다.

작업 6.1: 씬 설치 방법을 사용하여 멀티스 CNI 설치

Kubernetes Operator에 SSH로 접속합니다.
1. 다음 명령을 실행하여 Multus Git 라이브러리를 복제합니다.
```
git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
```
2. Thin 설치 방법을 사용하여 Multus 데몬 세트를 설치하려면 다음 명령을 실행합니다.
```
kubectl apply -f deployments/multus-daemonset.yml && cd ..
```

다중 데몬 세트에서 수행하는 작업

Multus 데몬 세트를 시작합니다. 그러면 /opt/cni/bin의 각 노드에 Multus 바이너리를 배치하는 각 노드에서 포드가 실행됩니다.
/etc/cni/net.d에서 사전순(알파벳순) 첫번째 구성 파일을 읽고 /etc/cni/net.d/00-multus.conf로 각 노드에서 Multus에 대한 새 구성 파일을 만듭니다. 이 구성은 자동 생성되며 기본 네트워크 구성(알파벳순으로 첫번째 구성으로 간주됨)을 기반으로 합니다.
Kubernetes API에 액세스하기 위해 Multus에 대한 인증 정보를 사용하여 각 노드에 /etc/cni/net.d/multus.d라는 디렉토리를 생성합니다.

작업 6.2: Multus 설치 검증

Kubernetes Operator에서 다음 명령을 실행하여 Multus 데몬 세트가 모든 작업자 노드에 설치되어 있는지 검증합니다.
```
kubectl get pods --all-namespaces | grep -i multus
```
또한 다중 데몬 세트가 작업자 노드 자체에 설치되어 있는지 확인할 수 있습니다.
1. ssh -i id_rsa opc@10.0.112.134 명령을 실행하여 다음 명령으로 작업자 노드로 SSH를 실행합니다.
2. cd /etc/cni/net.d/ 명령을 실행하여 다음 명령으로 디렉토리를 변경합니다.
3. ls -l 명령을 실행하여 다음 명령으로 디렉토리 출력을 나열합니다.
4. 00-multus.conf 및 multus.d 파일이 나열됩니다.
1. sudo more 00-multus.conf 명령을 실행하여 00-multus.conf 파일의 내용을 확인합니다.
2. 00-multus.conf 파일의 내용을 확인합니다.

작업 7: Pod에 네트워크 인터페이스 연결

이 작업에서는 컨테이너 인터페이스를 이 VNIC에 매핑하거나 연결합니다.

POD에 추가 인터페이스를 연결하려면 인터페이스를 연결하기 위한 구성이 필요합니다.

이것은 NetworkAttachmentDefinition 종류의 사용자 정의 리소스에서 캡슐화됩니다.
이 구성은 기본적으로 사용자정의 리소스로 패키지화된 CNI 구성입니다.

이 작업을 수행하기 위해 Multus와 함께 사용할 수있는 몇 가지 CNI 플러그인이 있습니다. 자세한 내용은 플러그인 개요를 참조하십시오.

여기에 설명된 접근 방식에서 목표는 단일 포드에 대해서만 SR-IOV VF(가상 기능)를 제공하는 것입니다. 따라서 포드는 간섭이나 그 사이의 계층 없이 기능을 활용할 수 있습니다.
VF에 대한 Pod 배타적 액세스 권한을 부여하기 위해 인터페이스를 Pod의 네임스페이스로 이동할 수 있는 호스트-장치 플러그인을 활용하여 배타적 액세스 권한을 가질 수 있습니다. 자세한 내용은 host-device를 참조하십시오.

다음 예에서는 노드에 추가된 보조 ens5 인터페이스를 구성하는 NetworkAttachmentDefinition 객체를 보여줍니다.

ipam 플러그인 구성은 이러한 인터페이스에 대해 IP 주소를 관리하는 방법을 결정합니다.
이 예에서는 OCI에서 보조 인터페이스에 지정한 것과 동일한 IP 주소를 사용하려고 하므로 적절한 경로와 함께 정적 ipam 구성을 사용합니다.
ipam 구성은 보다 유연한 구성을 위해 host-local 또는 dhcp와 같은 다른 방법도 지원합니다.

작업 7.1: 네트워크 연결 정의 생성

NetworkAttachmentDefinition는 네트워크 연결(예: 포드의 보조 인터페이스)을 설정하는 데 사용됩니다.

NetworkAttachmentDefinition를 구성하는 다음 두 가지 방법이 있습니다.

NetworkAttachmentDefinition(JSON CNI 구성 포함)
NetworkAttachmentDefinition(CNI 구성 파일 포함)

주: 이 자습서에서는 CNI 구성 파일을 사용하는 메소드를 사용하려고 합니다.

작업자 노드가 4개 있으며 각 작업자 노드에는 컨테이너(pod)의 인터페이스에 매핑할 두번째 VNIC가 있습니다.

다음 명령을 실행하여 모든 작업자 노드 및 해당 VNIC에 대한 CNI 구성 파일을 만듭니다.

ens3	ens5	name	네트워크	nano 명령
10.0.112.134	10.0.3.30/27	스리오브-vnic-1	10.0.3.0/27	`sudo nano sriov-vnic-1.yaml`
10.0.66.97	10.0.3.15/27	스리오브-vnic-2	10.0.3.0/27	`sudo nano sriov-vnic-2.yaml`
10.0.73.242	10.0.3.14/27	스리오브-vnic-3	10.0.3.0/27	`sudo nano sriov-vnic-3.yaml`
10.0.89.50	10.0.3.16/27	스리오브-vnic-4	10.0.3.0/27	`sudo nano sriov-vnic-4.yaml`

Kubernetes 연산자에서 다음 단계를 수행합니다. sudo nano sriov-vnic-1.yaml 명령을 사용하여 첫번째 워커 노드에 대한 새 YAML 파일을 생성합니다.
- 이름이 고유하고 설명적인지 확인하십시오. 이 예에서는 sriov-vnic-1를 사용합니다.
- 방금 추가한 두번째 어댑터의 IP 주소(ens5)를 사용합니다.
- dst network도 올바른지 확인하고 이것이 작업 3.2에서 생성된 서브넷과 동일한지 확인하십시오.
sriov-vnic-1.yaml:
```
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-1
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.30/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'
```

sudo nano sriov-vnic-2.yaml 명령을 사용하여 두번째 워커 노드에 대한 새 YAML 파일을 생성합니다.

sriov-vnic-2.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-2
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.15/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

sudo nano sriov-vnic-3.yaml 명령을 사용하여 세번째 워커 노드에 대한 새 YAML 파일을 생성합니다.

sriov-vnic-3.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-3
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.14/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

sudo nano sriov-vnic-4.yaml 명령을 사용하여 네번째 worker 노드에 대한 새 YAML 파일을 생성합니다.

sriov-vnic-4.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-4
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.16/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

작업자 노드에 NetworkAttachmentDefinition를 적용합니다.
- 첫번째 노드에 대해 kubectl apply -f sriov-vnic-1.yaml 명령을 실행합니다.
- 두번째 노드에 대해 kubectl apply -f sriov-vnic-2.yaml 명령을 실행합니다.
- 세번째 노드에 대해 kubectl apply -f sriov-vnic-3.yaml 명령을 실행합니다.
- 네번째 노드에 대해 kubectl apply -f sriov-vnic-4.yaml 명령을 실행합니다.
NetworkAttachmentDefinition가 올바르게 적용된 경우 출력과 유사한 내용이 표시됩니다.
```
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-1.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-2.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-3.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-4.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 created
[opc@o-sqrtga ~]$
```

kubectl get network-attachment-definitions.k8s.cni.cncf.io 명령을 실행하여 NetworkAttachmentDefinitions가 올바르게 적용되었는지 확인합니다.

[opc@o-sqrtga ~]$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME           AGE
sriov-vnic-1   96s
sriov-vnic-2   72s
sriov-vnic-3   60s
sriov-vnic-4   48s
[opc@o-sqrtga ~]$

kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 -o yaml 명령을 실행하여 첫번째 워커 노드에 대해 적용된 NetworkAttachmentDefinition를 가져옵니다.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-1","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.30/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:03:55Z"
generation: 1
name: sriov-vnic-1
namespace: default
resourceVersion: "22915413"
uid: 2d529130-2147-4f49-9d78-4e5aa12aea62
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.30/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 -o yaml 명령을 실행하여 두번째 워커 노드에 대해 적용된 NetworkAttachmentDefinition를 가져옵니다.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-2","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.15/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:19Z"
generation: 1
name: sriov-vnic-2
namespace: default
resourceVersion: "22915508"
uid: aec5740c-a093-43d3-bd6a-2209ee9e5c96
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.15/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 -o yaml 명령을 실행하여 세번째 워커 노드에 대해 적용된 NetworkAttachmentDefinition를 가져옵니다.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-3","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.14/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:31Z"
generation: 1
name: sriov-vnic-3
namespace: default
resourceVersion: "22915558"
uid: 91b970ff-328f-4b6b-a0d8-7cdd07d7bca3
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.14/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 -o yaml 명령을 실행하여 네번째 워커 노드에 대해 적용된 NetworkAttachmentDefinition를 가져옵니다.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-4","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.16/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:43Z"
generation: 1
name: sriov-vnic-4
namespace: default
resourceVersion: "22915607"
uid: 383fd3f0-7e5e-46ec-9997-29cbc9a2dcea
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.16/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'
[opc@o-sqrtga ~]$

다음 이미지는 지금까지 구성한 내용을 시각적으로 보여줍니다.

작업 7.2: `NetworkDefinitionAttachment`가 연결된 상태로 Pod 생성

이 작업에서는 NetworkAttachmentDefinitions를 실제 컨테이너 또는 POD에 연결합니다.

다음 표에서는 워커 노드에서 호스트할 Pod에 대한 매핑을 생성했습니다.

근로자(기본) 노드 IP	ens5	name	POD명	완료됨
10.0.112.134	10.0.3.30/27	스리오브-vnic-1	testpod1	예
10.0.66.97	10.0.3.15/27	스리오브-vnic-2	testpod2	예
10.0.73.242	10.0.3.14/27	스리오브-vnic-3	testpod3	예
10.0.89.50	10.0.3.16/27	스리오브-vnic-4	testpod4	예

작업 7.3: 노드 유사성이 있는 Pod 생성

기본적으로 Kubernetes는 포드를 배치할 위치(작업자 노드)를 결정합니다. 이 예에서는 NetworkAttachmentDefinition가 IP 주소에 바인드되고 이 IP 주소가 VNIC에 바인드되고 이 VNIC가 특정 워커 노드에 바인드되기 때문에 이 작업을 수행할 수 없습니다. 따라서 NetworkAttachmentDefinition를 Pod에 연결할 때 생성하려는 Pod가 원하는 워커 노드에서 작동하는지 확인해야 합니다.

이 작업을 수행하지 않으면 Pod에 대해 IP 주소를 사용할 수 있는 다른 위치에서 Pod가 종료될 수 있습니다. 따라서 Pod가 SR-IOV 사용 인터페이스를 사용하여 통신할 수 없습니다.

kubectl get nodes 명령을 사용하여 사용 가능한 모든 노드를 가져옵니다.

[opc@o-sqrtga ~]$ kubectl get nodes
NAME           STATUS   ROLES   AGE   VERSION
10.0.112.134   Ready    node    68d   v1.30.1
10.0.66.97     Ready    node    68d   v1.30.1
10.0.73.242    Ready    node    68d   v1.30.1
10.0.89.50     Ready    node    68d   v1.30.1
[opc@o-sqrtga ~]$

kubectl label node 10.0.112.134 node_type=testpod1 명령을 사용하여 작업자 노드 1에 레이블을 지정합니다.
kubectl label node 10.0.66.97 node_type=testpod2 명령을 사용하여 작업자 노드 2에 레이블을 지정합니다.
kubectl label node 10.0.73.242 node_type=testpod3 명령을 사용하여 작업자 노드 3에 레이블을 지정합니다.
kubectl label node 10.0.89.50 node_type=testpod4 명령을 사용하여 작업자 노드 4에 레이블을 지정합니다.

[opc@o-sqrtga ~]$ kubectl label node 10.0.112.134 node_type=testpod1
node/10.0.112.134 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.73.242 node_type=testpod3
node/10.0.73.242 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.66.97 node_type=testpod2
node/10.0.66.97 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.89.50 node_type=testpod4
node/10.0.89.50 labeled
[opc@o-sqrtga ~]$

다음 이미지는 지금까지 구성한 내용을 시각적으로 보여줍니다.

sudo nano testpod1-v2.yaml 명령을 사용하여 testpod1에 대한 YAML 파일을 생성합니다.

앞에서 생성한 NetworkAttachmentDefinition(sriov-vnic-1)를 이 테스트 POD에 바인드하는 annotations 섹션에 유의하십시오.
테스트 POD를 레이블이 testpod1인 특정 워커 노드에 바인드하는 spec:affinity:nodeAffinity 섹션을 확인합니다.

sudo nano testpod1-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod1
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-1
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod1
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

sudo nano testpod2-v2.yaml 명령을 사용하여 testpod2에 대한 YAML 파일을 생성합니다.

앞에서 생성한 NetworkAttachmentDefinition(sriov-vnic-2)를 이 테스트 POD에 바인드하는 annotations 섹션에 유의하십시오.
테스트 POD를 레이블이 testpod2인 특정 워커 노드에 바인드하는 spec:affinity:nodeAffinity 섹션을 확인합니다.

sudo nano testpod2-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod2
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-2
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod2
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

sudo nano testpod3-v2.yaml 명령을 사용하여 testpod3에 대한 YAML 파일을 생성합니다.

앞에서 생성한 NetworkAttachmentDefinition(sriov-vnic-3)를 이 테스트 POD에 바인드하는 annotations 섹션에 유의하십시오.
테스트 POD를 레이블이 testpod3인 특정 워커 노드에 바인드하는 spec:affinity:nodeAffinity 섹션을 확인합니다.

sudo nano testpod3-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod3
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-3
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod3
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

sudo nano testpod4-v2.yaml 명령을 사용하여 testpod4에 대한 YAML 파일을 만듭니다.
- 앞에서 생성한 NetworkAttachmentDefinition(sriov-vnic-4)를 이 테스트 POD에 바인드하는 annotations 섹션에 유의하십시오.
- 테스트 POD를 레이블이 testpod4인 특정 워커 노드에 바인드하는 spec:affinity:nodeAffinity 섹션을 확인합니다.
```
sudo nano testpod4-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod4
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-4
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod4
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]
```
- kubectl apply -f testpod1-v2.yaml 명령을 사용하여 YAML 파일을 적용하여 testpod1를 만듭니다.
- kubectl apply -f testpod2-v2.yaml 명령을 사용하여 YAML 파일을 적용하여 testpod2를 만듭니다.
- kubectl apply -f testpod3-v2.yaml 명령을 사용하여 YAML 파일을 적용하여 testpod3를 만듭니다.
- kubectl apply -f testpod4-v2.yaml 명령을 사용하여 YAML 파일을 적용하여 testpod4를 만듭니다.
```
[opc@o-sqrtga ~]$ kubectl apply -f testpod1-v2.yaml
pod/testpod1 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod2-v2.yaml
pod/testpod2 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod3-v2.yaml
pod/testpod3 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod4-v2.yaml
pod/testpod4 created
[opc@o-sqrtga ~]$
```

kubectl get pod 명령을 사용하여 테스트 포드가 만들어졌는지 확인합니다. 모든 테스트 포드가 생성되고 Running STATUS가 있습니다.

[opc@o-sqrtga ~]$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-576c6b7b6-6fn6f   1/1     Running   3          40d
my-nginx-576c6b7b6-k9wwc   1/1     Running   3          40d
my-nginx-576c6b7b6-z8xkd   1/1     Running   6          40d
mysql-6d7f5d5944-dlm78     1/1     Running   12         35d
testpod1                   1/1     Running   0          2m29s
testpod2                   1/1     Running   0          2m17s
testpod3                   1/1     Running   0          2m5s
testpod4                   1/1     Running   0          111s
[opc@o-sqrtga ~]$

testpod1가 kubectl get pod testpod1 -o wide 명령을 사용하여 레이블이 testpod1인 워커 노드 10.0.112.134에서 실행 중인지 확인합니다.

[opc@o-sqrtga ~]$ kubectl get pod testpod1 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE           NOMINATED NODE   READINESS GATES
testpod1   1/1     Running   0          3m41s   10.244.1.6   10.0.112.134   <none>           <none>

testpod2가 kubectl get pod testpod2 -o wide 명령을 사용하여 레이블이 testpod2인 워커 노드 10.0.66.97에서 실행 중인지 확인합니다.

[opc@o-sqrtga ~]$ kubectl get pod testpod2 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
testpod2   1/1     Running   0          3m33s   10.244.1.133   10.0.66.97   <none>           <none>

testpod3가 kubectl get pod testpod3 -o wide 명령을 사용하여 레이블이 testpod3인 워커 노드 10.0.73.242에서 실행 중인지 확인합니다.

[opc@o-sqrtga ~]$ kubectl get pod testpod3 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE          NOMINATED NODE   READINESS GATES
testpod3   1/1     Running   0          3m25s   10.244.0.5   10.0.73.242   <none>           <none>

testpod4가 kubectl get pod testpod4 -o wide 명령을 사용하여 레이블이 testpod4인 워커 노드 10.0.89.50에서 실행 중인지 확인합니다.

[opc@o-sqrtga ~]$ kubectl get pod testpod4 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
testpod4   1/1     Running   0          3m22s   10.244.0.133   10.0.89.50   <none>           <none>

다음 이미지는 지금까지 구성한 내용을 시각적으로 보여줍니다.

작업 7.4: 테스트 포드의 IP 주소 확인

kubectl exec -it testpod1 -- ip addr show 명령을 사용하여 net1 pod 인터페이스에 대한 testpod1의 IP 주소를 확인하십시오.

net1 인터페이스의 IP 주소는 10.0.3.30/27입니다.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether ca:28:e4:5f:66:c4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.0.132/25 brd 10.244.0.255 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::c828:e4ff:fe5f:66c4/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:4c:0d brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.30/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:4c0d/64 scope link
	valid_lft forever preferred_lft forever

kubectl exec -it testpod2 -- ip addr show 명령을 사용하여 net1 pod 인터페이스에 대한 testpod2의 IP 주소를 확인하십시오.

net1 인터페이스의 IP 주소는 10.0.3.15/27입니다.

[opc@o-sqrtga ~]$ kubectl exec -it testpod2 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether da:ce:84:22:fc:29 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.1.132/25 brd 10.244.1.255 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::d8ce:84ff:fe22:fc29/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:7b:4f brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.15/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:7b4f/64 scope link
	valid_lft forever preferred_lft forever

kubectl exec -it testpod3 -- ip addr show 명령을 사용하여 net1 pod 인터페이스에 대한 testpod3의 IP 주소를 확인하십시오.

net1 인터페이스의 IP 주소는 10.0.3.14/27입니다.

[opc@o-sqrtga ~]$ kubectl exec -it testpod3 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether de:f2:81:10:04:b2 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.0.4/25 brd 10.244.0.127 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::dcf2:81ff:fe10:4b2/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:b7:51 brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.14/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:b751/64 scope link
	valid_lft forever preferred_lft forever

kubectl exec -it testpod4 -- ip addr show 명령을 사용하여 net1 pod 인터페이스에 대한 testpod4의 IP 주소를 확인하십시오.

net1 인터페이스의 IP 주소는 10.0.3.16/27입니다.

[opc@o-sqrtga ~]$ kubectl exec -it testpod4 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether ea:63:eb:57:9c:99 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.1.5/25 brd 10.244.1.127 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::e863:ebff:fe57:9c99/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:d4:a2 brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.16/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:d4a2/64 scope link
	valid_lft forever preferred_lft forever
[opc@o-sqrtga ~]$

다음 표는 모든 테스트 POD에 대한 net1 인터페이스의 모든 IP 주소에 대한 개요를 보여줍니다.

POD명	net1 IP
testpod1	10.0.3.30/27
testpod2	10.0.3.15/27
testpod3	10.0.3.14/27
testpod4	10.0.3.16/27

주: 이러한 IP 주소는 SR-IOV 사용 VNIC를 배치하기 위해 작업 3에서 생성된 OCI 서브넷과 동일한 범위에 있습니다.

작업 7.5: 작업자 노드의 IP 주소 확인

이제 테스트 POD net1 인터페이스에 IP 주소가 있으므로 이 IP 주소는 워커 노드에 있는 ens5 인터페이스의 IP 주소로 사용되었습니다. 이 IP 주소는 이제 ens5 워커 노드 인터페이스에서 net1 테스트 POD 인터페이스로 이동됩니다.

ssh -i id_rsa opc@10.0.112.134 명령을 사용하여 첫번째 워커 노드로 SSH를 연결합니다.

ip a 명령을 사용하여 모든 인터페이스의 IP 주소를 가져옵니다.
ens5 인터페이스가 워커 노드에서 제거되었습니다.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.112.134
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 20:42:19 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:59:58 brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.112.134/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82180sec preferred_lft 82180sec
	inet6 fe80::17ff:fe00:5958/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 3a:b7:fb:e6:2e:cf brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.0/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::38b7:fbff:fee6:2ecf/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether de:35:f5:51:85:5d brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.1/25 brd 10.244.1.127 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::dc35:f5ff:fe51:855d/64 scope link
	valid_lft forever preferred_lft forever
6: veth1cdaac17@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 76:e2:92:ad:37:40 brd ff:ff:ff:ff:ff:ff link-netns 1935ba66-34cc-4468-8abb-f66add46d08b
	inet6 fe80::74e2:92ff:fead:3740/64 scope link
	valid_lft forever preferred_lft forever
7: vethbcd391ab@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 9a:9a:0f:d6:48:17 brd ff:ff:ff:ff:ff:ff link-netns 3f02d5fd-596e-4b9f-8a35-35f2f946901b
	inet6 fe80::989a:fff:fed6:4817/64 scope link
	valid_lft forever preferred_lft forever
8: vethc15fa705@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 3a:d2:c8:66:d1:0b brd ff:ff:ff:ff:ff:ff link-netns f581b7f2-cfa0-46eb-b0aa-37001a11116d
	inet6 fe80::38d2:c8ff:fe66:d10b/64 scope link
	valid_lft forever preferred_lft forever
9: vethc663e496@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 7e:0b:bb:5d:49:8c brd ff:ff:ff:ff:ff:ff link-netns d3993135-0f2f-4b06-b16d-31d659f8230d
	inet6 fe80::7c0b:bbff:fe5d:498c/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ exit
logout
Connection to 10.0.112.134 closed.

ssh -i id_rsa opc@10.0.66.97 명령을 사용하여 두번째 워커 노드에 SSH로 접속합니다.

ip a 명령을 사용하여 모든 인터페이스의 IP 주소를 가져옵니다.
ens5 인터페이스가 워커 노드에서 제거되었습니다.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.66.97
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 19:47:55 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:16:ca brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.66.97/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82502sec preferred_lft 82502sec
	inet6 fe80::17ff:fe00:16ca/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 02:92:e7:f5:8e:29 brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.128/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::92:e7ff:fef5:8e29/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether f6:08:06:e2:bc:9d brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.129/25 brd 10.244.1.255 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::f408:6ff:fee2:bc9d/64 scope link
	valid_lft forever preferred_lft forever
6: veth5db97290@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether c2:e0:b5:7e:ce:ed brd ff:ff:ff:ff:ff:ff link-netns 3682b5cd-9039-4931-aecc-b50d46dabaf1
	inet6 fe80::c0e0:b5ff:fe7e:ceed/64 scope link
	valid_lft forever preferred_lft forever
7: veth6fd818a5@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 3e:a8:7d:84:d3:b9 brd ff:ff:ff:ff:ff:ff link-netns 08141d6b-5ec0-4f3f-a312-a00b30f82ade
	inet6 fe80::3ca8:7dff:fe84:d3b9/64 scope link
	valid_lft forever preferred_lft forever
8: veth26f6b686@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ae:bf:36:ca:52:cf brd ff:ff:ff:ff:ff:ff link-netns f533714a-69be-4b20-be30-30ba71494f7a
	inet6 fe80::acbf:36ff:feca:52cf/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ exit
logout
Connection to 10.0.66.97 closed.

ssh -i id_rsa opc@10.0.73.242 명령을 사용하여 SSH를 세번째 워커 노드로 설정합니다.

ip a 명령을 사용하여 모든 인터페이스의 IP 주소를 가져옵니다.
ens5 인터페이스가 워커 노드에서 제거되었습니다.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.73.242
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 20:08:31 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:49:9c brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.73.242/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82733sec preferred_lft 82733sec
	inet6 fe80::17ff:fe00:499c/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 9a:c7:1b:30:e8:9a brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.0/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::98c7:1bff:fe30:e89a/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether 2a:2b:cb:fb:15:82 brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.1/25 brd 10.244.0.127 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::282b:cbff:fefb:1582/64 scope link
	valid_lft forever preferred_lft forever
6: veth06343057@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ca:70:83:13:dc:ed brd ff:ff:ff:ff:ff:ff link-netns fb0f181f-7c3a-4fb6-8bf0-5a65d39486c1
	inet6 fe80::c870:83ff:fe13:dced/64 scope link
	valid_lft forever preferred_lft forever
7: veth8af17165@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether c6:a0:be:75:9b:d9 brd ff:ff:ff:ff:ff:ff link-netns c07346e6-33f5-4e80-ba5e-74f7487b5daa
	inet6 fe80::c4a0:beff:fe75:9bd9/64 scope link
	valid_lft forever preferred_lft forever
8: veth170b8774@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether e6:c9:42:60:8f:e7 brd ff:ff:ff:ff:ff:ff link-netns edef0c81-0477-43fa-b260-6b81626e7d87
	inet6 fe80::e4c9:42ff:fe60:8fe7/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ exit
logout
Connection to 10.0.73.242 closed.

ssh -i id_rsa opc@10.0.89.50 명령을 사용하여 네번째 워커 노드로 SSH를 실행합니다.

ip a 명령을 사용하여 모든 인터페이스의 IP 주소를 가져옵니다.
ens5 인터페이스가 워커 노드에서 제거되었습니다.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.89.50
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 19:49:27 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:ac:7c brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.89.50/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82976sec preferred_lft 82976sec
	inet6 fe80::17ff:fe00:ac7c/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether aa:31:9f:d0:b3:3c brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.128/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::a831:9fff:fed0:b33c/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether b2:0d:c0:de:02:61 brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.129/25 brd 10.244.0.255 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::b00d:c0ff:fede:261/64 scope link
	valid_lft forever preferred_lft forever
6: vethb37e8987@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 7a:93:1d:2a:33:8c brd ff:ff:ff:ff:ff:ff link-netns ab3262ca-4a80-4b02-a39f-4209d003f148
	inet6 fe80::7893:1dff:fe2a:338c/64 scope link
	valid_lft forever preferred_lft forever
7: veth73a651ce@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ae:e4:97:89:ba:6e brd ff:ff:ff:ff:ff:ff link-netns 9307bfbd-8165-46bf-916c-e1180b6cbd83
	inet6 fe80::ace4:97ff:fe89:ba6e/64 scope link
	valid_lft forever preferred_lft forever
8: veth42c3a604@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether f2:e6:ba:72:8f:b2 brd ff:ff:ff:ff:ff:ff link-netns a7eb561c-8182-49b2-9e43-7c52845620a7
	inet6 fe80::f0e6:baff:fe72:8fb2/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ exit
logout
Connection to 10.0.89.50 closed.
[opc@o-sqrtga ~]$

다음 이미지는 지금까지 구성한 내용을 시각적으로 보여줍니다.

작업 8: 여러 Pod 간 핑 테스트 수행

모든 Pod에는 SR-IOV 사용 VNIC가 연결된 OCI 서브넷의 IP 주소가 있습니다. 일부 핑 테스트를 수행하여 네트워크 접속이 제대로 작동하는지 확인할 수 있습니다.

다음 표는 Kubernetes Operator에서 테스트 POD에 연결하는 명령을 제공합니다.

핑 테스트를 수행하거나 경로 테이블을 보려면 이를 각 포드로 exec해야 합니다.

ens3	net1	name	POD명	명령
10.0.112.134	10.0.3.30/27	스리오브-vnic-1	testpod1	`kubectl exec -it testpod1 -- /bin/bash`
10.0.66.97	10.0.3.15/27	스리오브-vnic-2	testpod2	`kubectl exec -it testpod2 -- /bin/bash`
10.0.73.242	10.0.3.14/27	스리오브-vnic-3	testpod3	`kubectl exec -it testpod3 -- /bin/bash`
10.0.89.50	10.0.3.16/27	스리오브-vnic-4	testpod4	`kubectl exec -it testpod4 -- /bin/bash`

kubectl exec -it testpod1 -- route -n 명령을 실행하여 testpod1에 대한 Kubernetes 운영자 터미널에서 직접 경로 지정 테이블을 확인합니다.

testpod1의 경로 지정 테이블에는 SR-IOV 사용 인터페이스인 eth0 및 net1에 대한 기본 게이트웨이가 있습니다.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.0.129    0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.0.129    255.255.0.0     UG    0      0        0 eth0
10.244.0.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

kubectl exec -it testpod2 -- route -n 명령을 실행하여 testpod2에 대한 Kubernetes 운영자 터미널에서 직접 경로 지정 테이블을 확인합니다.

testpod2의 경로 지정 테이블에는 SR-IOV 사용 인터페이스인 eth0 및 net1에 대한 기본 게이트웨이가 있습니다.

[opc@o-sqrtga ~]$ kubectl exec -it testpod2 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.1.129    0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.1.129    255.255.0.0     UG    0      0        0 eth0
10.244.1.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

kubectl exec -it testpod3 -- route -n 명령을 실행하여 testpod3에 대한 Kubernetes 운영자 터미널에서 직접 경로 지정 테이블을 확인합니다.

testpod3의 경로 지정 테이블에는 SR-IOV 사용 인터페이스인 eth0 및 net1에 대한 기본 게이트웨이가 있습니다.

[opc@o-sqrtga ~]$ kubectl exec -it testpod3 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.0.1      0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
10.244.0.0      10.244.0.1      255.255.0.0     UG    0      0        0 eth0

kubectl exec -it testpod4 -- route -n 명령을 실행하여 testpod4에 대한 Kubernetes 운영자 터미널에서 직접 경로 지정 테이블을 확인합니다.

testpod4의 경로 지정 테이블에는 SR-IOV 사용 인터페이스인 eth0 및 net1에 대한 기본 게이트웨이가 있습니다.

[opc@o-sqrtga ~]$ kubectl exec -it testpod4 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.1.1      0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.1.1      255.255.0.0     UG    0      0        0 eth0
10.244.1.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
[opc@o-sqrtga ~]$

테스트 POD에서 직접 Kubernetes Operator의 핑 테스트를 수행하려면 ping 명령이 필요합니다.

다음 표에서는 모든 테스트 POD에 대해 모든 Ping 명령을 제공했습니다. 이 명령은 특정 테스트 포드에서 net1 IP 주소를 포함한 다른 모든 테스트 포드로 핑합니다.

소스 POD 이름	명령
testpod1	`kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4`
testpod2	`kubectl exec -it testpod2 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.16 -c 4`
testpod3	`kubectl exec -it testpod3 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.16 -c 4`
testpod4	`kubectl exec -it testpod4 -- ping -I net1 10.0.3.16 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.14 -c 4`

주: 이 예에서는 testpod1를 사용하여 다른 모든 테스트 POD net1 IP 주소를 ping합니다.

kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4 명령을 실행하여 testpod1에서 testpod1로 ping합니다.

핑에는 4 packets transmitted, 4 received, 0% packet loss가 있습니다. 그래서 핑은 성공적이다.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4
PING 10.0.3.30 (10.0.3.30) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.30: icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from 10.0.3.30: icmp_seq=2 ttl=64 time=0.024 ms
64 bytes from 10.0.3.30: icmp_seq=3 ttl=64 time=0.037 ms
64 bytes from 10.0.3.30: icmp_seq=4 ttl=64 time=0.026 ms

--- 10.0.3.30 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3087ms
rtt min/avg/max/mdev = 0.024/0.032/0.043/0.009 ms

kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4 명령을 실행하여 testpod1에서 testpod2로 ping합니다.

핑에는 4 packets transmitted, 4 received, 0% packet loss가 있습니다. 그래서 핑은 성공적이다.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4
PING 10.0.3.15 (10.0.3.15) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.15: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from 10.0.3.15: icmp_seq=2 ttl=64 time=0.113 ms
64 bytes from 10.0.3.15: icmp_seq=3 ttl=64 time=0.114 ms
64 bytes from 10.0.3.15: icmp_seq=4 ttl=64 time=0.101 ms

--- 10.0.3.15 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3109ms
rtt min/avg/max/mdev = 0.101/0.177/0.383/0.119 ms

kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4 명령을 실행하여 testpod1에서 testpod3로 ping합니다.

핑에는 4 packets transmitted, 4 received, 0% packet loss가 있습니다. 그래서 핑은 성공적이다.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4
PING 10.0.3.14 (10.0.3.14) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.14: icmp_seq=1 ttl=64 time=0.399 ms
64 bytes from 10.0.3.14: icmp_seq=2 ttl=64 time=0.100 ms
64 bytes from 10.0.3.14: icmp_seq=3 ttl=64 time=0.130 ms
64 bytes from 10.0.3.14: icmp_seq=4 ttl=64 time=0.124 ms

--- 10.0.3.14 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3057ms
rtt min/avg/max/mdev = 0.100/0.188/0.399/0.122 ms

kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4 명령을 실행하여 testpod1에서 testpod4로 ping합니다.

핑에는 4 packets transmitted, 4 received, 0% packet loss가 있습니다. 그래서 핑은 성공적이다.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4
PING 10.0.3.16 (10.0.3.16) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.16: icmp_seq=1 ttl=64 time=0.369 ms
64 bytes from 10.0.3.16: icmp_seq=2 ttl=64 time=0.154 ms
64 bytes from 10.0.3.16: icmp_seq=3 ttl=64 time=0.155 ms
64 bytes from 10.0.3.16: icmp_seq=4 ttl=64 time=0.163 ms

--- 10.0.3.16 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3110ms
rtt min/avg/max/mdev = 0.154/0.210/0.369/0.092 ms
[opc@o-sqrtga ~]$

주: 다른 모든 테스트 POD에 대한 다른 모든 Ping 출력은 포함되지 않았지만 아이디어를 얻을 수 있습니다.

다음 이미지는 지금까지 구성한 내용을 시각적으로 보여줍니다.

작업 9: (선택 사항) 다중 인터페이스로 Pod 배치

지금까지는 하나의 VNIC(SR-IOV 지원)만 준비하고 이 VNIC를 Pod로 이동했습니다. 우리는 네 가지 다른 테스트 포드를 위해 이것을했습니다.

이제 특정 포드에 더 많은 VNIC를 추가하거나 이동하려면 어떻게 해야 할까요? 다음 단계를 반복해야 합니다.

새 OCI 서브넷을 생성합니다.
새 VNIC를 만들고 IP 주소를 지정합니다.
새 NetworkAttachmentDefinitions를 생성합니다.
새 주석을 추가하여 테스트 pod YAML 파일을 업데이트합니다.

이 작업에서는 추가 서브넷인 VNIC를 만들고, IP 주소와 NetworkAttachmentDefinition를 지정하고, testpod1에 대한 Pod 생성 YAML 파일에 추가하는 예제를 찾을 수 있습니다.

네트워크 10.0.4.0/27에서 IP 주소가 10.0.4.29/27인 새 인터페이스 ens6에 대한 NetworkAttachmentDefinition입니다.

이는 네트워크 10.0.3.0/27의 IP 주소 10.0.3.30/27를 사용하는 인터페이스 ens5에 대해 이전보다 NetworkAttachmentDefinition입니다.

sriov-vnic-2-new.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-2-new
spec:
config: '{
		"cniVersion": "0.3.1",
		"type": "host-device",
		"device": "ens6",
		"ipam": {
				"type": "static",
				"addresses": [
					{
						"address": "10.0.4.29/27",
						"gateway": "0.0.0.0"
					}
				],
				"routes": [
					{ "dst": "10.0.4.0/27", "gw": "0.0.0.0" }
				]
			}
		}'

testpod1에 대한 (업데이트된) YAML 파일입니다.

새 NetworkAttachmentDefinition; sriov-vnic-2-new가 참조되는 annotations의 추가 행에 유의하십시오.

sudo nano testpod1-v3.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod1
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-1
	k8s.v1.cni.cncf.io/networks: sriov-vnic-2-new
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod1
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

작업 10: 모든 Pod 배치 제거 및 `NetworkAttachmentDefinitions`

처음부터 다시 시작하거나 NetworkAttachmentDefinitions로 컨테이너를 정리하려면 다음 단계를 수행합니다.

kubectl get pod 명령을 사용하여 모든 포드를 가져옵니다.

[opc@o-sqrtga ~]$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-576c6b7b6-6fn6f   1/1     Running   3          105d
my-nginx-576c6b7b6-k9wwc   1/1     Running   3          105d
my-nginx-576c6b7b6-z8xkd   1/1     Running   6          105d
mysql-6d7f5d5944-dlm78     1/1     Running   12         100d
testpod1                   1/1     Running   0          64d
testpod2                   1/1     Running   0          64d
testpod3                   1/1     Running   0          64d
testpod4                   1/1     Running   0          64d
[opc@o-sqrtga ~]$

다음 명령을 사용하여 테스트 포드를 삭제합니다.

kubectl delete -f testpod1-v2.yaml

kubectl delete -f testpod2-v2.yaml

kubectl delete -f testpod3-v2.yaml

kubectl delete -f testpod4-v2.yaml

kubectl get network-attachment-definitions.k8s.cni.cncf.io 명령을 사용하여 모든 NetworkAttachmentDefinitions를 가져옵니다.

[opc@o-sqrtga ~]$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME           AGE
sriov-vnic-1   64d
sriov-vnic-2   64d
sriov-vnic-3   64d
sriov-vnic-4   64d
[opc@o-sqrtga ~]$

다음 명령을 사용하여 NetworkAttachmentDefinitions를 삭제합니다.

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4

VM 기반 Oracle Container Engine for Kubernetes 노드용 Multus를 사용하여 POD에 대한 SR-IOV 인터페이스 구성

승인

작성자 - Iwan Hoogendoorn(OCI 네트워크 전문가)

추가 학습 자원

docs.oracle.com/learn에서 다른 랩을 탐색하거나 Oracle Learning YouTube 채널에서 더 많은 무료 학습 콘텐츠에 액세스하세요. 또한 education.oracle.com/learning-explorer를 방문하여 Oracle Learning Explorer가 되십시오.

제품 설명서는 Oracle Help Center를 참조하십시오.

제목 및 저작권 정보

Deploy SR-IOV Enabled Network Interfaces Container Apps on OKE Using Multus CNI Plugin

G28059-02

다중 CNI 플러그인을 사용하여 OKE에 SR-IOV 사용 네트워크 인터페이스 컨테이너 앱 배치

소개

목표

작업 1: 배스천, 운영자, 3개의 VM 워커 노드 및 Flannel CNI 플러그인을 사용하여 OKE 배치

작업 2: 각 워커 노드에서 SR-IOV(하드웨어 지원) 네트워킹 사용

작업 3: SR-IOV 사용 VNIC에 대한 새 서브넷 만들기

작업 3.1: 보안 목록 생성

작업 3.2: 서브넷 생성

작업 4: 두번째 VNIC 연결 추가

작업 4.1: NSG(네트워크 보안 그룹) 만들기

작업 4.2: VNIC 추가

작업 5: 기본 게이트웨이를 사용하여 새 두번째 VNIC에 IP 주소 지정

작업 5.1: 노드 풀 1의 모든 노드 확인(np1)

작업 5.2: 노드 풀 2의 모든 노드 확인(np2)

작업 6: 워커 노드에 메타 플러그인 CNI(다중 CNI) 설치

작업 6.1: 씬 설치 방법을 사용하여 멀티스 CNI 설치

작업 6.2: Multus 설치 검증

작업 7: Pod에 네트워크 인터페이스 연결

작업 7.1: 네트워크 연결 정의 생성

작업 7.2: NetworkDefinitionAttachment가 연결된 상태로 Pod 생성

작업 7.3: 노드 유사성이 있는 Pod 생성

작업 7.4: 테스트 포드의 IP 주소 확인

작업 7.5: 작업자 노드의 IP 주소 확인

작업 8: 여러 Pod 간 핑 테스트 수행

작업 9: (선택 사항) 다중 인터페이스로 Pod 배치

작업 10: 모든 Pod 배치 제거 및 NetworkAttachmentDefinitions

관련 링크

승인

추가 학습 자원

작업 5.1: 노드 풀 1의 모든 노드 확인(`np1`)

작업 5.2: 노드 풀 2의 모든 노드 확인(`np2`)

작업 7.2: `NetworkDefinitionAttachment`가 연결된 상태로 Pod 생성

작업 10: 모든 Pod 배치 제거 및 `NetworkAttachmentDefinitions`