참고:

이 자습서에서는 Oracle Cloud에 액세스해야 합니다. 무료 계정에 등록하려면 Oracle Cloud Infrastructure Free Tier 시작하기를 참조하십시오.
Oracle Cloud Infrastructure 인증서, 테넌시 및 구획에 대한 예제 값을 사용합니다. 실습을 완료하려면 이 값을 클라우드 환경에 해당하는 값으로 대체하십시오.

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

소개

네트워크 중심의 워크로드에서 Pod 내에서 보조 네트워크 인터페이스를 설정해야 하는 경우 Multus와 같은 메타 CNI를 사용하여 이를 수행할 수 있습니다. 이러한 경우 일반적으로 연결된 보조 네트워크 인터페이스에는 SR-IOV(Single Root IO Virtualization)와 같은 특수한 네트워킹 기능 또는 등록 정보가 포함됩니다.

이전 사용지침서: 베어메탈 OKE 노드용 Multus를 사용하여 포드에 대한 SR-IOV 인터페이스 구성(관련 링크 섹션에서 링크를 액세스할 수 있음), 베어메탈 인스턴스에 연결된 하드웨어에서 VF(가상 기능)를 직접 생성할 수 있는 OCI(Oracle Cloud Infrastructure)의 베어메탈 Kubernetes 노드에서 이 작업을 수행하는 방법에 대해 설명했습니다.

이 사용지침서에서는 OKE(Oracle Container Engine for Kubernetes) 클러스터의 가상 머신 노드에 대해 유사한 접근 방식을 따르며 베어 메탈 노드에서 사용되는 것과 다른 구성 및 플러그인과 유사한 접근 방식을 사용합니다. 하이퍼바이저가 기본 하드웨어에 대한 액세스를 추상화하고 제어할 수 없는 하드웨어 및 가상 머신을 완벽하게 제어할 수 있는 베어메탈 간에 인터페이스를 만들고 관리하는 방법에 상당한 차이가 있습니다.

여기에 설명된 접근법은 Multus를 사용하여 포드에 여러 인터페이스를 제공하지만 SR-IOV CNI 및 연관된 장치 플러그인은 사용되지 않습니다. 이는 SR-IOV CNI가 기본 하드웨어인 PF(물리적 기능)에 대한 액세스가 필요하기 때문이며, 이는 가상 시스템에 문제가 발생하기 때문입니다. 이러한 문제를 해결하려면 VNIC에 대한 OCI 네트워킹 API를 사용하여 베어메탈 시나리오와 같이 PF(물리적 기능)에 VF(가상 기능)를 만들고 이 VF에 대한 VM 직접 및 비구조적 액세스를 제공할 수 있습니다. 이러한 VF는 OKE 노드를 포함한 컴퓨트 인스턴스에 네트워크 인터페이스로 연결할 수 있습니다. 이러한 인터페이스/VF는 포드가 VF를 네트워크 인터페이스로 직접 독점적으로 사용할 수 있도록 하는 포드의 네트워크 이름 공간으로 이동할 수 있습니다. Pod의 관점에서 둘을 구분할 수 없으며 두 경우 모두 직접 사용할 수 있는 VF에 액세스할 수 있습니다.

VM이 VF에 직접 액세스할 수 있도록 하려면 기본 paravirtualized 모드와 반대로 VFIO 네트워크 연결 모드로 VM을 실행해야 합니다. 이 선택은 컴퓨트 인스턴스에 대한 실행 모드로 제어됩니다. 네트워크 연결 모드가 VFIO로 설정되면 OCI API를 사용하여 네트워크 연결을 만들 수 있습니다. 그러면 기본 PF에서 VF를 만들고 VM에 직접 VF를 제공합니다. 호스트의 OS는 이러한 인터페이스를 네트워크 인터페이스로 인식합니다. VM에서 VF를 사용할 수 있게 되면 Pod 이름 공간으로 이동할 수 있습니다. 이 모델에서 VF는 베어 메탈 시나리오의 시스템 명령과 달리 OCI API를 사용하여 생성됩니다.

VF가 Pod 네트워크 네임스페이스로 이동됨

목표

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

필요 조건

2개 이상의 VM으로 구성된 노드 풀이 있는 OKE 클러스터입니다.

주: 이 자습서는 Flannel 네트워킹(Flannel을 기본 CNI로 사용)을 사용하는 OKE 클러스터에서 검증되었습니다.

작업 1: 노드 설정

SR-IOV 인터페이스에 대한 액세스가 필요한 각 노드는 Pod에서 사용하기 전에 하드웨어 지원 네트워크 연결을 위해 준비해야 합니다.

VFIO 모드로 노드 부트
- 클러스터에 노드 풀 및 노드 세트를 만듭니다.
- 노드가 생성되면 인스턴스 속성을 편집합니다.
- 인스턴스 속성에서 고급 옵션 표시를 눌러 추가 속성을 봅니다. Launch Options(실행 옵션) 탭에서 Networking type(네트워킹 유형)에 대해 Hardware-assisted (SR-IOV) networking(하드웨어 지원(SR-IOV) 네트워킹)을 선택합니다.
  
  참고: 인스턴스가 하드웨어 지원(SR-IOV 또는 VFIO) 모드로 반가상화 네트워크 연결 형식으로 전환되면 더 이상 인프라 유지보수를 라이브 마이그레이션할 수 없습니다.
- 업데이트 워크플로우에서 인스턴스를 재부팅하라는 메시지가 표시됩니다. 재부팅 후 인스턴스에 VFIO 네트워크 연결이 있습니다. 콘솔에서 확인할 수 있습니다.
- 인스턴스가 SR-IOV 네트워크 연결을 사용 중인지 확인하는 또 다른 방법은 노드에 SSH로 접속하고 lspci를 사용하여 VM의 PCI 장치를 나열하는 것입니다. 아래 이미지의 스토리지 컨트롤러와 같이 virtio 드라이버를 사용하는 장치가 아닌 VM에서 직접 기본 가상 기능을 볼 수 있어야 합니다.
- 이때 노드에는 노드에 대한 모든 통신에 사용되는 기본 VNIC인 단일 VNIC 연결이 있습니다. 인스턴스가 하드웨어 지원 네트워크 연결을 사용하고 있으므로 네트워크 연결이 노드에 기본 하드웨어의 가상 기능으로 표시됩니다. 포드가 VF(가상 기능)를 배타적으로 사용하려면 VM에 추가 VF가 필요합니다. 콘솔 또는 API를 사용하여 VNIC 연결을 인스턴스에 추가할 수 있습니다. 이러한 VNIC 연결은 기본 PF의 VF입니다. lspci로 확인할 수 있습니다.
다른 VNIC 연결 추가
- 인스턴스 페이지에서 연결된 VNIC를 선택하고 VNIC 생성을 누릅니다.
- 필요한 VCN 및 서브넷을 사용하여 VNIC를 구성합니다.
- 노드에서 SSH-ing하고 lspci를 실행하여 VNIC를 이전과 같이 호스트에서 가상 기능으로 볼 수 있는지 확인합니다.
- 보조 VNIC를 Linux VM 인스턴스에 추가하면 새 인터페이스(이더넷 장치)가 인스턴스에 추가되고 OS에서 자동으로 인식됩니다. 그러나 DHCP가 보조 VNIC에 대해 활성 상태가 아니므로 정적 IP 주소 및 기본 경로로 인터페이스를 구성해야 합니다.
보조 VNIC에 대한 OS 구성
- OCI는 보조 VNIC에 대한 OS 구성을 위한 설명서 및 스크립트를 제공합니다. 보조 VNIC를 구성하려면 노드에서 스크립트를 다운로드하고 OCI 설명서에 제공된 지침에 따라 실행합니다.
  
  Note: The secondary VNICs on each node must be set up by repeating these steps for each node. These steps can be optionally and automated using a custom cloud_init script for the nodes.
- 이제 인터페이스가 IP 주소 및 기본 경로와 함께 연결되었는지 확인합니다. 확인하려면 ip addr 또는 nmcli 명령을 사용합니다.
- 선택적으로 핑을 사용하여 경로 지정을 확인하여 서로 보조 IP 주소에 연결합니다. 아래 이미지에서 10.0.10.238는 클러스터의 두번째 노드에 있는 보조 IP입니다.

작업 2: Meta-Plugin CNI 설치(다중)

Multus는 SR-IOV CNI 플러그인과 같은 다운스트림 CNI에 VF 정보를 제공할 수 있는 메타 플러그인으로, 여러 네트워크 인터페이스가 있는 "멀티홈" 포드 또는 포드를 사용으로 설정하면서 네트워크 리소스 배관을 처리할 수 있습니다.

주: Multus 4.0 이상에서는 Multus가 '두번째 플러그인'이라는 새 클라이언트-서버 스타일 배치를 도입했습니다. 새 굵은 플러그인은 이전에 지원되지 않은 측정항목과 같은 추가 기능을 지원합니다. 이 문서는 더 적은 리소스를 사용하므로 '씬' 플러그인을 사용합니다.

Multus를 설치하려면 다음 명령을 실행합니다.

git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
kubectl apply -f deployments/multus-daemonset.yml && cd ..

주: 설치 시 stable 태그가 지정된 데몬 세트에서 사용하는 기본 이미지에는 kubelet이 v1.20.x여야 합니다. 이전 클러스터에 설치하는 경우 매니페스트에서 deamonset을 편집하고 다중 이미지 태그 v3.7.1를 사용합니다.

이 매니페스트는 kind:NetworkAttachmentDefinition에 대한 새 CRD를 만들고 데몬 세트를 통해 모든 노드에 Multus 이진을 제공합니다. 다중 사용자 데몬 세트가 노드에서 실행 중인지 확인하여 설치를 확인할 수 있습니다.

작업 3: POD에 여러 인터페이스 연결

추가 인터페이스를 POD에 연결하려면 인터페이스를 연결하기 위한 구성이 필요합니다. 이는 NetworkAttachmentDefinition 유형의 사용자정의 리소스에서 캡슐화됩니다. 이 구성은 기본적으로 사용자 정의 리소스로 패키지화된 CNI 구성입니다.
이를 위해 Multus와 함께 사용할 수 있는 여러 개의 CNI 플러그인이 있습니다. 여기에 설명된 접근 방식에서 목표는 SR-IOV 가상 기능을 단일 포드에 독점적으로 제공하여 포드가 간섭이나 그 사이에 있는 계층 없이 기능을 활용할 수 있도록 하는 것입니다. POD에 배타적 액세스 권한을 VF에 부여하기 위해 인터페이스를 POD의 이름 공간으로 이동할 수 있는 host-device plug-in을 활용할 수 있습니다. 그러면 해당 POD에 배타적 액세스가 가능합니다.

아래 예에서는 노드에 추가된 보조 ens5 인터페이스를 구성하는 NetworkAttachmentDefinition 객체를 보여줍니다. ipam 플러그인 구성에 따라 해당 인터페이스에 대해 IP 주소가 관리되는 방식이 결정됩니다. 이 예에서는 OCI가 보조 인터페이스에 지정한 것과 동일한 IP 주소를 사용하려고 하므로 정적 ipam 구성을 적절한 경로와 함께 사용합니다. ipam 구성은 더 유연한 구성을 위해 host-local 또는 dhcp과 같은 다른 메소드도 지원합니다.

## network attachment for the first node. Note the IPaddress assignment in the `ipam` configuration.

cat << EOF | kubectl create -f -
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.10.93/24",
                        "gateway": "0.0.0.0"
                    }
                ],
                "routes": [
                    { "dst": "10.0.10.0/24", "gw": "0.0.0.0" }
                ]
            }
          }'
EOF

## network attachment for the second node. Note the IPaddress assignment in the `ipam` configuration.

cat << EOF | kubectl create -f -
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.10.238/24",
                        "gateway": "0.0.0.0"
                    }
                ],
                "routes": [
                    { "dst": "10.0.10.0/24", "gw": "0.0.0.0" }
                ]
            }
          }'
EOF

작업 4: 여러 인터페이스로 Pod 배치 및 테스트

이제 Pod가 주석을 사용하여 추가 인터페이스를 요청할 수 있습니다. 주석을 통해 meta-plug-in(Multus)은 Pod가 생성될 때 추가 인터페이스를 제공하는 데 사용할 NetworkAttachmentDefinition(CNI 구성)를 알 수 있습니다.

주: 이 예에 표시된 것과 같은 정적 구성을 사용하는 경우 원하는 호스트 장치를 사용할 수 있는 노드에서 Pod가 예약되도록 Pod에 노드 유사성을 설정해야 합니다.

다음은 테스트 포드의 예입니다.

## Create the first pod
cat << EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: testpod1
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-vnic-1
spec:
  containers:
  - name: appcntr1
    image: centos/tools
    imagePullPolicy: IfNotPresent
    command: [ "/bin/bash", "-c", "--" ]
    args: [ "while true; do sleep 300000; done;" ]

EOF

## Create a second pod
cat << EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: testpod2
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-vnic
spec:
  containers:
  - name: appcntr1
    image: centos/tools
    imagePullPolicy: IfNotPresent
    command: [ "/bin/bash", "-c", "--" ]
    args: [ "while true; do sleep 300000; done;" ]

EOF

두 개의 포드가 생성되면 두 포드가 모두 실행 중인 것을 확인해야 합니다. Pod를 만드는 동안 추가 네트워크 인터페이스가 만들어졌음을 확인할 수 있어야 합니다. 다중 사용자는 기본 CNI(이 예의 경우 Flannel)가 지원하는 eth0 인터페이스와 SR-IOV 가상 기능인 추가 net1 인터페이스를 제공합니다. 포드를 describe하고 출력의 Events 섹션을 관찰하여 포드에 연결 중인 인터페이스를 비롯한 다양한 이벤트를 확인할 수 있습니다.

포드가 시작되면 빠른 테스트를 수행할 수 있습니다.

## Verify that both pods have two interfaces. An `eth0` on the overlay and a `net1` which is the VF, along with the IP address for the secondary VNIC.
kubectl exec -it testpod1 -- ip addr show
kubectl exec -it testpod2 -- ip addr show

출력은 다음 이미지와 유사해야 합니다.

또한 이러한 보조 인터페이스를 통해 두 포드 간의 통신을 확인할 수 있습니다.

## test communication
kubectl exec -it testpod1 -- ping -I net1  <ip address for secondary vnic on the other pod/node>
kubectl exec -it testpod2 -- ping -I net1  <ip address for secondary vnic on the other pod/node>

출력은 다음 이미지와 유사해야 합니다.
또한 VM 또는 VCN 내의 다른 소스에서 Pod를 연결하려고 시도하여 네트워크 연결을 통해 POD가 경로 지정 가능한지 검증할 수 있습니다.
```
## Test that the pod is routable from outside Kubernetes. This is executed from node1.
ping 10.0.10.238

## similarly, from node 2
ping 10.0.10.93
```
출력은 다음 이미지와 유사해야 합니다.

승인

작성자 - Jeevan Joseph(교장 제품 관리자)

추가 학습 자원

docs.oracle.com/learn에서 다른 실습을 탐색하거나 Oracle Learning YouTube 채널에서 더 많은 무료 학습 콘텐츠에 액세스할 수 있습니다. 또한 education.oracle.com/learning-explorer을 방문하여 Oracle Learning Explorer가 됩니다.

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

제목 및 저작권 정보

Configure SR-IOV interfaces for pods using Multus for VM-based Oracle Container Engine for Kubernetes nodes

F80585-01

May 2023