マルチス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を使用してインスタンスまたはワーカー・ノードにログインします。
lspci
コマンドを実行して、すべてのVNICで現在使用されているネットワークドライバを確認します。Virtio
ネットワークドライバが使用されていることに注意してください。
- OCIコンソールの「インスタンスの詳細」ページに移動します。
- 下へスクロール
- NICアタッチメント・タイプがPARAVIRTUALIZEDになりました。
- OCIコンソールの「インスタンスの詳細」ページに移動します。
- 「他のアクション」をクリックします。
- 「編集」をクリックします。
-
「詳細オプションの表示」をクリックします。
- 「起動オプション」をクリックし、「ネットワーキング・タイプ」として「ハードウェア支援(SR-IOV)ネットワーキング」を選択します。
- 「変更の保存」をクリックします。
-
「インスタンスの再起動」をクリックして、インスタンスの再起動を確認します。
-
インスタンスのステータスがSTOPPINGに変更されたことに注意してください。
-
インスタンス・ステータスがSTARTINGに変更されたことに注意してください。
-
インスタンス・ステータスが「RUNNING」に変更されたことに注意してください。
- 下へスクロール
- NICアタッチメント・タイプがVFIOになりました。
-
次の図は、これまでに構成した内容の概要を示しています。
タスク3: SR-IOV対応VNICの新しいサブネットの作成
SR-IOV対応のインタフェースが使用する専用のサブネットを作成します。
タスク3.1: セキュリティ・リストの作成
すでに他のサブネットにセキュリティ・リストを使用しているため、新しく作成されたSR-IOVサブネット専用のセキュリティ・リストも必要です。
-
OCIコンソールに移動します。
- 「Virtual Cloud Networks」に移動します。
- 既存のVCNをクリックします。
- 「Security Lists」をクリックします。
- 「セキュリティ・リストの作成」をクリックします。
-
「イングレス・ルール1」に、次の情報を入力します。
- 「名前」を入力します。
- 「ソース・タイプ」として「CIDR」を選択します。
- 「ソースCIDR」に
0.0.0.0/0
と入力します。 - 「IPプロトコル」に「すべてのプロトコル」を選択します。
- 下へスクロール
- 「エグレス・ルール1」に、次の情報を入力します。
- 「ソース・タイプ」として「CIDR」を選択します。
- 「ソースCIDR」に
0.0.0.0/0
と入力します。 - 「IPプロトコル」に「すべてのプロトコル」を選択します。
- 「セキュリティ・リストの作成」をクリックします。
-
新しいセキュリティ・リストが作成されることに注意してください。
タスク3.2: サブネットの作成
-
「Virtual Cloud Network Details」ページに移動します。
- 「サブネット」をクリックします。
- OKE環境用にすでに作成されている既存のサブネットに注意してください。
- 「サブネットの作成」をクリックします。
- 「名前」を入力します。
- 「IPv4 CIDRブロック」を入力します。
- 下へスクロール
- 「プライベート・サブネット」を選択します。
- 下へスクロール
- 「DHCPオプション」で「DHCPのデフォルト・オプション」を選択します。
- タスク3.1で作成した「セキュリティ・リスト」を選択します。
- 「サブネットの作成」をクリックします。
-
ネット・サブネットが作成されることに注意してください。
ノート:
- サブネット自体には、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」ページに移動します。
- 「ネットワーク・セキュリティ・グループ」に移動します。
- 「ネットワーク・セキュリティ・グループの作成」をクリックします。
-
次のルールを追加します。
- イングレス:
- ソース・タイプを許可: 「CIDR」を選択します。
- ソース:
0.0.0.0/0
と入力します。 - 宛先:宛先は空白のままにします。
- プロトコル:すべてのプロトコルを許可します。
- エグレス:
- ソース・タイプを許可: 「CIDR」を選択します。
- ソース:ソースは空白のままにします。
- 宛先:
0.0.0.0/0
と入力します。 - プロトコル:すべてのプロトコルを許可します。
- イングレス:
-
NSGが作成されることに注意してください。これを(OKEクラスタ内の各ワーカー・ノードで)作成する新しい(セカンダリ)VNICに適用します。
タスク4.2: VNICの追加
-
各仮想ワーカー・ノード・インスタンスに移動し、各ワーカー・ノードに2番目のVNICを追加します。
- 各仮想ワーカー・ノード・インスタンスに移動し、「アタッチされたVNIC」をクリックします。
- 既存のVNICがすでに存在することに注意してください。
- 「VNICの作成」をクリックして、2番目のVNICを追加します。
- 「名前」を入力します。
- VCNを選択します。
- タスク3.2で作成した「サブネット」を選択します。
- 「ネットワーク・セキュリティ・グループを使用してトラフィックを制御」を選択します。
- タスク4.1で作成したNSGを選択します。
- 下へスクロール
- 「プライベートIPv4アドレスの自動割当て」を選択します。
- 「変更の保存」をクリックします。
-
2番目のVNICが作成され、仮想ワーカー・ノード・インスタンスにアタッチされ、サブネットにもアタッチされることに注意してください。
-
SSHを使用してインスタンスまたはワーカー・ノードにログインします。
lspci
コマンドを実行して、すべてのVNICで現在使用されているネットワークドライバを確認します。- 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
)をクリックします。 -
このノード・プールの一部であるワーカー・ノードをクリックします。
- NICアタッチメント・タイプがVFIOであることに注意してください(これは、この仮想インスタンス・ワーカー・ノードでSR-IOVが有効になっていることを意味します)。
- 2番目のVNICが作成され、このワーカー・ノードにアタッチされていることに注意してください。
タスク5.2: ノード・プール2のすべてのノードの確認(np2
)
-
ノードを1つずつクリックし、検証を開始します。
- NICアタッチメント・タイプがVFIOであることに注意してください(これは、この仮想インスタンス・ワーカー・ノードでSR-IOVが有効になっていることを意味します)。
- 2番目のVNICが作成され、このワーカー・ノードにアタッチされていることに注意してください。
-
ノード・プール2 (
np2
)のサマリー・ページに移動します。ノード・プールの2番目のワーカー・ノードをクリックします。- NICアタッチメント・タイプがVFIOであることに注意してください(これは、この仮想インスタンス・ワーカー・ノードでSR-IOVが有効になっていることを意味します)。
- 2番目のVNICが作成され、このワーカー・ノードにアタッチされていることに注意してください。
-
ノード・プール2 (
np2
)のサマリー・ページに移動します。ノード・プールの3番目のワーカー・ノードをクリックします。- NICアタッチメント・タイプがVFIOであることに注意してください(これは、この仮想インスタンス・ワーカー・ノードでSR-IOVが有効になっていることを意味します)。
- 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
コマンドを実行します。IPアドレスが正常に構成されると、
ens5
(2番目のVNIC)には、SR-IOVインタフェース用にタスク3.2で作成したサブネットの範囲内のIPアドレスが含まれます。[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
コマンドを実行します。IPアドレスが正常に構成されると、
ens5
(2番目のVNIC)には、SR-IOVインタフェース用にタスク3.2で作成したサブネットの範囲内のIPアドレスが含まれます。[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
コマンドを実行します。IPアドレスが正常に構成されると、
ens5
(2番目のVNIC)には、SR-IOVインタフェース用にタスク3.2で作成したサブネットの範囲内のIPアドレスが含まれます。[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接続します。
-
次のコマンドを実行して、Multus Gitライブラリをクローニングします。
git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
-
次のコマンドを実行して、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
-
マルチス・デーモン・セットがワーカー・ノード自体にインストールされているかどうかを確認することもできます。
- 次のコマンドを使用して、
ssh -i id_rsa opc@10.0.112.134
コマンドを実行してワーカー・ノードにSSHを実行します。 cd /etc/cni/net.d/
コマンドを実行して、次のコマンドを使用してディレクトリを変更します。ls -l
コマンドを実行して、次のコマンドを使用してディレクトリ出力をリストします。00-multus.conf
およびmultus.d
ファイルがリストされていることに注意してください。
sudo more 00-multus.conf
コマンドを実行して、00-multus.conf
ファイルの内容を表示します。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
関連リンク
確認
- 作成者 - 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
Copyright ©2025, Oracle and/or its affiliates.