ポッド・ネットワーキング用の複数のセカンダリVNICのアタッチ

ステップ1: ノードの拡張リソース名と容量の確認

ノード・プールにワーカー・ノードが表示されたら、ノードの拡張リソース名と容量を確認します。

1. ノードの通知された拡張リソースを確認します。

   kubectl describe node <node-name>

2. 出力のCapacityセクションで、アプリケーション・リソースに対応する拡張リソース(oke-application-resource.oci.oraclecloud.com/frontendなど)を特定し、ゼロ以外の容量があることを確認します。

アプリケーション・リソースを公開するノードは、明示的なアプリケーション・リソース・リクエストのないポッドがそれらにランディングされないように、oci.oraclecloud.com/application-resource-only:NoScheduleで汚染されます。

対応する許容範囲をポッド仕様に追加します(ポッドの場合はspec.tolerations、デプロイメントの場合はspec.template.spec.tolerations)。

tolerations:
  - key: "oci.oraclecloud.com/application-resource-only"
    operator: "Exists"
    effect: "NoSchedule"

この許容範囲がない場合、スケジューラはリソース容量が存在する場合でも配置を拒否します。

ポッド仕様で、ポッドが使用する必要があるセカンダリVNICプロファイルに対応する拡張リソース(たとえば、spec.template.spec.containers[].resourcesのデプロイメント内)をリクエストします。スケジューラが容量を一貫して予約するように、要求および制限する単位は1つのみです。

例:

containers:
  - name: myapp
    image: <image>
    resources:
      requests:
        oke-application-resource.oci.oraclecloud.com/frontend: "1"
      limits:
        oke-application-resource.oci.oraclecloud.com/frontend: "1"

ステップ4: (オプション)正しいノード・プールのターゲット指定

組織でこれらのノードにノード・ラベル/セレクタ規則(gva_vnic: "yes"など)を使用する場合は、必要なリソースがないノード・プールにポッドが配置されないように、それを含めます。

nodeSelector:
  gva_vnic: "yes"

アプリケーション・リソースのリクエストおよび許容範囲がすでにスケジューリングを制限している場合、nodeSelectorはオプションです。nodeSelectorは、ターゲット・ノードにラベルを付けた場合(たとえば、ノード・プールのKubernetesラベルを使用)にのみ使用します。

デプロイ後:

1. 次のように入力します。

   kubectl get pods -o wide

2. 関心のあるポッドには、次のように入力します:

   kubectl describe pod <pod-name>

3. ポッドが実行中であり、スケジューリング・エラーがないことを確認します(たとえば、要求されたリソースのキャパシティが不十分です)。

NADを作成するか、マルチインタフェース・ポッドをデプロイする前に、Multusをインストールします。Multusのインストールの詳細は、GitHubのMultus-CNIドキュメントを参照してください。

組織の標準プロセスに従ってMultusをデプロイし、それが正常であることを確認します。

kubectl get pod -l app=multus -n kube-system

この項の例では、追加のポッド・インタフェースにipvlan CNIプラグインを使用します。マルチインタフェース・ポッドを実行できるすべてのワーカー・ノードの/opt/cni/bin/ipvlanに、ipvlanバイナリが存在することを確認します。

Oracleでは、ノードの作成、置換またはスケール・アウト時にプラグインがインストールされるように、ノード・プールのcloud-initスクリプトを使用してipvlanプラグインをインストールすることをお薦めします。フローティングダウンロードパスに従うのではなく、ターゲット環境の検証済みリリースにプラグインを固定します。次の例では、バージョンv1.9.0を使用します。

例:

#!/bin/bash

CNI_VERSION="v1.9.0"
CNI_ARCH="amd64"
CNI_TARBALL="cni-plugins-linux-${CNI_ARCH}-${CNI_VERSION}.tgz"
CNI_URL="https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/${CNI_TARBALL}"
CNI_BIN_DIR="/opt/cni/bin"

wget --fail -O "/tmp/${CNI_TARBALL}" "${CNI_URL}" && \
  tar xvzf "/tmp/${CNI_TARBALL}" -C "${CNI_BIN_DIR}" && \
  rm -f "/tmp/${CNI_TARBALL}"

curl --fail -H "Authorization: Bearer Oracle" -L0 \
  http://169.254.169.254/opc/v2/instance/metadata/oke_init_script \
  | base64 --decode > /var/run/oke-init.sh

bash /var/run/oke-init.sh

ワーカー・ノードがGitHubにアクセスできない場合は、必要なCNIプラグイン・アーカイブをOCIオブジェクト・ストレージまたは承認された別の内部場所にステージングし、cloud-initスクリプトでダウンロードURLを更新します。

NADは、接続されたVNICによって作成される実際のホストインタフェース名をターゲットとする必要があります(たとえば、enp1s0、enp2s0)。組織の標準アクセス方法を使用して、ワーカー・ノードでそれらを確認します。

作成:

• デフォルトのポッド・ネットワーク用に1つのNAD(eth0を戻すホスト・インタフェースを制御するため)
• 追加インタフェース用の1つ以上のNAD (たとえば、net1)。

NAD構成では、deviceSelectorを使用してデバイスを選択できます(たとえば、interfaceNameによって、またはご使用の環境でサポートされている場合はappResourceを使用してアプリケーション・リソース名によって)。

次のNAD例では、意図的に異なるネームスペースを使用しています。oci-vcn-native-networkはkube-systemで定義され、ipvlan-networkはdefaultで定義されます。ワークロードが別のネームスペースで実行される場合、そのネームスペースにipvlan-networkを作成するか、ポッド注釈を更新して完全修飾NAD名を参照します。

デフォルトのネットワークNADがenp1s0に固定されました。

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: oci-vcn-native-network
  namespace: kube-system
spec:
  config: |
    {
      "name": "oci",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "cniVersion": "0.3.1",
          "type": "oci-ipvlan",
          "mode": "l2",
          "ipam": {
            "type": "oci-ipam",
            "deviceSelector": {
              "interfaceName": "enp1s0"
            }
          }
        },
        {
          "cniVersion": "0.3.1",
          "type": "oci-ptp",
          "containerInterface": "ptp-veth0",
          "mtu": 9000
        }
      ]
    }

セカンダリ・ネットワークNADがenp2s0に固定されました。

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: ipvlan-network
  namespace: default
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "ipvlan",
          "mode": "l2",
          "master": "enp2s0",
          "ipam": {
            "type": "oci-ipam",
            "deviceSelector": {
              "interfaceName": "enp2s0"
            }
          }
        }
      ]
    }

デフォルトのNADでは、OCI固有のoci-ipvlanおよびoci-ptpプラグインが使用されます。これは、そのインタフェースがOKE VCNネイティブのデフォルト・ネットワーク・パスに参加するためです。追加のNADは標準のipvlanプラグインを使用します。これは、Multusが特定のホストNICに追加のインタフェースをアタッチし、OCI IPAMは引き続きサブネット対応のIP割当てを提供するためです。

deviceSelectorは、次のようなフィールドを持つインタフェースをターゲットにできます。

{
  "appResource": "blue",
  "interfaceName": "enp2s0",
  "interfaceNamePrefix": "enp",
  "macAddress": "02:00:17:08:E3:07"
}

deviceSelectorブロックを使用すると、OCI IPAMはポッドIP割当てに使用されるターゲット・インタフェースまたはVNICを選択できます。次の1つ以上のフィールドを使用してデバイスを選択できます。

• appResource: アプリケーション・リソース名でGVA VNICプロファイルを選択します。

• interfaceName: 特定のホスト・インタフェース(enp1s0など)を選択します。

• interfaceNamePrefix: 接頭辞でインタフェースを選択します(enpなど)。

• macAddress: MACアドレスでインタフェースを選択します。

NADデバイス・セレクタでappResourceが設定されている場合、OCI IPAMプラグインは、そのアプリケーション・リソースを使用して、ポッドIPアドレスを提供し、そのインタフェースの親デバイスとして機能するGVA VNICプロファイルを決定します。これにより、次のように、同じポッド内の異なるNADを異なるVNICプロファイルにマップできます。

• NAD1 -> Application Resource: vnic-a

• NAD2 -> Application Resource: vnic-b

• NAD3 -> Application Resource: vnic-c

ポッドが3つのNADをすべて使用している場合、各インタフェースは対応する VNICプロファイルを介して接続できます。

このドキュメントに示されているinterface-nameの例では:

• oci-vcn-native-network NADはinterfaceName: enp1s0を使用するため、OCI IPAMはホストのenp1s0インタフェースからポッドのデフォルト・ネットワークIPを割り当てます。

• ipvlan-network NADはinterfaceName: enp2s0を使用するため、OCI IPAMはホストのenp2s0インタフェースから追加のインタフェースIPを割り当てます。

これは、ポッドの例が次のように設定する理由でもあります。

annotations:
  v1.multus-cni.io/default-network: kube-system/oci-vcn-native-network
  k8s.v1.cni.cncf.io/networks: default/ipvlan-network

v1.multus-cni.io/default-network注釈は、eth0がoci-vcn-native-network NADを使用するようにします。そのデフォルト・ネットワークを明示的に選択しないと、OCI IPAMは適格なホスト・インタフェースから割り当てることができ、プライマリ・ポッド・インタフェースを予測しやすくなります。デフォルトのNADを設定すると、eth0は目的のインタフェースを使用し、追加のネットワーク・アタッチメントから分離します。

これらのMultusポッド注釈を、同じポッド仕様のポッド・レベルのアプリケーション・リソース・リクエストと組み合せないでください。マルチインタフェース・ポッドでGVA VNICの選択が必要な場合は、ポッドレベルのアプリケーション・リソース・リクエストを使用するかわりに、各インタフェースのNAD deviceSelector.appResource構成内でその選択を定義します。

NADを適用します。

kubectl apply -f oci-vcn-native-network-nad.yaml

kubectl apply -f ipvlan-network.yaml

ポッドに注釈を付けてデフォルトのネットワークNADを選択し、追加のネットワークNADを接続します。次に例を示します。

metadata:
  annotations:
    v1.multus-cni.io/default-network: kube-system/oci-vcn-native-network
    k8s.v1.cni.cncf.io/networks: default/ipvlan-network

1. ポッドについて説明し、Multusネットワーク・ステータス注釈(存在する場合)を確認します。

   kubectl describe pod <pod-name>

2. ご使用の環境で許可されている場合、ポッドにexecを実行してインタフェースを検査し(たとえば、ifconfigまたはip addr)、ポッドに予期されるインタフェース(eth0、net1、...)およびIPアドレスがあることを確認します。