ノート:

このチュートリアルではOracle Cloudへのアクセスが必要です。無料アカウントにサインアップするには、Oracle Cloud Infrastructure Free Tierの開始を参照してください。
Oracle Cloud Infrastructure資格証明、テナンシおよびコンパートメントの値の例を使用します。演習を完了する場合は、これらの値をクラウド環境に固有の値に置き換えてください。

Multus for VMベースのOracle Container Engine for Kubernetesノードを使用したポッド用のSR-IOVインタフェースの構成

イントロダクション

ネットワーク指向のワークロードでポッド内のセカンダリ・ネットワーク・インタフェースを設定する必要がある場合は、MultusなどのメタCNIを使用してこれを実現できます。このような場合に通常接続されるセカンダリネットワークインタフェースには、シングルルートIO仮想化(SR-IOV)などの特殊なネットワーク機能またはプロパティーがあります。

以前のチュートリアル: ベア・メタルOKEノード用にMultusを使用してポッド用のSR-IOVインタフェースを構成します(リンクは「関連リンク」セクションからアクセスできます)。ベア・メタル・インスタンスにアタッチされたハードウェアで仮想機能(VF)を直接作成できるOracle Cloud Infrastructure (OCI)のベア・メタルKubernetesノードでこれを実現する方法について説明しました。

このチュートリアルは、Oracle Container Engine for Kubernetes (OKE)クラスタの仮想マシン・ノードに対して同様のアプローチに従い、ベアメタル・ノードで使用されているものとは異なる構成およびプラグインを使用して同様のアプローチをとります。ハードウェアと仮想マシンを完全に制御できるベア・メタル間でインタフェースを作成および管理する方法には大きな違いがあります。そこでは、ハイパーバイザが基礎となるハードウェアへのアクセスを抽象化し、それに対する制御が不十分です。

ここで説明するアプローチでは、Multusを使用してポッドに複数のインタフェースを提供しますが、SR-IOV CNIおよび関連するデバイス・プラグインは使用されません。これは、SR-IOV CNIが基盤となるハードウェアである物理機能(PF)にアクセスする必要があるためで、これは明らかに仮想マシンに課題をもたらします。この課題を克服するために、VNIC用のOCIネットワークAPIを使用して、ベア・メタル・シナリオのように物理機能(PF)に仮想機能(VF)を作成し、VMにこのVFへの直接および妨害されていないアクセス権を付与できます。これらのVFは、ネットワークインタフェースとしてOKEノードを含むコンピュートインスタンスに接続できます。これらのインタフェース/VFをポッドのネットワーク・ネームスペースに移動できるため、ポッドは直接かつ排他的にVFをネットワーク・インタフェースとして使用できます。ポッドの観点から見ると、両者を区別できず、どちらの場合も直接使用できるVFにアクセスできます。

VMにVFへの直接アクセスを付与するには、デフォルトの paravirtualizedモードではなく、VFIOネットワーク接続モードで VMを起動する必要があります。この選択は、コンピュート・インスタンスの起動モードによって制御されます。ネットワーク・アタッチメント・モードをVFIOとして設定すると、OCI APIを使用してネットワーク・アタッチメントを作成できます。OCI APIでは、基礎となるPFにVFを作成し、VFをVMに直接提供します。ホスト上のOSは、これらをネットワークインタフェースとして認識します。VFがVMで使用可能になったら、ポッド・ネームスペースに移動できます。このモデルでは、VFは、ベアメタル・シナリオのシステム・コマンドではなくOCI APIを使用して作成されます。

VFがポッド・ネットワーク・ネームスペースに移動しました

目標

Multus for VMベースのOracle Container Engine for Kubernetesノードを使用して、ポッド用のSR-IOVインタフェースを構成します。

前提条件

2つ以上のVMで構成されるノード・プールを持つOKEクラスタ。

ノート: このチュートリアルは、Flannelネットワークを使用するOKEクラスタ(プライマリCNIとしてのFlannel)で検証されました。

タスク1: ノードの設定

SR-IOVインタフェースへのアクセスを必要とする各ノードは、ポッドで使用する前に、ハードウェア支援ネットワーク・アタッチメント用に準備する必要があります。

VFIOモードでノードをブートします
- ノード・プールおよびクラスタ内のノードのセットを作成します。
- ノードが作成されたら、インスタンス・プロパティを編集します。
- インスタンス・プロパティで、「拡張オプションの表示」をクリックして追加プロパティを表示します。「起動オプション」タブで、「ネットワーキング・タイプ」に「ハードウェア支援(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を構成します。
- VNICがホスト上で以前と同じように仮想機能として表示されるかどうかを確認するには、ノード上でSSH-ingを実行し、lspciを実行します。
- セカンダリVNICをLinux VMインスタンスに追加すると、新しいインタフェース(イーサネット・デバイス)がインスタンスに追加され、OSによって自動的に認識されます。ただし、セカンダリVNICではDHCPがアクティブでないため、静的IPアドレスとデフォルト・ルートを使用してインタフェースを構成する必要があります。
セカンダリVNICのOSの構成
- OCIには、セカンダリVNICのOSを構成するためのドキュメントとスクリプトが用意されています。セカンダリVNICを構成するには、ノードにスクリプトをダウンロードし、OCIドキュメントに記載されている手順に基づいて実行します。
  
  ノート: 各ノードのセカンダリVNICは、各ノードに対してこれらのステップを繰り返して設定する必要があります。これらのステップは、オプションで、ノードのカスタムcloud_initスクリプトを使用して自動化できます。
- インタフェースがIPアドレスとデフォルトルートで接続されていることを確認します。確認するには、コマンドip addrまたはnmcliを使用します。
- オプションで、pingを使用してルーティングを検証し、相互にセカンダリIPアドレスに到達します。次のイメージでは、10.0.10.238はクラスタ内の2番目のノードのセカンダリIPです。

タスク2: Meta-Plugin CNIのインストール(複数)

Multusは、SR-IOV CNIプラグインのようなダウンストリームCNIにVF情報を提供できるメタ・プラグインで、複数のネットワーク・インタフェースを持つマルチホーム・ポッドまたはポッドを有効にしながら、ネットワーク・リソース・plumbを処理できます。

ノート: Multus 4.0以降では、Thick plug-inと呼ばれる新しいクライアント・サーバー・スタイルのデプロイメントが導入されました。新しい太いプラグインは、以前はサポートされていなかったメトリックなどの追加機能をサポートしています。このドキュメントでは、消費するリソースが少ないため、thinプラグインを使用します。

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

このマニフェストは、kind:NetworkAttachmentDefinitionの新しいCRDを作成し、デーモンセットを介してすべてのノードでMultusバイナリを提供します。ノードでMultusデーモンセットが実行されていることを確認して、インストールを検証できます。

タスク3: ポッドへの複数のインタフェースのアタッチ

ポッドに追加のインタフェースをアタッチするには、インタフェースをアタッチするための構成が必要です。これは、NetworkAttachmentDefinitionタイプのカスタム・リソースにカプセル化されています。この構成は、基本的にカスタム・リソースとしてパッケージ化されたCNI構成です。
これを実現するためにMultusとともに使用できるいくつかのCNIプラグインがあります。ここで説明するアプローチでは、SR-IOV仮想機能を単一のポッドのみに提供し、ポッドが干渉やその間のレイヤーなしで機能を利用できるようにすることが目標です。VFへのポッド排他アクセスを付与するために、インタフェースをポッドの名前空間に移動できるようにするホスト・デバイス・プラグインを利用して、そのインタフェースに排他的にアクセスできるようにします。

次の例は、ノードに追加されたセカンダリ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: 複数のインタフェースおよびテストを使用したポッドのデプロイ

ポッドは、注釈を使用して追加のインタフェースをリクエストできるようになりました。注釈を使用すると、メタプラグイン(Multus)は、ポッドの作成時に追加のインタフェースを提供するために使用するNetworkAttachmentDefinition (CNI Config)を認識できます。

ノート: この例に示すような静的構成を使用する場合、ポッドにはノード・アフィニティが設定されている必要があるため、目的のホスト・デバイスが使用可能なノード上でポッドがスケジュールされます。

テスト・ポッドの例を次に示します:

## 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

2つのポッドが作成されると、両方が実行中であることがわかります。ポッドの作成中に追加のネットワーク・インタフェースが作成されたことを確認できます。マルチパスは、デフォルトのCNI (この例ではFlannel)に支えられたeth0インタフェースと、SR-IOV仮想機能である追加のnet1インタフェースを提供します。ポッドをdescribeし、出力の「イベント」セクションを確認して、ポッドに接続されているインタフェースを含む様々なイベントを表示できます。

ポッドが開始されると、クイック・テストを実行できます。

## 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

出力は、次のイメージのようになります。

これらのセカンダリ・インタフェースを介して2つのポッド間の通信を確認することもできます。

## 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内の他のソースからポッドにアクセスしようとして、ネットワーク・アタッチメントを使用してポッドがルーティング可能であることも検証できます。
```
## 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