참고:

Multus CNI를 사용하여 OKE의 Pod에 대한 SR-IOV 인터페이스 구성

소개

SR-IOV는 단일 PCIe 장치가 여러 개의 개별 물리적 PCIe 장치로 표시되도록 하는 사양입니다. SR-IOV는 PF(물리적 기능) 및 VF(가상 기능)의 개념을 도입하여 작동합니다. PF는 호스트에서 사용되며 일반적으로 단일 NIC 포트를 나타냅니다. VF는 해당 PF의 경량 버전입니다. 적절한 지원을 통해 SR-IOV는 물리적 하드웨어(예: SmartNIC)를 여러 고유(네트워크 인터페이스) 장치로 표시할 수 있는 방법을 제공합니다. 컨테이너를 사용하면 이러한 인터페이스(VF) 중 하나를 호스트에서 컨테이너 또는 Pod의 네트워크 네임스페이스로 이동하여 컨테이너가 이제 인터페이스에 직접 액세스할 수 있습니다. 이 장점은 virt-io를 사용하여 오버헤드를 받지 않고 기본 장치 성능을 확보한다는 점입니다.

참고: 이 자습서에 설명된 플러그인 및 프로세스는 베어메탈 인스턴스에만 적용할 수 있습니다. 가상 머신 기반 인스턴스의 경우 다른 플러그인 및 구성 세트가 필요합니다.

목표

이 사용지침서에서는 OKE 클러스터에서 실행되는 POD에 대해 보조 SR-IOV 가상 기능 기반 네트워크 인터페이스를 설정하는 방법을 설명합니다. SRIOV-CNI 플러그인을 사용하여 SR-IOV 가상 기능을 노드에 할당할 수 있는 리소스로 관리하고 Multus 메타 CNI를 사용하여 Pod에 네트워크 인터페이스를 더 추가합니다.

작동 방법

접근 방식에는 여러 계층과 구성요소가 있습니다. 크루즈에서 Kubernetes 장치 플러그인은 일련의 가상 기능을 관리하고 노드에 할당 가능한 리소스로 게시합니다. Pod가 이러한 리소스를 요청할 경우 리소스를 사용할 수 있는 노드에 Pod를 지정할 수 있으며 SR-IOV CNI가 Pod의 네트워크 이름 공간에 가상 기능을 연결할 수 있습니다. Multus와 같은 CNI 메타 플러그인은 Pod가 SR-IOV와 오버레이 네트워크를 통해 통신할 수 있도록 Pod에 대한 여러 네트워크 연결을 처리합니다.

먼저 SR-IOV 가능 smartNICs에 여러 VF를 설정하면 해당 VF가 개별 NIC로 표시됩니다. 그런 다음 OCI(Oracle Cloud Infrastructure)가 인식하는 MAC 주소로 이러한 VF를 구성합니다. 이러한 VF는 이 자습서에 설명된 대로 수동으로 Multus 외부에 생성되거나 노드 생성 시 호출할 수 있는 스크립트를 사용하여 생성됩니다. 이때 호스트에서 각각 별도의 NIC로 식별되는 VF 풀과 OCI MAC 주소가 있습니다. Kubernetes 네트워크 연결 작업 그룹은 VF를 검색하고 할당 가능한 노드 리소스로 게시하는 특수 용도의 네트워크 장치 플러그인을 유지 관리합니다. SR-IOV CNI(Kubernetes 네트워크 연결 작업 그룹에서도)는 장치 플러그인과 함께 작동하며 Pod 수명 주기를 기반으로 이러한 가상 기능을 Pod에 지정하는 작업을 관리합니다.

이제 SR-IOV 장치 플러그인에 의해 인식되고 관리되는 VF 풀이 있는 하나 이상의 노드가 할당 가능한 노드 리소스로 제공됩니다. POD에서 요청할 수 있습니다. SR-IOV CNI는 VF를 Pod 생성 시 Pod의 네트워크 네임스페이스로 이동(이동)하고 Pod 삭제 시 VF(루트 네임스페이스로 다시 이동)를 해제합니다. 이렇게 하면 VF를 다른 Pod에 할당할 수 있습니다. Multus와 같은 메타 플러그인은 CNI에 VF 정보를 제공하고 Pod에서 여러 네트워크 연결을 관리할 수 있습니다.

다중 포드 이미지

작업 1: 호스트 설정

먼저 베어메탈 호스트에서 PCIe 인터페이스에 대한 VF를 설정할 수 있습니다. 베어메탈 호스트에서는 다음 단계를 수행합니다.

  1. VF 생성: 베어메탈 노드에 SSH로 접속합니다. 물리적 장치를 찾아 가상 기능을 추가합니다.

    주: 장치 이름을 가져오는 스크립트는 자동화에만 필요합니다.

    이 예에서는 장치에 두 개의 VF를 만듭니다.

    # Gets the physical device. Alterntively, just run `ip addr show` and look at the primary iface to set $PHYSDEV
URL=http://169.254.169.254/opc/v1/vnics/
baseAddress=`curl -s ${URL} | jq -r '.[0] | .privateIp'`
PHYSDEV=`ip -o -4 addr show | grep ${baseAddress} | awk -F: '{gsub(/^[ \t]|[ \t]$/,"",$2);split($2,out,/[ \t]+/);print out[1]}'`

# Add two VFs
echo "2" > /sys/class/net/${PHYSDEV}/device/sriov_numvfs

# Verify the VFs
ip link show ${PHYSDEV}

  2. VF에 OCI MAC 주소를 지정합니다.

    이러한 VF에는 현재(또는 000) 자동 생성된 MAC 주소가 포함됩니다. OCI 네트워크에서 트래픽을 허용하려면 해당 트래픽의 OCI MAC 주소를 설정해야 합니다. 생성된 VF 수와 호스트에서 동일한 수의 VNIC 연결을 만들기합니다. 각 VNIC 연결의 MAC 주소를 확인합니다. 이제 OCI가 인식하는 이러한 MAC 주소를 생성된 VFS에 각각 지정합니다.

    # For each MAC address from the VNIC attachments

ip link set ${PHYSDEV} vf <n= 0..numVFs> mac <MAC Address from VNIC attachment> spoofchk off

# verify all VFs have Mac addresses from OCI
ip link show ${PHYSDEV}

이렇게 해서 Pod에 SR-IOV 네트워킹 리소스를 제공해야 하는 모든 호스트에서 수행되어야 하므로 호스트 설정이 완료되었습니다.

작업 2: SR-IOV CNI 설치

이 CNI는 데몬 세트로 1.16+ 클러스터에 설치할 수 있습니다. SR-IOV 장치가 없는 노드는 장치 플러그인 자체에 의해 정상적으로 처리됩니다.

git clone https://github.com/k8snetworkplumbingwg/sriov-cni.git && cd sriov-cni
kubectl apply -f images/k8s-v1.16/sriov-cni-daemonset.yaml && cd..

작업 3: SR-IOV 네트워크 장치 플러그인 설치

주: 장치 플러그인은 VF를 즉시 만들지 않으므로 별도로 만들어야 합니다.

장치 플러그인은 노드에서 SR-IOV 가능 네트워크 장치를 검색하고 알립니다. 이를 위해 장치 플러그인은 장치 플러그인 끝점을 만들 수 있도록 구성이 필요합니다. 구성은 사용된 장치 및 드라이버를 식별합니다.

  1. SR-IOV 리소스 풀에 대한 ConfigMap를 만듭니다. ConfigMap를 설정하려면 공급업체 ID, 장치 ID 및 장치에서 사용하는 드라이버를 알아야 합니다.

    1. 공급업체 ID 및 장치 ID를 찾으려면 다음을 수행합니다.

      lspci -nn|grep Virtual

31:02.0 Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme-E Ethernet Virtual Function [14e4:16dc]
31:02.1 Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme-E Ethernet Virtual Function [14e4:16dc]

    2. 위 예제에서는 VF가 두 개 있으며 마지막 정보 비트가 공급업체 ID(14e4) 및 장치 ID(16dc)를 제공합니다. lspci에서 사용하는 hwdata를 사용하여 이를 상호 확인할 수 있습니다.

      cat /usr/share/hwdata/pci.ids|grep 16dc

    3. 사용된 드라이버를 찾으려면 다음을 수행합니다.

      # filtering based on the PCIe slots.
find /sys | grep drivers.*31:02.0|awk -F/ '{print $6}'

bnxt_en

  2. ConfigMap를 설정합니다. ConfigMap의 이름은 sriovdp-config이고 config.json 키가 있어야 합니다.

    cat << EOF > sriovdp-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: sriovdp-config
  namespace: kube-system
data:
  config.json: |
    {
      "resourceList": [{
              "resourceName": "mlnx_sriov_rdma",
              "resourcePrefix": "mellanox.com",
              "selectors": {
                "vendors": ["15b3"],
                "devices": ["101e"],
                "drivers": ["mlx5_core"],
                "isRdma": false
              }
          },
          {
              "resourceName": "netxtreme_sriov_rdma",
              "resourcePrefix": "broadcom.com",
              "selectors": {
                "vendors": ["14e4"],
                "devices": ["16dc"],
                "drivers": ["bnxt_en"],
                "isRdma": false
              }
          }
      ]
    }
EOF

kubectl create -f sriovdp-config.yaml

  3. 장치 플러그인을 설정합니다. 구성 맵을 만들면 장치 플러그인을 데몬 세트로 설치할 수 있습니다.

    git clone https://github.com/k8snetworkplumbingwg/sriov-network-device-plugin.git && cd sriov-network-device-plugin
kubectl create -f deployments/k8s-v1.16/sriovdp-daemonset.yaml && cd ..

  4. 데몬 세트가 배치되면 컨테이너 로그에서 문제 해결을 확인할 수 있습니다. 배치가 성공하면 노드가 가상 기능을 할당 가능한 리소스로 나열해야 합니다.

    kubectl get node <node_name> -o json | jq '.status.allocatable'

{
  "broadcom.com/netxtreme_sriov_rdma": "2",
  "cpu": "128",
  "ephemeral-storage": "37070025462",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "memory": "527632840Ki",
  "pods": "110"
}

작업 4: 메타 플러그인 CNI(다중) 설치

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

  1. 다중 설치:

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

    주:

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

    • 이 매니페스트는 kind:NetworkAttachmentDefinition에 대한 새 CRD를 만들고 데몬 세트를 통해 모든 노드에서 다중 사용자 이진을 제공합니다.

  2. Pod에 추가 인터페이스를 연결하려면 인터페이스를 연결하려면 구성이 필요합니다. 종류 NetworkAttachmentDefinition의 사용자 정의 리소스에서 캡슐화됩니다. 이 구성은 기본적으로 사용자정의 리소스로 패키지화된 CNI 구성입니다.

    샘플 NetworkAttachmentDefinition를 설정해 보겠습니다.

    cat << EOF > sriov-net1.yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: sriov-net1
  annotations:
    k8s.v1.cni.cncf.io/resourceName: broadcom.com/netxtreme_sriov_rdma
spec:
  config: '{
  "type": "sriov",
  "cniVersion": "0.3.1",
  "name": "sriov-network",
  "ipam": {
    "type": "host-local",
    "subnet": "10.20.30.0/25",
    "routes": [{
      "dst": "0.0.0.0/0"
    }],
    "gateway": "10.20.10.1"
  }
}'
EOF

kubectl apply -f sriov-net1.yaml

작업 5: 다중 인터페이스를 사용하여 Pod 배치 및 테스트

수락

추가 학습 자원

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

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