ノート:

マルチパスCNIを使用したOKE上のポッドに対するSR-IOVインタフェースの構成

イントロダクション

SR-IOVは、単一のPCIeデバイスを複数の個別の物理PCIeデバイスとして表示できる仕様です。SR-IOVは、物理機能(PF)と仮想機能(VF)の概念を導入することによって機能します。PFはホストによって使用され、通常は単一のNICポートを表します。VFは、そのPFの軽量バージョンです。適切なサポートにより、SR-IOVは物理ハードウェア(SmartNICなど)が複数の個別の(ネットワークインタフェース)デバイスとしてそれ自体を示す方法を提供します。コンテナを使用すると、コンテナがインタフェースに直接アクセスできるように、これらのインタフェース(VF)の1つをホストからコンテナまたはポッドのネットワーク・ネームスペースに移動できます。この利点は、virt-ioによるオーバーヘッドがなく、ネイティブデバイスのパフォーマンスが得られることです。

ノート: このチュートリアルで説明するプラグインおよびプロセスは、ベア・メタル・インスタンスにのみ適用されます。仮想マシン・ベースのインスタンスの場合、異なるプラグインおよび構成のセットが必要です。

目標

このチュートリアルでは、OKEクラスタで実行されているポッドに対して、セカンダリSR-IOV仮想機能ベースのネットワーク・インタフェースを設定する方法について説明します。SRIOV-CNIプラグインを利用して、SR-IOV仮想機能をノードに割り当てることができるリソースとして管理し、MultusメタCNIを使用してポッドに追加のネットワーク・インタフェースを追加します。

機能

このアプローチにはいくつかのレイヤーとコンポーネントがあります。その正確には、Kubernetesデバイス・プラグインが一連の仮想機能を管理し、それをノード上の割当て可能なリソースとして公開します。ポッドがそのようなリソースをリクエストすると、リソースが使用可能なノードにポッドを割り当て、SR-IOV CNIがポッドのネットワーク・ネームスペースに仮想機能をplumbできます。MultusなどのCNIメタプラグインは、ポッドへの複数のネットワーク・アタッチメントを処理し、ポッドがSR-IOVとオーバーレイ・ネットワークの両方を介して通信できるようにします。

最初に、SR-IOV対応 smartNICsに多数のVFを設定し、それを個々のNICとして表示します。次に、Oracle Cloud Infrastructure (OCI)で認識されるMACアドレスを使用してこれらのVFを構成します。これらのVFは、Multusの外部で(このチュートリアルで説明されているように)手動またはノード作成時に呼び出すことができるスクリプトを使用して作成されます。この時点で、VFのプールがあり、それぞれホストによって個別のNICとして識別され、OCI MACアドレスがあります。Kubernetesネットワーク・plumbingワーキング・グループは、VFを割り当て可能なノード・リソースとして検出および公開する特別な目的のネットワーク・デバイス・プラグインを維持します。SR-IOV CNI (Kubernetesネットワーク・plumb作業グループからも同様)は、デバイス・プラグインとともに動作し、ポッド・ライフサイクルに基づいてポッドへのこれらの仮想機能の割当てを管理します。

これで、SR-IOVデバイスプラグインによって割り当て可能なノードリソースとして認識および管理されるVFのプールを持つ1つ以上のノードがあります。これらはポッドによってリクエストできます。SR-IOV CNIは、VFをポッド作成時にポッドのネットワーク名前空間にplumb (移動)し、ポッド削除時にVFを解放します(ルート名前空間に戻します)。これにより、VFを別のポッドに割り当てることができます。Multusのようなメタ・プラグインは、CNIにVF情報を提供し、ポッド上の複数のネットワーク添付を管理できます。

マルチパスポッドイメージ

タスク1: ホストの設定

まず、PCIeインタフェースにVFを設定できるベア・メタル・ホストから始めます。ベア・メタル・ホストでは、次のステップを実行します。

  1. VFの作成: ベア・メタル・ノードへのSSH接続。物理デバイスを見つけて、それに仮想機能を追加します。

    ノート: デバイス名を取得するスクリプトは、自動化の場合にのみ必要です。

    この例では、デバイス上に2つの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. OCI MACアドレスをVFに割り当てます。

    これらの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}

これでホストの設定が完了します。これは、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. 前述の例では、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は、SR-IOV CNIプラグインのようなダウンストリームCNIにVF情報を提供できるメタ・プラグインで、複数のネットワーク・インタフェースを持つマルチホーム・ポッドまたはポッドを有効にしながら、ネットワーク・リソース・plumbを処理できます。

  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である必要があります。古いクラスタにインストールする場合は、マニフェスト内のデモンセットを編集し、マルチユーザー・イメージ・タグv3.7.1を使用します。

    • このマニフェストは、kind:NetworkAttachmentDefinitionの新しいCRDを作成し、デーモンセットを介してすべてのノード上でマルチウスバイナリを提供します。

  2. ポッドに追加のインタフェースをアタッチするには、インタフェースをアタッチするための構成が必要です。これは、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: 複数のインタフェースを使用したポッドのデプロイおよびテスト

承認

その他の学習リソース

docs.oracle.com/learnで他のラボをご覧いただくか、Oracle Learning YouTubeチャネルでより無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスして、Oracle Learning Explorerになります。

製品ドキュメントについては、Oracle Help Centerを参照してください。