マルチスCNIプラグインを使用したOKEへのSR-IOV対応ネットワーク・インタフェース・コンテナ・アプリケーションのデプロイ

はじめに

このチュートリアルでは、高度なネットワーキング機能を活用して、Oracle Cloud Infrastructure Kubernetes Engine (OKE)内の仮想インスタンス・ワーカー・ノードにコンテナ化されたアプリケーションをデプロイする方法を説明します。具体的には、コンテナ・ネットワーク・インタフェースに対してシングル・ルートI/O仮想化(SR-IOV)を有効にし、マルチ・ホーム・ネットワーキングをコンテナに対して有効にするようにマルチ・ルートCNIプラグインを構成します。

SR-IOVとMultusを組み合わせることで、AI、機械学習、リアルタイム・データ処理などの特殊なワークロード向けに、高パフォーマンスで低レイテンシのネットワーキングを実現できます。このチュートリアルでは、OKE環境の構成、SR-IOV対応インタフェースを使用したワーカー・ノードのデプロイ、およびマルチスCNIを使用したポッド内の複数のネットワーク・インタフェースの管理の手順を説明します。高速パケット処理を目指す場合でも、Kubernetesネットワーキングを微調整する必要がある場合でも、このチュートリアルでは、開始するためのツールと知識を提供します。

ノート:

このチュートリアルの公開時点では、SR-IOV CNIは、OKEクラスタの一部である仮想インスタンス上のポッドまたはコンテナとMultus CNIプラグインでは使用できません。

このチュートリアルでは、OKEクラスタの一部である仮想インスタンス上のポッドまたはコンテナで実行されているポッド内でSR-IOV対応インタフェースを使用する方法を示します。仮想ネットワーク・インタフェース・カード(VNIC)(仮想インスタンス上)をポッドに格納し、マルチスCNIプラグイン(SR-IOV CNIプラグインはまったく使用されない)の助けを借りて使用できます。

SR-IOV CNIプラグインは、OKEクラスタの一部であるベア・メタル・インスタンスとMultus CNIプラグインでサポートされています。このチュートリアルでは対象外です。

イメージ

目的

マルチスCNIプラグインを使用して、SR-IOV対応ネットワーク・インタフェースを使用して、OKE内の仮想インスタンス・ワーカー・ノードにコンテナ・アプリケーションをデプロイします。

タスク1: 要塞、オペレータ、3つのVMワーカー・ノードおよびFlannel CNIプラグインを使用したOKEのデプロイ

次の設定でOKEがデプロイされていることを確認します。

要塞
オペレータ
3 VMワーカー・ノード
Flannel CNIプラグイン

この設定の詳細は、次のチュートリアルを参照してください: Oracle Cloud Infrastructure Kubernetes Engineを使用したTerraformを使用したKubernetesクラスタのデプロイ。

次のイメージは、このチュートリアル全体で使用するコンポーネントの概要を示しています。

イメージ

タスク2: 各ワーカー・ノードでのSR-IOV (ハードウェア支援)ネットワーキングの有効化

ノート:次のステップは、OKEクラスタの一部であるすべてのワーカー・ノードで実行する必要があります。

次の図は、このチュートリアル全体で使用するOKEクラスタ内のワーカー・ノードの概要を示しています。

イメージ

インスタンスでのSR-IOVの有効化

SSHを使用してインスタンスまたはワーカー・ノードにログインします。
1. lspciコマンドを実行して、すべてのVNICで現在使用されているネットワークドライバを確認します。
2. Virtioネットワークドライバが使用されていることに注意してください。
1. OCIコンソールの「インスタンスの詳細」ページに移動します。
2. 下へスクロール
3. NICアタッチメント・タイプがPARAVIRTUALIZEDになりました。
1. OCIコンソールの「インスタンスの詳細」ページに移動します。
2. 「他のアクション」をクリックします。
3. 「編集」をクリックします。
「詳細オプションの表示」をクリックします。
1. 「起動オプション」をクリックし、「ネットワーキング・タイプ」として「ハードウェア支援(SR-IOV)ネットワーキング」を選択します。
2. 「変更の保存」をクリックします。
「インスタンスの再起動」をクリックして、インスタンスの再起動を確認します。
インスタンスのステータスがSTOPPINGに変更されたことに注意してください。
インスタンス・ステータスがSTARTINGに変更されたことに注意してください。
インスタンス・ステータスが「RUNNING」に変更されたことに注意してください。
1. 下へスクロール
2. NICアタッチメント・タイプがVFIOになりました。
次の図は、これまでに構成した内容の概要を示しています。

タスク3: SR-IOV対応VNICの新しいサブネットの作成

SR-IOV対応のインタフェースが使用する専用のサブネットを作成します。

タスク3.1: セキュリティ・リストの作成

すでに他のサブネットにセキュリティ・リストを使用しているため、新しく作成されたSR-IOVサブネット専用のセキュリティ・リストも必要です。

OCIコンソールに移動します。
1. 「Virtual Cloud Networks」に移動します。
2. 既存のVCNをクリックします。
1. 「Security Lists」をクリックします。
2. 「セキュリティ・リストの作成」をクリックします。
「イングレス・ルール1」に、次の情報を入力します。
1. 「名前」を入力します。
2. 「ソース・タイプ」として「CIDR」を選択します。
3. 「ソースCIDR」に0.0.0.0/0と入力します。
4. 「IPプロトコル」に「すべてのプロトコル」を選択します。
5. 下へスクロール
1. 「エグレス・ルール1」に、次の情報を入力します。
2. 「ソース・タイプ」として「CIDR」を選択します。
3. 「ソースCIDR」に0.0.0.0/0と入力します。
4. 「IPプロトコル」に「すべてのプロトコル」を選択します。
5. 「セキュリティ・リストの作成」をクリックします。
新しいセキュリティ・リストが作成されることに注意してください。

タスク3.2: サブネットの作成

「Virtual Cloud Network Details」ページに移動します。
1. 「サブネット」をクリックします。
2. OKE環境用にすでに作成されている既存のサブネットに注意してください。
3. 「サブネットの作成」をクリックします。
1. 「名前」を入力します。
2. 「IPv4 CIDRブロック」を入力します。
3. 下へスクロール
1. 「プライベート・サブネット」を選択します。
2. 下へスクロール
1. 「DHCPオプション」で「DHCPのデフォルト・オプション」を選択します。
2. タスク3.1で作成した「セキュリティ・リスト」を選択します。
3. 「サブネットの作成」をクリックします。
ネット・サブネットが作成されることに注意してください。
ノート:
- サブネット自体には、SR-IOV対応の技術コンポーネントはありません。
- このチュートリアルでは、SR-IOVテクノロジを使用してトラフィックを転送できるように、標準のOCIサブネットを使用しています。
次の図は、これまでに構成した内容の概要を示しています。

タスク4: 2番目のVNICアタッチメントの追加

次の図は、2番目のVNICを追加する前にワーカー・ノード・サブネットに接続された単一のVNICがワーカー・ノードにどのように存在するかの視覚的な概要を示しています。

イメージ

2番目のVNICアタッチメントをワーカー・ノードに追加する前に、ネットワーク・セキュリティ・グループを作成します。

タスク4.1: ネットワーク・セキュリティ・グループ(NSG)の作成

すでに他のVNICにNSGを使用していますが、OKEクラスタの一部であり、Kubernetesワーカー・ノードとして役割を果たす既存の仮想インスタンスに追加する、新しく作成されたVNICの専用NSGも必要です。このインタフェースは、SR-IOVが有効になっている VNICになります。

「Virtual Cloud Network Details」ページに移動します。
1. 「ネットワーク・セキュリティ・グループ」に移動します。
2. 「ネットワーク・セキュリティ・グループの作成」をクリックします。
次のルールを追加します。
1. イングレス:
  - ソース・タイプを許可: 「CIDR」を選択します。
  - ソース: 0.0.0.0/0と入力します。
  - 宛先:宛先は空白のままにします。
  - プロトコル:すべてのプロトコルを許可します。
2. エグレス:
  - ソース・タイプを許可: 「CIDR」を選択します。
  - ソース:ソースは空白のままにします。
  - 宛先: 0.0.0.0/0と入力します。
  - プロトコル:すべてのプロトコルを許可します。
NSGが作成されることに注意してください。これを(OKEクラスタ内の各ワーカー・ノードで)作成する新しい(セカンダリ)VNICに適用します。

タスク4.2: VNICの追加

各仮想ワーカー・ノード・インスタンスに移動し、各ワーカー・ノードに2番目のVNICを追加します。
1. 各仮想ワーカー・ノード・インスタンスに移動し、「アタッチされたVNIC」をクリックします。
2. 既存のVNICがすでに存在することに注意してください。
3. 「VNICの作成」をクリックして、2番目のVNICを追加します。
1. 「名前」を入力します。
2. VCNを選択します。
3. タスク3.2で作成した「サブネット」を選択します。
4. 「ネットワーク・セキュリティ・グループを使用してトラフィックを制御」を選択します。
5. タスク4.1で作成したNSGを選択します。
6. 下へスクロール
1. 「プライベートIPv4アドレスの自動割当て」を選択します。
2. 「変更の保存」をクリックします。
2番目のVNICが作成され、仮想ワーカー・ノード・インスタンスにアタッチされ、サブネットにもアタッチされることに注意してください。
SSHを使用してインスタンスまたはワーカー・ノードにログインします。
1. lspciコマンドを実行して、すべてのVNICで現在使用されているネットワークドライバを確認します。
2. Mellanox Technologies ConnectX Family mlx5Gen Virtual Functionネットワーク・ドライバが使用されていることに注意してください。
Mellanox TechnologiesのConnectXファミリmlx5Gen仮想機能ネットワーク・ドライバは、SR-IOVで使用される仮想機能(VF)ドライバです。そのため、VFを使用したSR-IOVに対して VNICが有効になっています。
次の図は、これまでに構成した内容の概要を示しています。

タスク5: デフォルト・ゲートウェイを使用した新しい2番目のVNICへのIPアドレスの割当て

タスク4で2番目のVNICが作成され、アタッチされたので、それにIPアドレスを割り当てる必要があります。2番目のインタフェースをインスタンスに追加する場合、最初のインタフェースと同じサブネットに割り当てるか、新しいサブネットを選択できます。

2番目のインタフェースではDHCPが有効になっていないため、IPアドレスを手動で割り当てる必要があります。

2番目のインタフェースにIPアドレスを割り当てるには、さまざまな方法があります。

方法1: OCI-network-configコマンドを使用して、Oracle Cloud Infrastructureコマンドライン・インタフェース(OCI CLI) (oci-utilsパッケージ)を使用して、OCIコンピュート・インスタンスの2番目のインタフェースにIPアドレスを割り当てます。
方法2: OCI CLI (oci-utilsパッケージ)を使用して、ocidデーモンを使用して、OCIコンピュート・インスタンスの2番目のインタフェースにIPアドレスを割り当てます。
方法3: OCI_Multi_VNIC_Setupスクリプトを使用します。
方法4:新しいVNICのインタフェース構成ファイルを/etc/sysconfig/network-scripts/フォルダに手動で作成します。

すべてのワーカー・ノードについて、セカンダリvNIC (ens5)にIPアドレスを割り当てました。方法3を使用して、セカンダリvNIC (ens5)にIPアドレスを割り当てました。2番目のVNICへのIPアドレスの割当ての詳細は、「Oracle Linuxインスタンスの2番目のインタフェースへのIPアドレスの割当て」を参照してください。

IPアドレスが VNICに割り当てられたら、2番目のVNICのIPアドレスが正しく構成されているかどうかを確認する必要があります。また、すべてのノード・プール・ワーカー・ノードでSR-IOVを有効にしたかどうかを確認することもできます。

OKEクラスタは次のもので構成されます。

ノード・プール
NP1	1 xワーカー・ノード
NP2	3 xワーカー・ノード

すべてのノード・プール内のすべてのワーカー・ノードを確認します。

タスク5.1: ノード・プール1のすべてのノードの確認(`np1`)

OKEクラスタで「ノード」をクリックします。
最初のノード・プール(np1)をクリックします。
このノード・プールの一部であるワーカー・ノードをクリックします。
1. NICアタッチメント・タイプがVFIOであることに注意してください(これは、この仮想インスタンス・ワーカー・ノードでSR-IOVが有効になっていることを意味します)。
2. 2番目のVNICが作成され、このワーカー・ノードにアタッチされていることに注意してください。

タスク5.2: ノード・プール2のすべてのノードの確認(`np2`)

ノードを1つずつクリックし、検証を開始します。
1. NICアタッチメント・タイプがVFIOであることに注意してください(これは、この仮想インスタンス・ワーカー・ノードでSR-IOVが有効になっていることを意味します)。
2. 2番目のVNICが作成され、このワーカー・ノードにアタッチされていることに注意してください。
ノード・プール2 (np2)のサマリー・ページに移動します。ノード・プールの2番目のワーカー・ノードをクリックします。
1. NICアタッチメント・タイプがVFIOであることに注意してください(これは、この仮想インスタンス・ワーカー・ノードでSR-IOVが有効になっていることを意味します)。
2. 2番目のVNICが作成され、このワーカー・ノードにアタッチされていることに注意してください。
ノード・プール2 (np2)のサマリー・ページに移動します。ノード・プールの3番目のワーカー・ノードをクリックします。
1. NICアタッチメント・タイプがVFIOであることに注意してください(これは、この仮想インスタンス・ワーカー・ノードでSR-IOVが有効になっていることを意味します)。
2. 2番目のVNICが作成され、このワーカー・ノードにアタッチされていることに注意してください。

SSHを使用してKubernetes Operatorにログインします。

kubectl get nodesコマンドを実行して、すべてのワーカー・ノードのリストおよびIPアドレスを取得します。

[opc@o-sqrtga ~]$ kubectl get nodes
NAME           STATUS   ROLES   AGE   VERSION
10.0.112.134   Ready    node    68d   v1.30.1
10.0.66.97     Ready    node    68d   v1.30.1
10.0.73.242    Ready    node    68d   v1.30.1
10.0.89.50     Ready    node    68d   v1.30.1
[opc@o-sqrtga ~]$

すべてのワーカー・ノードへのSSHを容易にするために、次の表を作成しました。

ワーカー・ノード名	ens3 IP	SSHコマンドworkernode
cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0	10.0.112.134	`ssh -i id_rsa opc@10.0.112.134`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1	10.0.66.97	`ssh -i id_rsa opc@10.0.66.97`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0	10.0.73.242	`ssh -i id_rsa opc@10.0.73.242`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2	10.0.89.50	`ssh -i id_rsa opc@10.0.89.50`

すべての仮想ワーカー・ノードにSSHを実行する前に、使用可能な秘密キーが正しいことを確認してください。
ssh -i <private key> opc@<ip-address>コマンドを実行して、すべてのワーカー・ノードにSSHを実行します。

イメージ

cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0ワーカー・ノードでip aコマンドを実行します。

IPアドレスが正常に構成されると、ens5 (2番目のVNIC)には、SR-IOVインタフェース用にタスク3.2で作成したサブネットの範囲内のIPアドレスが含まれます。

[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:59:58 brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.112.134/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 85530sec preferred_lft 85530sec
   inet6 fe80::17ff:fe00:5958/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:d4:a2 brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.30/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::8106:c09e:61fa:1d2a/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 3a:b7:fb:e6:2e:cf brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.0/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::38b7:fbff:fee6:2ecf/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether de:35:f5:51:85:5d brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.1/25 brd 10.244.1.127 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::dc35:f5ff:fe51:855d/64 scope link
      valid_lft forever preferred_lft forever
6: veth1cdaac17@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 76:e2:92:ad:37:40 brd ff:ff:ff:ff:ff:ff link-netns 1935ba66-34cc-4468-8abb-f66add46d08b
   inet6 fe80::74e2:92ff:fead:3740/64 scope link
      valid_lft forever preferred_lft forever
7: vethbcd391ab@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 9a:9a:0f:d6:48:17 brd ff:ff:ff:ff:ff:ff link-netns 3f02d5fd-596e-4b9f-8a35-35f2f946901b
   inet6 fe80::989a:fff:fed6:4817/64 scope link
      valid_lft forever preferred_lft forever
8: vethc15fa705@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 3a:d2:c8:66:d1:0b brd ff:ff:ff:ff:ff:ff link-netns f581b7f2-cfa0-46eb-b0aa-37001a11116d
   inet6 fe80::38d2:c8ff:fe66:d10b/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$

cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1ワーカー・ノードでip aコマンドを実行します。

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:16:ca brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.66.97/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 85859sec preferred_lft 85859sec
   inet6 fe80::17ff:fe00:16ca/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:7b:4f brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.15/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::87eb:4195:cacf:a6da/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 02:92:e7:f5:8e:29 brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.128/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::92:e7ff:fef5:8e29/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether f6:08:06:e2:bc:9d brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.129/25 brd 10.244.1.255 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::f408:6ff:fee2:bc9d/64 scope link
      valid_lft forever preferred_lft forever
6: veth5db97290@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether c2:e0:b5:7e:ce:ed brd ff:ff:ff:ff:ff:ff link-netns 3682b5cd-9039-4931-aecc-b50d46dabaf1
   inet6 fe80::c0e0:b5ff:fe7e:ceed/64 scope link
      valid_lft forever preferred_lft forever
7: veth6fd818a5@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 3e:a8:7d:84:d3:b9 brd ff:ff:ff:ff:ff:ff link-netns 08141d6b-5ec0-4f3f-a312-a00b30f82ade
   inet6 fe80::3ca8:7dff:fe84:d3b9/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$

cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0ワーカー・ノードでip aコマンドを実行します。

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:49:9c brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.73.242/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 86085sec preferred_lft 86085sec
   inet6 fe80::17ff:fe00:499c/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:b7:51 brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.14/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::bc31:aa09:4e05:9ab7/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 9a:c7:1b:30:e8:9a brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.0/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::98c7:1bff:fe30:e89a/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether 2a:2b:cb:fb:15:82 brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.1/25 brd 10.244.0.127 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::282b:cbff:fefb:1582/64 scope link
      valid_lft forever preferred_lft forever
6: veth06343057@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether ca:70:83:13:dc:ed brd ff:ff:ff:ff:ff:ff link-netns fb0f181f-7c3a-4fb6-8bf0-5a65d39486c1
   inet6 fe80::c870:83ff:fe13:dced/64 scope link
      valid_lft forever preferred_lft forever
7: veth8af17165@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether c6:a0:be:75:9b:d9 brd ff:ff:ff:ff:ff:ff link-netns c07346e6-33f5-4e80-ba5e-74f7487b5daa
   inet6 fe80::c4a0:beff:fe75:9bd9/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$

cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2ワーカー・ノードでip aコマンドを実行します。

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:ac:7c brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.89.50/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 86327sec preferred_lft 86327sec
   inet6 fe80::17ff:fe00:ac7c/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:4c:0d brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.16/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::91eb:344e:829e:35de/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether aa:31:9f:d0:b3:3c brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.128/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::a831:9fff:fed0:b33c/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether b2:0d:c0:de:02:61 brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.129/25 brd 10.244.0.255 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::b00d:c0ff:fede:261/64 scope link
      valid_lft forever preferred_lft forever
6: vethb37e8987@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 7a:93:1d:2a:33:8c brd ff:ff:ff:ff:ff:ff link-netns ab3262ca-4a80-4b02-a39f-4209d003f148
   inet6 fe80::7893:1dff:fe2a:338c/64 scope link
      valid_lft forever preferred_lft forever
7: veth73a651ce@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether ae:e4:97:89:ba:6e brd ff:ff:ff:ff:ff:ff link-netns 9307bfbd-8165-46bf-916c-e1180b6cbd83
   inet6 fe80::ace4:97ff:fe89:ba6e/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$

2番目のVNIC (ens5)ですべてのIPアドレスが構成されていることを確認しました。この情報を含む次の表を作成できます。

ens3 IP	ens3GW	ens5 IP	ens5GW
10.0.112.134	10.0.64.1	10.0.3.30/27	10.0.3.1
10.0.66.97	10.0.64.1	10.0.3.15/27	10.0.3.1
10.0.73.242	10.0.64.1	10.0.3.14/27	10.0.3.1
10.0.89.50	10.0.64.1	10.0.3.16/27	10.0.3.1

次の図は、これまでに構成した内容の概要を示しています。

タスク6: ワーカー・ノードへのメタプラグインCNI (マルチCNI)のインストール

Multus CNIは、複数のネットワーク・インタフェースをポッドにアタッチできるKubernetesのコンテナ・ネットワーク・インタフェース(CNI)プラグインです。

マルチスCNIの仕組み

メタプラグインとして機能: Multusはネットワーク自体を提供せず、かわりに他のCNIプラグインをコールします。
複数のネットワーク・インタフェースの作成:各ポッドは、複数のCNIプラグイン(Flannel、Calico、SR-IOVなど)を組み合せることで、複数のネットワーク・インタフェースを持つことができます。
構成ファイルの使用:プライマリ・ネットワークはデフォルトのCNIを使用して設定され、追加のネットワークはカスタム・リソース定義(CRD)に基づいてアタッチされます。

マルチCNIが必要な理由

複数のネットワーク分離:別個の管理およびデータ・プレーンを必要とするワークロードに役立ちます。
高パフォーマンス・ネットワーキング: SR-IOVまたはDPDKを使用した直接ハードウェア・アクセスを有効にします。
ポッドのマルチホーミング:複数のネットワーク・インタフェースが不可欠なネットワーク機能仮想化(NFV)およびTelcoのユースケースをサポートします。

タスク6.1: シン・インストール方法を使用したマルチスCNIのインストール

Kubernetes OperatorにSSH接続します。
1. 次のコマンドを実行して、Multus Gitライブラリをクローニングします。
```
git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
```
2. 次のコマンドを実行して、thinインストール方法を使用してMultusデーモン・セットをインストールします。
```
kubectl apply -f deployments/multus-daemonset.yml && cd ..
```

Multusデーモン設定の動作

マルチス・デーモン・セットを起動します。これにより、/opt/cni/binの各ノードにマルチス・バイナリを配置する各ノードでポッドが実行されます。
/etc/cni/net.dの辞書順(アルファベット順)の最初の構成ファイルを読み込み、各ノードにMultusの新しい構成ファイルを/etc/cni/net.d/00-multus.confとして作成します。この構成は自動生成され、デフォルトのネットワーク構成(アルファベット順の最初の構成とみなされます)に基づいています。
Kubernetes APIにアクセスするためのMultusの認証情報を使用して、各ノードに/etc/cni/net.d/multus.dという名前のディレクトリを作成します。

タスク6.2: マルチ・インストールの検証

次のコマンド(Kubernetesオペレータ)を実行して、Multusデーモン・セットがすべてのワーカー・ノードにインストールされているかどうかを検証します。
```
kubectl get pods --all-namespaces | grep -i multus
```
マルチス・デーモン・セットがワーカー・ノード自体にインストールされているかどうかを確認することもできます。
1. 次のコマンドを使用して、ssh -i id_rsa opc@10.0.112.134コマンドを実行してワーカー・ノードにSSHを実行します。
2. cd /etc/cni/net.d/コマンドを実行して、次のコマンドを使用してディレクトリを変更します。
3. ls -lコマンドを実行して、次のコマンドを使用してディレクトリ出力をリストします。
4. 00-multus.confおよびmultus.dファイルがリストされていることに注意してください。
1. sudo more 00-multus.confコマンドを実行して、00-multus.confファイルの内容を表示します。
2. 00-multus.confファイルの内容を確認します。

タスク7: ポッドへのネットワーク・インタフェースのアタッチ

このタスクでは、このVNICにコンテナ・インタフェースをマップまたはアタッチします。

ポッドに追加のインタフェースをアタッチするには、インタフェースをアタッチするための構成が必要です。

これは、NetworkAttachmentDefinition型のカスタム・リソースにカプセル化されます。
この構成は、基本的にカスタム・リソースとしてパッケージ化されたCNI構成です。

これを実現するためにMultusとともに使用できるCNIプラグインがいくつかあります。詳細は、プラグインの概要を参照してください。

ここで説明するアプローチでは、目標は、単一のポッドに対してSR-IOV仮想機能(VF)を排他的に提供することで、ポッドが干渉やその間のレイヤーなしで機能を利用できるようにします。
VFへのポッド排他アクセス権を付与するために、インタフェースをポッドのネームスペースに移動できるようにするホストデバイスプラグインを活用して、そのインタフェースに排他アクセスできるようにします。詳細は、host-deviceを参照してください。

次の例は、ノードに追加されたセカンダリens5インタフェースを構成するNetworkAttachmentDefinitionオブジェクトを示しています。

ipamプラグイン構成は、これらのインタフェースのIPアドレスの管理方法を決定します。
この例では、OCIによってセカンダリ・インタフェースに割り当てられたものと同じIPアドレスを使用するため、静的ipam構成を適切なルートとともに使用します。
ipam構成では、より柔軟な構成のために、host-localやdhcpなどの他のメソッドもサポートされています。

タスク7.1: ネットワーク添付定義の作成

NetworkAttachmentDefinitionは、ポッドのセカンダリ・インタフェースなど、ネットワーク・アタッチメントの設定に使用されます。

NetworkAttachmentDefinitionを構成するには、2つの方法があります。

NetworkAttachmentDefinition (JSON CNI構成あり)。
CNI構成ファイルを含むNetworkAttachmentDefinition。

ノート:このチュートリアルでは、CNI構成ファイルを使用してメソッドを使用します。

4つのxワーカー・ノードがあり、各ワーカー・ノードには、コンテナ(ポッド)上のインタフェースにマップする2番目のVNICがあります。

次のコマンドを実行して、すべてのワーカー・ノードおよび対応するVNICのCNI構成ファイルを作成します。

ens3	ens5	name	ネットワーク	nanoコマンド
10.0.112.134	10.0.3.30/27	sriov-vnic-1	10.0.3.0/27	`sudo nano sriov-vnic-1.yaml`
10.0.66.97	10.0.3.15/27	sriov-vnic-2	10.0.3.0/27	`sudo nano sriov-vnic-2.yaml`
10.0.73.242	10.0.3.14/27	sriov-vnic-3	10.0.3.0/27	`sudo nano sriov-vnic-3.yaml`
10.0.89.50	10.0.3.16/27	sriov-vnic-4	10.0.3.0/27	`sudo nano sriov-vnic-4.yaml`

Kubernetesオペレータで次のステップを実行します。sudo nano sriov-vnic-1.yamlコマンドを使用して、最初のワーカー・ノードの新規YAMLファイルを作成します。
- 名前が一意でわかりやすいものであることを確認してください。この例では、sriov-vnic-1を使用しています。
- 追加した2番目のアダプタのIPアドレス(ens5)を使用します。
- dst networkも正しいことを確認します。これは、タスク3.2で作成したサブネットと同じです。
sriov-vnic-1.yaml:
```
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.3.30/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'
```

sudo nano sriov-vnic-2.yamlコマンドを使用して、2番目のワーカー・ノード用の新しいYAMLファイルを作成します。

sriov-vnic-2.yaml:

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.3.15/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

sudo nano sriov-vnic-3.yamlコマンドを使用して、3番目のワーカー・ノード用の新しいYAMLファイルを作成します。

sriov-vnic-3.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-3
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.14/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

sudo nano sriov-vnic-4.yamlコマンドを使用して、4番目のワーカー・ノード用の新しいYAMLファイルを作成します。

sriov-vnic-4.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-4
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.16/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

NetworkAttachmentDefinitionをワーカー・ノードに適用します。
- 最初のノードに対してkubectl apply -f sriov-vnic-1.yamlコマンドを実行します。
- 2番目のノードに対してkubectl apply -f sriov-vnic-2.yamlコマンドを実行します。
- 3番目のノードに対してkubectl apply -f sriov-vnic-3.yamlコマンドを実行します。
- 4番目のノードに対してkubectl apply -f sriov-vnic-4.yamlコマンドを実行します。
NetworkAttachmentDefinitionが正しく適用されている場合は、出力に類似した内容が表示されます。
```
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-1.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-2.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-3.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-4.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 created
[opc@o-sqrtga ~]$
```

kubectl get network-attachment-definitions.k8s.cni.cncf.ioコマンドを実行して、NetworkAttachmentDefinitionsが正しく適用されているかどうかを確認します。

[opc@o-sqrtga ~]$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME           AGE
sriov-vnic-1   96s
sriov-vnic-2   72s
sriov-vnic-3   60s
sriov-vnic-4   48s
[opc@o-sqrtga ~]$

kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 -o yamlコマンドを実行して、最初のワーカー・ノードに適用されたNetworkAttachmentDefinitionを取得します。

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-1","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.30/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:03:55Z"
generation: 1
name: sriov-vnic-1
namespace: default
resourceVersion: "22915413"
uid: 2d529130-2147-4f49-9d78-4e5aa12aea62
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.30/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 -o yamlコマンドを実行して、2番目のワーカー・ノードに適用されたNetworkAttachmentDefinitionを取得します。

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-2","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.15/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:19Z"
generation: 1
name: sriov-vnic-2
namespace: default
resourceVersion: "22915508"
uid: aec5740c-a093-43d3-bd6a-2209ee9e5c96
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.15/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 -o yamlコマンドを実行して、3番目のワーカー・ノードに適用されたNetworkAttachmentDefinitionを取得します。

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-3","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.14/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:31Z"
generation: 1
name: sriov-vnic-3
namespace: default
resourceVersion: "22915558"
uid: 91b970ff-328f-4b6b-a0d8-7cdd07d7bca3
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.14/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 -o yamlコマンドを実行して、4番目のワーカー・ノードに適用されたNetworkAttachmentDefinitionを取得します。

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-4","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.16/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:43Z"
generation: 1
name: sriov-vnic-4
namespace: default
resourceVersion: "22915607"
uid: 383fd3f0-7e5e-46ec-9997-29cbc9a2dcea
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.16/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'
[opc@o-sqrtga ~]$

次の図は、これまでに構成した内容の概要を示しています。

タスク7.2: `NetworkDefinitionAttachment`がアタッチされたポッドの作成

このタスクでは、NetworkAttachmentDefinitionsを実際のコンテナまたはポッドに関連付けます。

次の表では、どのポッドをどのワーカー・ノードにホストするかについてのマッピングを作成しました。

ワーカー(プライマリ)ノードIP	ens5	name	POD名	終了
10.0.112.134	10.0.3.30/27	sriov-vnic-1	testpod1	YES
10.0.66.97	10.0.3.15/27	sriov-vnic-2	testpod2	YES
10.0.73.242	10.0.3.14/27	sriov-vnic-3	testpod3	YES
10.0.89.50	10.0.3.16/27	sriov-vnic-4	testpod4	YES

タスク7.3: ノード・アフィニティを使用したポッドの作成

デフォルトでは、Kubernetesはポッドを配置する場所(ワーカー・ノード)を決定します。この例では、NetworkAttachmentDefinitionがIPアドレスにバインドされ、このIPアドレスがVNICにバインドされ、このVNICが特定のワーカー・ノードにバインドされているため、これはできません。したがって、作成するポッドが目的のワーカー・ノードに終わることを確認する必要があります。これは、NetworkAttachmentDefinitionをポッドにアタッチするときに必要です。

これを行わないと、ポッドでIPアドレスを使用できる別の場所にポッドが立ち上がる可能性があります。したがって、ポッドはSR-IOV対応インタフェースを使用して通信できません。

kubectl get nodesコマンドを使用して、使用可能なすべてのノードを取得します。

[opc@o-sqrtga ~]$ kubectl get nodes
NAME           STATUS   ROLES   AGE   VERSION
10.0.112.134   Ready    node    68d   v1.30.1
10.0.66.97     Ready    node    68d   v1.30.1
10.0.73.242    Ready    node    68d   v1.30.1
10.0.89.50     Ready    node    68d   v1.30.1
[opc@o-sqrtga ~]$

kubectl label node 10.0.112.134 node_type=testpod1コマンドを使用して、ワーカー・ノード1にラベルを割り当てます。
kubectl label node 10.0.66.97 node_type=testpod2コマンドを使用して、ワーカー・ノード2にラベルを割り当てます。
kubectl label node 10.0.73.242 node_type=testpod3コマンドを使用して、ワーカー・ノード3にラベルを割り当てます。
kubectl label node 10.0.89.50 node_type=testpod4コマンドを使用して、ワーカー・ノード4にラベルを割り当てます。

[opc@o-sqrtga ~]$ kubectl label node 10.0.112.134 node_type=testpod1
node/10.0.112.134 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.73.242 node_type=testpod3
node/10.0.73.242 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.66.97 node_type=testpod2
node/10.0.66.97 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.89.50 node_type=testpod4
node/10.0.89.50 labeled
[opc@o-sqrtga ~]$

次の図は、これまでに構成した内容の概要を示しています。

sudo nano testpod1-v2.yamlコマンドを使用して、testpod1のYAMLファイルを作成します。

前に作成したNetworkAttachmentDefinition (sriov-vnic-1)をこのテスト・ポッドにバインドするannotationsセクションに注意してください。
テスト・ポッドをラベルtestpod1を持つ特定のワーカー・ノードにバインドするspec:affinity:nodeAffinityセクションに注意してください。

sudo nano testpod1-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod1
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-1
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod1
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

sudo nano testpod2-v2.yamlコマンドを使用して、testpod2のYAMLファイルを作成します。

前に作成したNetworkAttachmentDefinition (sriov-vnic-2)をこのテスト・ポッドにバインドするannotationsセクションに注意してください。
テスト・ポッドをラベルtestpod2を持つ特定のワーカー・ノードにバインドするspec:affinity:nodeAffinityセクションに注意してください。

sudo nano testpod2-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod2
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-2
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod2
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

sudo nano testpod3-v2.yamlコマンドを使用して、testpod3のYAMLファイルを作成します。

前に作成したNetworkAttachmentDefinition (sriov-vnic-3)をこのテスト・ポッドにバインドするannotationsセクションに注意してください。
テスト・ポッドをラベルtestpod3を持つ特定のワーカー・ノードにバインドするspec:affinity:nodeAffinityセクションに注意してください。

sudo nano testpod3-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod3
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-3
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod3
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

sudo nano testpod4-v2.yamlコマンドを使用して、testpod4のYAMLファイルを作成します。
- 前に作成したNetworkAttachmentDefinition (sriov-vnic-4)をこのテスト・ポッドにバインドするannotationsセクションに注意してください。
- テスト・ポッドをラベルtestpod4を持つ特定のワーカー・ノードにバインドするspec:affinity:nodeAffinityセクションに注意してください
```
sudo nano testpod4-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod4
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-4
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod4
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]
```
- kubectl apply -f testpod1-v2.yamlコマンドを使用してYAMLファイルを適用して、testpod1を作成します。
- kubectl apply -f testpod2-v2.yamlコマンドを使用してYAMLファイルを適用して、testpod2を作成します。
- kubectl apply -f testpod3-v2.yamlコマンドを使用してYAMLファイルを適用して、testpod3を作成します。
- kubectl apply -f testpod4-v2.yamlコマンドを使用してYAMLファイルを適用して、testpod4を作成します。
```
[opc@o-sqrtga ~]$ kubectl apply -f testpod1-v2.yaml
pod/testpod1 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod2-v2.yaml
pod/testpod2 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod3-v2.yaml
pod/testpod3 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod4-v2.yaml
pod/testpod4 created
[opc@o-sqrtga ~]$
```

kubectl get podコマンドを使用して、テスト・ポッドが作成されているかどうかを確認します。すべてのテスト・ポッドが作成され、Running STATUSが設定されていることに注意してください。

[opc@o-sqrtga ~]$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-576c6b7b6-6fn6f   1/1     Running   3          40d
my-nginx-576c6b7b6-k9wwc   1/1     Running   3          40d
my-nginx-576c6b7b6-z8xkd   1/1     Running   6          40d
mysql-6d7f5d5944-dlm78     1/1     Running   12         35d
testpod1                   1/1     Running   0          2m29s
testpod2                   1/1     Running   0          2m17s
testpod3                   1/1     Running   0          2m5s
testpod4                   1/1     Running   0          111s
[opc@o-sqrtga ~]$

kubectl get pod testpod1 -o wideコマンドを使用して、ラベルtestpod1を使用してワーカー・ノード10.0.112.134でtestpod1が実行されているかどうかを確認します。

[opc@o-sqrtga ~]$ kubectl get pod testpod1 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE           NOMINATED NODE   READINESS GATES
testpod1   1/1     Running   0          3m41s   10.244.1.6   10.0.112.134   <none>           <none>

kubectl get pod testpod2 -o wideコマンドを使用して、ラベルtestpod2を使用してワーカー・ノード10.0.66.97でtestpod2が実行されているかどうかを確認します。

[opc@o-sqrtga ~]$ kubectl get pod testpod2 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
testpod2   1/1     Running   0          3m33s   10.244.1.133   10.0.66.97   <none>           <none>

kubectl get pod testpod3 -o wideコマンドを使用して、ラベルtestpod3を使用してワーカー・ノード10.0.73.242でtestpod3が実行されているかどうかを確認します。

[opc@o-sqrtga ~]$ kubectl get pod testpod3 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE          NOMINATED NODE   READINESS GATES
testpod3   1/1     Running   0          3m25s   10.244.0.5   10.0.73.242   <none>           <none>

kubectl get pod testpod4 -o wideコマンドを使用して、ラベルtestpod4を使用してワーカー・ノード10.0.89.50でtestpod4が実行されているかどうかを確認します。

[opc@o-sqrtga ~]$ kubectl get pod testpod4 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
testpod4   1/1     Running   0          3m22s   10.244.0.133   10.0.89.50   <none>           <none>

次の図は、これまでに構成した内容の概要を示しています。

タスク7.4: テスト・ポッドのIPアドレスの確認

kubectl exec -it testpod1 -- ip addr showコマンドを使用して、net1ポッド・インタフェースのtestpod1のIPアドレスを確認します。

net1インタフェースのIPアドレスは10.0.3.30/27であることに注意してください。

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether ca:28:e4:5f:66:c4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.0.132/25 brd 10.244.0.255 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::c828:e4ff:fe5f:66c4/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:4c:0d brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.30/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:4c0d/64 scope link
	valid_lft forever preferred_lft forever

kubectl exec -it testpod2 -- ip addr showコマンドを使用して、net1ポッド・インタフェースのtestpod2のIPアドレスを確認します。

net1インタフェースのIPアドレスは10.0.3.15/27であることに注意してください。

[opc@o-sqrtga ~]$ kubectl exec -it testpod2 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether da:ce:84:22:fc:29 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.1.132/25 brd 10.244.1.255 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::d8ce:84ff:fe22:fc29/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:7b:4f brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.15/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:7b4f/64 scope link
	valid_lft forever preferred_lft forever

kubectl exec -it testpod3 -- ip addr showコマンドを使用して、net1ポッド・インタフェースのtestpod3のIPアドレスを確認します。

net1インタフェースのIPアドレスは10.0.3.14/27であることに注意してください。

[opc@o-sqrtga ~]$ kubectl exec -it testpod3 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether de:f2:81:10:04:b2 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.0.4/25 brd 10.244.0.127 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::dcf2:81ff:fe10:4b2/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:b7:51 brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.14/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:b751/64 scope link
	valid_lft forever preferred_lft forever

kubectl exec -it testpod4 -- ip addr showコマンドを使用して、net1ポッド・インタフェースのtestpod4のIPアドレスを確認します。

net1インタフェースのIPアドレスは10.0.3.16/27であることに注意してください。

[opc@o-sqrtga ~]$ kubectl exec -it testpod4 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether ea:63:eb:57:9c:99 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.1.5/25 brd 10.244.1.127 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::e863:ebff:fe57:9c99/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:d4:a2 brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.16/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:d4a2/64 scope link
	valid_lft forever preferred_lft forever
[opc@o-sqrtga ~]$

次の表に、すべてのテスト・ポッドのnet1インタフェースのすべてのIPアドレスの概要を示します。

POD名	net1 IP
testpod1	10.0.3.30/27
testpod2	10.0.3.15/27
testpod3	10.0.3.14/27
testpod4	10.0.3.16/27

ノート:これらのIPアドレスは、SR-IOV対応のVNICを配置するためにタスク3で作成したOCIサブネットと同じ範囲にあります。

タスク7.5: ワーカー・ノードのIPアドレスの確認

テスト・ポッドのnet1インタフェースにIPアドレスが設定されたので、このIPアドレスはワーカー・ノード上のens5インタフェースのIPアドレスであったことに注意してください。このIPアドレスは、ens5ワーカー・ノード・インタフェースからnet1テスト・ポッド・インタフェースに移動されました。

ssh -i id_rsa opc@10.0.112.134コマンドを使用して、最初のワーカー・ノードにSSHを実行します。

ip aコマンドを使用して、すべてのインタフェースのIPアドレスを取得します。
ens5インタフェースがワーカー・ノードから削除されていることに注意してください。

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.112.134
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 20:42:19 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:59:58 brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.112.134/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82180sec preferred_lft 82180sec
	inet6 fe80::17ff:fe00:5958/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 3a:b7:fb:e6:2e:cf brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.0/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::38b7:fbff:fee6:2ecf/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether de:35:f5:51:85:5d brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.1/25 brd 10.244.1.127 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::dc35:f5ff:fe51:855d/64 scope link
	valid_lft forever preferred_lft forever
6: veth1cdaac17@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 76:e2:92:ad:37:40 brd ff:ff:ff:ff:ff:ff link-netns 1935ba66-34cc-4468-8abb-f66add46d08b
	inet6 fe80::74e2:92ff:fead:3740/64 scope link
	valid_lft forever preferred_lft forever
7: vethbcd391ab@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 9a:9a:0f:d6:48:17 brd ff:ff:ff:ff:ff:ff link-netns 3f02d5fd-596e-4b9f-8a35-35f2f946901b
	inet6 fe80::989a:fff:fed6:4817/64 scope link
	valid_lft forever preferred_lft forever
8: vethc15fa705@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 3a:d2:c8:66:d1:0b brd ff:ff:ff:ff:ff:ff link-netns f581b7f2-cfa0-46eb-b0aa-37001a11116d
	inet6 fe80::38d2:c8ff:fe66:d10b/64 scope link
	valid_lft forever preferred_lft forever
9: vethc663e496@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 7e:0b:bb:5d:49:8c brd ff:ff:ff:ff:ff:ff link-netns d3993135-0f2f-4b06-b16d-31d659f8230d
	inet6 fe80::7c0b:bbff:fe5d:498c/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ exit
logout
Connection to 10.0.112.134 closed.

ssh -i id_rsa opc@10.0.66.97コマンドを使用して、2番目のワーカー・ノードにSSHを実行します。

ip aコマンドを使用して、すべてのインタフェースのIPアドレスを取得します。
ens5インタフェースがワーカー・ノードから削除されていることに注意してください。

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.66.97
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 19:47:55 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:16:ca brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.66.97/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82502sec preferred_lft 82502sec
	inet6 fe80::17ff:fe00:16ca/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 02:92:e7:f5:8e:29 brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.128/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::92:e7ff:fef5:8e29/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether f6:08:06:e2:bc:9d brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.129/25 brd 10.244.1.255 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::f408:6ff:fee2:bc9d/64 scope link
	valid_lft forever preferred_lft forever
6: veth5db97290@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether c2:e0:b5:7e:ce:ed brd ff:ff:ff:ff:ff:ff link-netns 3682b5cd-9039-4931-aecc-b50d46dabaf1
	inet6 fe80::c0e0:b5ff:fe7e:ceed/64 scope link
	valid_lft forever preferred_lft forever
7: veth6fd818a5@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 3e:a8:7d:84:d3:b9 brd ff:ff:ff:ff:ff:ff link-netns 08141d6b-5ec0-4f3f-a312-a00b30f82ade
	inet6 fe80::3ca8:7dff:fe84:d3b9/64 scope link
	valid_lft forever preferred_lft forever
8: veth26f6b686@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ae:bf:36:ca:52:cf brd ff:ff:ff:ff:ff:ff link-netns f533714a-69be-4b20-be30-30ba71494f7a
	inet6 fe80::acbf:36ff:feca:52cf/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ exit
logout
Connection to 10.0.66.97 closed.

ssh -i id_rsa opc@10.0.73.242コマンドを使用して、3番目のワーカー・ノードにSSHを実行します。

ip aコマンドを使用して、すべてのインタフェースのIPアドレスを取得します。
ens5インタフェースがワーカー・ノードから削除されていることに注意してください。

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.73.242
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 20:08:31 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:49:9c brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.73.242/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82733sec preferred_lft 82733sec
	inet6 fe80::17ff:fe00:499c/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 9a:c7:1b:30:e8:9a brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.0/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::98c7:1bff:fe30:e89a/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether 2a:2b:cb:fb:15:82 brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.1/25 brd 10.244.0.127 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::282b:cbff:fefb:1582/64 scope link
	valid_lft forever preferred_lft forever
6: veth06343057@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ca:70:83:13:dc:ed brd ff:ff:ff:ff:ff:ff link-netns fb0f181f-7c3a-4fb6-8bf0-5a65d39486c1
	inet6 fe80::c870:83ff:fe13:dced/64 scope link
	valid_lft forever preferred_lft forever
7: veth8af17165@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether c6:a0:be:75:9b:d9 brd ff:ff:ff:ff:ff:ff link-netns c07346e6-33f5-4e80-ba5e-74f7487b5daa
	inet6 fe80::c4a0:beff:fe75:9bd9/64 scope link
	valid_lft forever preferred_lft forever
8: veth170b8774@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether e6:c9:42:60:8f:e7 brd ff:ff:ff:ff:ff:ff link-netns edef0c81-0477-43fa-b260-6b81626e7d87
	inet6 fe80::e4c9:42ff:fe60:8fe7/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ exit
logout
Connection to 10.0.73.242 closed.

ssh -i id_rsa opc@10.0.89.50コマンドを使用して、4番目のワーカー・ノードにSSHを実行します。

ip aコマンドを使用して、すべてのインタフェースのIPアドレスを取得します。
ens5インタフェースがワーカー・ノードから削除されていることに注意してください。

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.89.50
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 19:49:27 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:ac:7c brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.89.50/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82976sec preferred_lft 82976sec
	inet6 fe80::17ff:fe00:ac7c/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether aa:31:9f:d0:b3:3c brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.128/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::a831:9fff:fed0:b33c/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether b2:0d:c0:de:02:61 brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.129/25 brd 10.244.0.255 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::b00d:c0ff:fede:261/64 scope link
	valid_lft forever preferred_lft forever
6: vethb37e8987@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 7a:93:1d:2a:33:8c brd ff:ff:ff:ff:ff:ff link-netns ab3262ca-4a80-4b02-a39f-4209d003f148
	inet6 fe80::7893:1dff:fe2a:338c/64 scope link
	valid_lft forever preferred_lft forever
7: veth73a651ce@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ae:e4:97:89:ba:6e brd ff:ff:ff:ff:ff:ff link-netns 9307bfbd-8165-46bf-916c-e1180b6cbd83
	inet6 fe80::ace4:97ff:fe89:ba6e/64 scope link
	valid_lft forever preferred_lft forever
8: veth42c3a604@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether f2:e6:ba:72:8f:b2 brd ff:ff:ff:ff:ff:ff link-netns a7eb561c-8182-49b2-9e43-7c52845620a7
	inet6 fe80::f0e6:baff:fe72:8fb2/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ exit
logout
Connection to 10.0.89.50 closed.
[opc@o-sqrtga ~]$

次の図は、これまでに構成した内容の概要を示しています。

タスク8: 複数のポッド間のPingテストの実行

すべてのポッドには、SR-IOV対応VNICがアタッチされているOCIサブネットからのIPアドレスがあります。いくつかのpingテストを実行して、ネットワーク接続が正常に機能しているかどうかを確認できます。

次の表に、Kubernetesオペレータからテスト・ポッドに接続するコマンドを示します。

pingテストを実行するか、ルート表を参照するには、これを各ポッドにexecする必要があります。

ens3	net1	name	POD名	コマンド
10.0.112.134	10.0.3.30/27	sriov-vnic-1	testpod1	`kubectl exec -it testpod1 -- /bin/bash`
10.0.66.97	10.0.3.15/27	sriov-vnic-2	testpod2	`kubectl exec -it testpod2 -- /bin/bash`
10.0.73.242	10.0.3.14/27	sriov-vnic-3	testpod3	`kubectl exec -it testpod3 -- /bin/bash`
10.0.89.50	10.0.3.16/27	sriov-vnic-4	testpod4	`kubectl exec -it testpod4 -- /bin/bash`

kubectl exec -it testpod1 -- route -nコマンドを実行して、Kubernetes Operatorターミナルからtestpod1のルーティング・テーブルを直接確認します。

testpod1のルーティング表には、eth0およびSR-IOV対応インタフェースであるnet1のデフォルト・ゲートウェイがあります。

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.0.129    0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.0.129    255.255.0.0     UG    0      0        0 eth0
10.244.0.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

kubectl exec -it testpod2 -- route -nコマンドを実行して、Kubernetes Operatorターミナルからtestpod2のルーティング・テーブルを直接確認します。

testpod2のルーティング表には、eth0およびSR-IOV対応インタフェースであるnet1のデフォルト・ゲートウェイがあります。

[opc@o-sqrtga ~]$ kubectl exec -it testpod2 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.1.129    0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.1.129    255.255.0.0     UG    0      0        0 eth0
10.244.1.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

kubectl exec -it testpod3 -- route -nコマンドを実行して、Kubernetes Operatorターミナルからtestpod3のルーティング・テーブルを直接確認します。

testpod3のルーティング表には、eth0およびSR-IOV対応インタフェースであるnet1のデフォルト・ゲートウェイがあります。

[opc@o-sqrtga ~]$ kubectl exec -it testpod3 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.0.1      0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
10.244.0.0      10.244.0.1      255.255.0.0     UG    0      0        0 eth0

kubectl exec -it testpod4 -- route -nコマンドを実行して、Kubernetes Operatorターミナルからtestpod4のルーティング・テーブルを直接確認します。

testpod4のルーティング表には、eth0およびSR-IOV対応インタフェースであるnet1のデフォルト・ゲートウェイがあります。

[opc@o-sqrtga ~]$ kubectl exec -it testpod4 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.1.1      0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.1.1      255.255.0.0     UG    0      0        0 eth0
10.244.1.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
[opc@o-sqrtga ~]$

Kubernetes Operatorからテスト・ポッドから直接pingテストを実行するには、pingコマンドが必要です。

次の表では、すべてのテスト・ポッドに対してすべてのpingコマンドを提供しています。このコマンドは、特定のテスト・ポッドから、net1 IPアドレスを含む他のすべてのテスト・ポッドにpingを実行します。

ソース・ポッド名	コマンド
testpod1	`kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4`
testpod2	`kubectl exec -it testpod2 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.16 -c 4`
testpod3	`kubectl exec -it testpod3 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.16 -c 4`
testpod4	`kubectl exec -it testpod4 -- ping -I net1 10.0.3.16 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.14 -c 4`

ノート:この例では、testpod1を使用して、他のすべてのテスト・ポッドnet1 IPアドレスにpingを実行します。

kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4コマンドを実行して、testpod1からtestpod1にpingを実行します。

pingには4 packets transmitted, 4 received, 0% packet lossがあることに注意してください。そのため、pingは成功します。

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4
PING 10.0.3.30 (10.0.3.30) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.30: icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from 10.0.3.30: icmp_seq=2 ttl=64 time=0.024 ms
64 bytes from 10.0.3.30: icmp_seq=3 ttl=64 time=0.037 ms
64 bytes from 10.0.3.30: icmp_seq=4 ttl=64 time=0.026 ms

--- 10.0.3.30 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3087ms
rtt min/avg/max/mdev = 0.024/0.032/0.043/0.009 ms

kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4コマンドを実行して、testpod1からtestpod2にpingを実行します。

pingには4 packets transmitted, 4 received, 0% packet lossがあることに注意してください。そのため、pingは成功します。

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4
PING 10.0.3.15 (10.0.3.15) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.15: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from 10.0.3.15: icmp_seq=2 ttl=64 time=0.113 ms
64 bytes from 10.0.3.15: icmp_seq=3 ttl=64 time=0.114 ms
64 bytes from 10.0.3.15: icmp_seq=4 ttl=64 time=0.101 ms

--- 10.0.3.15 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3109ms
rtt min/avg/max/mdev = 0.101/0.177/0.383/0.119 ms

kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4コマンドを実行して、testpod1からtestpod3にpingを実行します。

pingには4 packets transmitted, 4 received, 0% packet lossがあることに注意してください。そのため、pingは成功します。

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4
PING 10.0.3.14 (10.0.3.14) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.14: icmp_seq=1 ttl=64 time=0.399 ms
64 bytes from 10.0.3.14: icmp_seq=2 ttl=64 time=0.100 ms
64 bytes from 10.0.3.14: icmp_seq=3 ttl=64 time=0.130 ms
64 bytes from 10.0.3.14: icmp_seq=4 ttl=64 time=0.124 ms

--- 10.0.3.14 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3057ms
rtt min/avg/max/mdev = 0.100/0.188/0.399/0.122 ms

kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4コマンドを実行して、testpod1からtestpod4にpingを実行します。

pingには4 packets transmitted, 4 received, 0% packet lossがあることに注意してください。そのため、pingは成功します。

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4
PING 10.0.3.16 (10.0.3.16) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.16: icmp_seq=1 ttl=64 time=0.369 ms
64 bytes from 10.0.3.16: icmp_seq=2 ttl=64 time=0.154 ms
64 bytes from 10.0.3.16: icmp_seq=3 ttl=64 time=0.155 ms
64 bytes from 10.0.3.16: icmp_seq=4 ttl=64 time=0.163 ms

--- 10.0.3.16 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3110ms
rtt min/avg/max/mdev = 0.154/0.210/0.369/0.092 ms
[opc@o-sqrtga ~]$

注意:他のすべてのテスト・ポッドのその他のすべてのping出力は含まれていませんが、わかります。

次の図は、これまでに構成した内容の概要を示しています。

タスク9: (オプション)複数のインタフェースを使用したポッドのデプロイ

これまでは、1つのVNIC(SR-IOVをサポートするため)のみを準備し、このVNICをポッドに移動しました。これは、4つの異なるテスト・ポッドに対して行いました。

では、さらにVNICを特定のポッドに追加または移動する場合はどうでしょうか。次のステップを繰り返す必要があります。

新しいOCIサブネットを作成します。
新しいVNICを作成し、IPアドレスを割り当てます。
新しいNetworkAttachmentDefinitionsを作成します。
新しい注釈を追加して、テスト・ポッドYAMLファイルを更新します。

このタスクでは、追加のサブネットVNICを作成し、IPアドレスNetworkAttachmentDefinitionを割り当て、これをtestpod1のポッド作成YAMLファイルに追加する例を示します。

これは、ネットワーク10.0.4.0/27上のIPアドレス10.0.4.29/27を持つ新しいインタフェースens6のNetworkAttachmentDefinitionです。

これは、ネットワーク10.0.3.0/27上のIPアドレス10.0.3.30/27を持つインタフェースens5で、以前よりも別のNetworkAttachmentDefinitionであることに注意してください。

sriov-vnic-2-new.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-2-new
spec:
config: '{
		"cniVersion": "0.3.1",
		"type": "host-device",
		"device": "ens6",
		"ipam": {
				"type": "static",
				"addresses": [
					{
						"address": "10.0.4.29/27",
						"gateway": "0.0.0.0"
					}
				],
				"routes": [
					{ "dst": "10.0.4.0/27", "gw": "0.0.0.0" }
				]
			}
		}'

これは、testpod1の(更新された)YAMLファイルです。

新しいNetworkAttachmentDefinition、sriov-vnic-2-newが参照されるannotations内の追加行に注意してください。

sudo nano testpod1-v3.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod1
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-1
	k8s.v1.cni.cncf.io/networks: sriov-vnic-2-new
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod1
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

タスク10: すべてのポッド・デプロイメントおよび`NetworkAttachmentDefinitions`の削除

NetworkAttachmentDefinitionsを使用してコンテナをやり直す場合、またはクリーン・アップする場合は、次のステップを実行します。

kubectl get podコマンドを使用して、すべてのポッドを取得します。

[opc@o-sqrtga ~]$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-576c6b7b6-6fn6f   1/1     Running   3          105d
my-nginx-576c6b7b6-k9wwc   1/1     Running   3          105d
my-nginx-576c6b7b6-z8xkd   1/1     Running   6          105d
mysql-6d7f5d5944-dlm78     1/1     Running   12         100d
testpod1                   1/1     Running   0          64d
testpod2                   1/1     Running   0          64d
testpod3                   1/1     Running   0          64d
testpod4                   1/1     Running   0          64d
[opc@o-sqrtga ~]$

次のコマンドを使用して、テスト・ポッドを削除します。

kubectl delete -f testpod1-v2.yaml

kubectl delete -f testpod2-v2.yaml

kubectl delete -f testpod3-v2.yaml

kubectl delete -f testpod4-v2.yaml

kubectl get network-attachment-definitions.k8s.cni.cncf.ioコマンドを使用して、すべてのNetworkAttachmentDefinitionsを取得します。

[opc@o-sqrtga ~]$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME           AGE
sriov-vnic-1   64d
sriov-vnic-2   64d
sriov-vnic-3   64d
sriov-vnic-4   64d
[opc@o-sqrtga ~]$

次のコマンドを使用して、NetworkAttachmentDefinitionsを削除します。

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4

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

確認

作成者 - Iwan Hoogendoorn (OCIネットワーク・スペシャリスト)

その他の学習リソース

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

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

タイトルおよび著作権情報

Deploy SR-IOV Enabled Network Interfaces Container Apps on OKE Using Multus CNI Plugin

G28058-02

マルチスCNIプラグインを使用したOKEへのSR-IOV対応ネットワーク・インタフェース・コンテナ・アプリケーションのデプロイ

はじめに

目的

タスク1: 要塞、オペレータ、3つのVMワーカー・ノードおよびFlannel CNIプラグインを使用したOKEのデプロイ

タスク2: 各ワーカー・ノードでのSR-IOV (ハードウェア支援)ネットワーキングの有効化

タスク3: SR-IOV対応VNICの新しいサブネットの作成

タスク3.1: セキュリティ・リストの作成

タスク3.2: サブネットの作成

タスク4: 2番目のVNICアタッチメントの追加

タスク4.1: ネットワーク・セキュリティ・グループ(NSG)の作成

タスク4.2: VNICの追加

タスク5: デフォルト・ゲートウェイを使用した新しい2番目のVNICへのIPアドレスの割当て

タスク5.1: ノード・プール1のすべてのノードの確認(np1)

タスク5.2: ノード・プール2のすべてのノードの確認(np2)

タスク6: ワーカー・ノードへのメタプラグインCNI (マルチCNI)のインストール

タスク6.1: シン・インストール方法を使用したマルチスCNIのインストール

タスク6.2: マルチ・インストールの検証

タスク7: ポッドへのネットワーク・インタフェースのアタッチ

タスク7.1: ネットワーク添付定義の作成

タスク7.2: NetworkDefinitionAttachmentがアタッチされたポッドの作成

タスク7.3: ノード・アフィニティを使用したポッドの作成

タスク7.4: テスト・ポッドのIPアドレスの確認

タスク7.5: ワーカー・ノードのIPアドレスの確認

タスク8: 複数のポッド間のPingテストの実行

タスク9: (オプション)複数のインタフェースを使用したポッドのデプロイ

タスク10: すべてのポッド・デプロイメントおよびNetworkAttachmentDefinitionsの削除

関連リンク

確認

その他の学習リソース

タスク5.1: ノード・プール1のすべてのノードの確認(`np1`)

タスク5.2: ノード・プール2のすべてのノードの確認(`np2`)

タスク7.2: `NetworkDefinitionAttachment`がアタッチされたポッドの作成

タスク10: すべてのポッド・デプロイメントおよび`NetworkAttachmentDefinitions`の削除