第2章 プライマリーネットワーク
2.1. ユーザー定義ネットワークについて リンクのコピーリンクがクリップボードにコピーされました!
ユーザー定義ネットワーク (UDN) が実装される前は、OpenShift Container Platform の OVN-Kubernetes CNI プラグインは、プライマリーまたは メイン ネットワーク上の Layer 3 トポロジーのみをサポートしていました。Kubernetes の設計原則により、すべての Pod はメインネットワークにアタッチされ、すべての Pod は IP アドレスを使用して相互に通信し、Pod 間のトラフィックはネットワークポリシーに基づき制限されます。
Kubernetes 設計は単純なデプロイメントには便利ですが、この Layer 3 トポロジーでは、特に最新のマルチテナントデプロイメントの場合、プライマリーネットワークセグメント設定のカスタマイズが制限されます。
UDN では、カスタムの Layer 2 および Layer 3 ネットワークセグメントを有効にすることで、Kubernetes Pod ネットワークのデフォルトの Layer 3 トポロジーの柔軟性とセグメンテーション機能が向上します。これらのセグメントはすべてデフォルトで分離されています。これらのセグメントは、デフォルトの OVN-Kubernetes CNI プラグインを使用するコンテナー Pod および仮想マシンの、プライマリーネットワークまたはセカンダリーネットワークとして機能します。UDN を使用することで、幅広いネットワークアーキテクチャーとトポロジーが可能になり、ネットワークの柔軟性、セキュリティー、パフォーマンスが向上します。
クラスター管理者は、ClusterUserDefinedNetwork
カスタムリソース (CR) を使用することで、クラスターレベルで複数の namespace にまたがるプライマリーまたはセカンダリーのネットワークを UDN を使用して作成および定義できます。クラスター管理者またはクラスターユーザーは、UDN を使用して、namespace レベルで UserDefinedNetwork
CR でセカンダリーネットワークを定義することもできます。
次のセクションでは、ユーザー定義ネットワークの利点と制限、ClusterUserDefinedNetwork
または UserDefinedNetwork
CR を作成する際のベストプラクティス、CR の作成方法、およびお客様のデプロイメントに関連する可能性のある追加設定の詳細をさらに詳しく説明します。
2.1.1. ユーザー定義ネットワークの利点 リンクのコピーリンクがクリップボードにコピーされました!
ユーザー定義ネットワークには次のような利点があります。
セキュリティーのためのネットワーク分離の強化
- テナントの分離: Red Hat OpenStack Platform (RHOSP) でテナントが分離される方法と同様に、namespace には独自の分離されたプライマリーネットワークを設定できます。これにより、テナント間のトラフィックのリスクが軽減され、セキュリティーが向上します。
ネットワークの柔軟性
- レイヤー 2 およびレイヤー 3 のサポート: クラスター管理者は、プライマリーネットワークをレイヤー 2 またはレイヤー 3 のネットワークタイプとして設定できます。
簡素化されたネットワーク管理
- ネットワーク設定の複雑さの軽減: ユーザー定義ネットワークでは、異なるネットワーク内のワークロードをグループ化することで分離を実現できるため、複雑なネットワークポリシーが不要になります。
高度な機能
- 一貫性があり選択可能な IP アドレス指定: ユーザーは、異なる namespace 間とクラスター間で IP サブネットを指定して再利用できるため、一貫性のあるネットワーク環境が実現します。
- 複数のネットワークのサポート: ユーザー定義のネットワーク機能により、管理者は複数の namespace を単一のネットワークに接続したり、異なる namespace セットごとに個別のネットワークを作成したりできます。
Red Hat OpenStack Platform (RHOSP) からのアプリケーション移行の簡素化
- ネットワークパリティー: ユーザー定義ネットワークでは、同様のネットワーク分離および設定オプションが提供されるため、OpenStack から OpenShift Container Platform へのアプリケーションの移行が簡素化されます。
開発者と管理者は、カスタムリソースを使用して、namespace スコープのユーザー定義ネットワークを作成できます。プロセスの概要は次のとおりです。
-
管理者は、
k8s.ovn.org/primary-user-defined-network
ラベルを使用して、ユーザー定義ネットワークの namespace を作成します。 -
UserDefinedNetwork
CR は、クラスター管理者またはユーザーによって作成されます。 - ユーザーは namespace 内に Pod を作成します。
2.1.2. ユーザー定義ネットワークの制限 リンクのコピーリンクがクリップボードにコピーされました!
ユーザー定義ネットワーク (UDN) は高度にカスタマイズ可能なネットワーク設定オプションを提供しますが、クラスター管理者と開発者がこれらのネットワークを実装および管理する際に認識しておくべき制限があります。UDN を実装する前に、次の制限を考慮してください。
DNS の制限:
- Pod の DNS ルックアップは、クラスターのデフォルトネットワーク上の Pod の IP アドレスに解決されます。Pod がユーザー定義ネットワークの一部である場合でも、DNS ルックアップではそのユーザー定義ネットワーク上の Pod の IP アドレスは解決されません。ただし、サービスおよび外部エンティティーの DNS ルックアップは期待どおりに機能します。
- Pod がプライマリー UDN に割り当てられると、その Pod はクラスターのデフォルトネットワーク上の Kubernetes API (KAPI) および DNS サービスにアクセスできるようになります。
- 初期ネットワーク割り当て: Pod を作成する前に、namespace とネットワークを作成する必要があります。Pod を含む namespace を新しいネットワークに割り当てたり、既存の namespace に UDN を作成したりすることは、OVN-Kubernetes では受け入れられません。
- ヘルスチェックの制限: Kubelet ヘルスチェックはクラスターのデフォルトネットワークによって実行されますが、Pod 上のプライマリーインターフェイスのネットワーク接続は確認されません。したがって、デフォルトネットワークでは Pod が正常に見えるものの、プライマリーインターフェイスで接続が切断されるというシナリオが、ユーザー定義ネットワークでは発生する可能性があります。
- ネットワークポリシーの制限: ユーザー定義の異なるプライマリネットワークに接続された namespace 間のトラフィックを有効にするネットワークポリシーは効果がありません。これらのトラフィックポリシーが有効にならないのは、これらの隔離されたネットワーク間に接続性がないためです。
-
作成および変更の制限:
ClusterUserDefinedNetwork
CR およびUserDefinedNetwork
CR は、作成後に変更することはできません。 -
デフォルトのネットワークサービスアクセス: ユーザー定義ネットワークの Pod は、デフォルトのネットワークから分離されているため、ほとんどのデフォルトのネットワークサービスにアクセスできません。たとえば、ユーザー定義ネットワークの Pod は、現在 OpenShift Container Platform イメージレジストリーにアクセスできません。この制限のため、Source-to-Image ビルドはユーザー定義ネットワークの namespace では機能しません。さらに、Git リポジトリー内のソースコードに基づいてアプリケーションを作成する機能 (
oc new-app <command>
など) や、Source-to-Image ビルドを使用する OpenShift Container Platform テンプレートからアプリケーションを作成する機能など、他の機能も動作しません。この制限は他のopenshift-*.svc
サービスにも影響する可能性があります。 - 接続制限: ユーザー定義ネットワーク上の NodePort サービスは分離が保証されません。たとえば、同じノード上の Pod からサービスへの NodePort トラフィックにはアクセスできませんが、別のノード上の Pod からのトラフィックは成功します。
-
IP アドレスの枯渇に関する不明なエラーメッセージ: ユーザー定義のネットワークのサブネットが利用可能な IP アドレスが不足すると、新規 Pod は起動に失敗します。これが発生すると、
Warning: Failed to create pod sandbox
というエラーが返されます。このエラーメッセージは、IP 枯渇が原因であることを明確に指定していません。問題を確認するには、OpenShift Container Platform Web コンソールで Pod の namespace の Events ページを確認します。ここでは、サブネット枯渇に関する明示的なメッセージが報告されます。
2.1.3. レイヤー 2 およびレイヤー 3 トポロジー リンクのコピーリンクがクリップボードにコピーされました!
フラットなレイヤー 2 トポロジーでは、クラスター内のすべてのノードに分散される仮想スイッチを作成します。仮想マシンと Pod はこの仮想スイッチに接続し、これらすべてのコンポーネントが同じサブネット内で相互通信できるようにします。フラットなレイヤー 2 トポロジーは、クラスター内に存在するノード間で仮想マシンのライブマイグレーションを実行する場合に役立ちます。次の図は、ライブマイグレーションのために仮想スイッチを使用する 2 つのノードを含むフラットなレイヤー 2 トポロジーを示しています。
図2.1 コンポーネントの通信に仮想スイッチを使用するフラットなレイヤー 2 トポロジー
レイヤー 2 サブネットを指定しない場合は、クラスター内の各 Pod の IP アドレスを手動で設定する必要があります。レイヤー 2 サブネットを指定しないと、ポートのセキュリティーがメディアアクセスコントロール (MAC) スプーフィングの防止だけに限定され、IP スプーフィングが対象外になります。レイヤー 2 トポロジーでは、単一のブロードキャストドメインが作成されます。しかし、大規模なネットワーク環境では、これにより問題が発生することがあります。ブロードキャストストームが発生して、ネットワークのパフォーマンスが低下する可能性があるためです。
ネットワークの詳細な設定オプションを利用する場合は、レイヤー 2 トポロジーをユーザー定義ネットワーク (UDN) と統合できます。次の図は、各ノードに存在する Pod を含むレイヤー 2 トポロジーで UDN を使用する 2 つのノードを示しています。各ノードには、次の 2 つのインターフェイスが含まれています。
- ノードインターフェイス。これは、ネットワークコンポーネントをノードに接続するコンピュートノードです。
-
br-ex
などの Open vSwitch (OVS) ブリッジ。これは、Pod が相互に通信してリソースを共有できるように、レイヤー 2 OVN スイッチを作成します。
これら 2 つのインターフェイスは、外部スイッチによって接続されています。ゲートウェイまたはルーターにより、外部スイッチとレイヤー 2 OVN スイッチ間のルーティングトラフィックが処理されます。ノード内の仮想マシンと Pod は UDN を使用して相互に通信できます。レイヤー 2 OVN スイッチは、UDN 経由のノードトラフィックを処理します。これにより、あるノードから別のノードへの仮想マシンのライブマイグレーションが可能になります。
図2.2 レイヤー 2 トポロジーを使用するユーザー定義ネットワーク (UDN)
レイヤー 3 トポロジーでは、クラスター内の各ノードに固有のレイヤー 2 セグメントが作成されます。レイヤー 3 ルーティングメカニズムはこれらのセグメントを相互接続し、異なるノードでホストされている仮想マシンと Pod が相互に通信できるようにします。レイヤー 3 トポロジーでは、各ドメインを特定のノードに割り当てることで大規模なブロードキャストドメインを効果的に管理できるため、ブロードキャストトラフィックの範囲は小さくなっています。レイヤー 3 トポロジーを設定するには、cidr
および hostSubnet
パラメーターを設定する必要があります。
2.1.4. ClusterUserDefinedNetwork CR について リンクのコピーリンクがクリップボードにコピーされました!
ClusterUserDefinedNetwork
(UDN) カスタムリソース (CR) は、管理者のみにクラスタースコープのネットワークセグメンテーションと分離を提供します。
次の図は、クラスター管理者が ClusterUserDefinedNetwork
CR を使用してテナント間のネットワーク分離を作成する方法を示しています。このネットワーク設定により、ネットワークを複数の namespace にまたがって構築できるようになります。この図では、udn-1
と udn-2
という 2 つのユーザー定義ネットワークを作成することでネットワークを分離しています。これらのネットワークは接続されておらず、spec.namespaceSelector.matchLabels
フィールドを使用して異なる namespace を選択しています。たとえば、udn-1
は namespace-1
と namespace-2
の通信を設定および分離し、udn-2
は namespace-3
と namespace-4
の通信を設定および分離します。namespace を分離し、同じ namespace 内の Pod が通信できるようにすることで、分離されたテナント (Tenants 1 と Tenants 2) が作成されます。
図2.3 ClusterUserDefinedNetwork CR を使用したテナント分離
2.1.4.1. ClusterUserDefinedNetwork CR のベストプラクティス リンクのコピーリンクがクリップボードにコピーされました!
ユーザーは、ClusterUserDefinedNetwork
カスタムリソース (CR) を設定する前に、次の情報を考慮する必要があります。
-
ClusterUserDefinedNetwork
CR はクラスター管理者による使用を目的としているため、管理者以外は使用しないでください。誤って使用すると、デプロイメントでセキュリティー上の問題が発生したり、中断が発生したり、クラスターネットワークが切断されたりする可能性があります。 -
ClusterUserDefinedNetwork
CR でdefault
namespace を選択しないでください。分離されず、その結果としてクラスターにセキュリティーリスクが生じる可能性があります。 -
ClusterUserDefinedNetwork
CR でopenshift-*
namespace を選択しないでください。 OpenShift Container Platform 管理者は、次のいずれかの条件が満たされると、クラスターのすべての namespace が選択されることに注意する必要があります。
-
matchLabels
セレクターが空のままである。 -
matchExpressions
セレクターが空のままである。 -
namespaceSelector
は初期化されているが、matchExpressions
またはmatchLabel
が指定されていない。例:namespaceSelector: {}
。
-
プライマリーネットワークの場合、
ClusterUserDefinedNetwork
CR に使用される namespace には、k8s.ovn.org/primary-user-defined-network
ラベルが含まれている必要があります。このラベルは更新できず、namespace 作成時にのみ追加できます。k8s.ovn.org/primary-user-defined-network
namespace ラベルには次の条件が適用されます。-
namespace に
k8s.ovn.org/primary-user-defined-network
ラベルがなく、Pod が作成された場合、Pod はデフォルトのネットワークにアタッチされます。 -
namespace に
k8s.ovn.org/primary-user-defined-network
ラベルがなく、その namespace に一致するプライマリーClusterUserDefinedNetwork
CR が作成されると、エラーが報告され、ネットワークは作成されません。 -
namespace に
k8s.ovn.org/primary-user-defined-network
ラベルがなく、プライマリーClusterUserDefinedNetwork
CR がすでに存在する場合、その namespace 内に Pod が作成され、デフォルトのネットワークにアタッチされます。 -
namespace にラベルが あり、プライマリー
ClusterUserDefinedNetwork
CR が存在しない場合、ClusterUserDefinedNetwork
CR が作成されるまで、その namespace に Pod は作成されません。
-
namespace に
ClusterUserDefinedNetwork
CR を使用してlocalnet
トポロジーを作成する場合、管理者向けのベストプラクティスは次のとおりです。-
CUDN CR を作成するときに、
spec.network.physicalNetworkName
パラメーターが Open vSwitch (OVS) ブリッジマッピングで設定したパラメーターと一致していることを確認する必要があります。これにより、意図した物理ネットワークのセグメントに確実にブリッジできます。同じブリッジマッピングを使用して複数の CUDN CR をデプロイする場合は、同じphysicalNetworkName
パラメーターが使用されていることを確認する必要があります。 -
物理ネットワークと他のネットワークインターフェイス間のサブネットの重複を避けてください。ネットワークサブネットが重複すると、ルーティングの競合が発生し、ネットワークが不安定になる可能性があります。
spec.network.localnet.excludeSubnets
パラメーターは、spec.network.localnet.subnets
パラメーター利用時の競合を避ける目的で使用されます。 -
仮想ローカルエリアネットワーク (VLAN) を設定するときは、基盤となる物理インフラストラクチャー (スイッチ、ルーターなど) とノードの両方が VLAN ID (VID) を受け入れるように適切に設定されていることを確認する必要があります。つまり、物理ネットワークインターフェイス (例:
eth1
) を、物理スイッチ経由で接続する VLAN (例:20
) のアクセスポートとして設定することになります。さらに、物理インターフェイスが OVN-Kubernetes に適切に接続されていることを確認するために、ノード上に OVS ブリッジマッピング (例:eth1
) が存在することを確認する必要があります。
-
CUDN CR を作成するときに、
2.1.4.2. CLI を使用した ClusterUserDefinedNetwork CR の作成 リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、CLI を使用して ClusterUserDefinedNetwork
カスタムリソース (CR) を作成します。ユースケースに基づき、Layer2
トポロジータイプの場合は cluster-layer-two-udn.yaml
の例、Layer3
トポロジータイプの場合は cluster-layer-three-udn.yaml
の例を使用してリクエストを作成します。
-
ClusterUserDefinedNetwork
CR はクラスター管理者による使用を目的としているため、管理者以外は使用しないでください。誤って使用すると、デプロイメントでセキュリティー上の問題が発生したり、中断が発生したり、クラスターネットワークが切断されたりする可能性があります。 -
OpenShift Virtualization は、
Layer2
およびLocalnet
トポロジーのみをサポートします。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
オプション: プライマリーネットワークを使用する
ClusterUserDefinedNetwork
CR の場合は、次のコマンドを入力して、k8s.ovn.org/primary-user-defined-network
ラベルを持つ namespace を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Layer2
またはLayer3
トポロジータイプのクラスター全体のユーザー定義ネットワークリクエストを作成します。Layer2
トポロジーのリクエストを定義するには、次の例のように、cluster-layer-two-udn.yaml
などの YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ClusterUserDefinedNetwork
CR の名前。- 2
- クラスター UDN CR が適用される namespace のセットに対するラベルクエリー。標準の Kubernetes
MatchLabel
セレクターを使用します。デフォルト
またはopenshift-*
namespace は指定しないでください。 - 3
matchLabels
セレクタータイプを使用します。このセレクタータイプでは、用語がAND
関係で評価されます。- 4 5
matchLabels
セレクタータイプが使用されているため、<label_1_key>=<label_1_value>
ラベルと<label_2_key>=<label_2_value>
ラベルの両方を含む namespace がプロビジョニングされます。- 6
- ネットワーク設定を記述します。
- 7
topology
フィールドはネットワーク設定を記述します。受け入れられる値はLayer2
とLayer3
です。Layer2
トポロジータイプを指定すると、すべてのノードで共有される 1 つの論理スイッチが作成されます。- 8
- このフィールドは、トポロジー設定を指定します。
layer2
またはlayer3
に指定できます。 - 9
Primary
またはSecondary
を指定します。4.19 でサポートされるrole
仕様はPrimary
のみです。- 10
Layer2
トポロジータイプの場合、以下はsubnet
フィールドの設定を指定します。- subnets フィールドは任意です。
-
subnets フィールドはタイプが
string
で、IPv4 と IPv6 の両方の標準 CIDR 形式を受け入れます。 -
subnets フィールドには 1 つまたは 2 つの項目を入力できます。2 つのアイテムは、異なるファミリーに属している必要があります。たとえば、subnets の値は
10.100.0.0/16
と2001:db8::/64
です。 -
Layer2
サブネットは省略できます。省略した場合、ユーザーは Pod の静的 IP アドレスを設定する必要があります。結果として、ポートセキュリティーは MAC スプーフィングのみを防止します。詳細は、「静的 IP アドレスを使用した Pod 設定」を参照してください。
Layer3
トポロジーの要求を定義するには、次の例のように、cluster-layer-three-udn.yaml
などの YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ClusterUserDefinedNetwork
CR の名前。- 2
- クラスター UDN が適用される namespace セットに対するラベルクエリー。標準の Kubernetes
MatchLabel
セレクターを使用します。デフォルト
またはopenshift-*
namespace は指定しないでください。 - 3
matchExpressions
セレクタータイプを使用します。このセレクタータイプでは、用語がOR
関係で評価されます。- 4
- 照合するラベルキーを指定します。
- 5
- Operator を指定します。有効な値には、
In
、NotIn
、Exists
、DoesNotExist
などがあります。 - 6
matchExpressions
タイプが使用されているため、<example_namespace_one>
または<example_namespace_two>
のいずれかに一致する namespace がプロビジョニングされます。- 7
- ネットワーク設定を記述します。
- 8
topology
フィールドはネットワーク設定を記述します。受け入れられる値はLayer2
とLayer3
です。Layer3
トポロジータイプを指定すると、ノードごとにレイヤー 2 セグメントが作成され、それぞれに異なるサブネットが割り当てられます。レイヤー 3 ルーティングは、ノードサブネットを相互接続するために使用されます。- 9
- このフィールドは、トポロジー設定を指定します。有効な値は
layer2
またはlayer3
です。 - 10
Primary
ロールまたはSecondary
ロールを指定します。4.19 でサポートされるrole
仕様はPrimary
のみです。- 11
Layer3
トポロジータイプの場合、subnet
フィールドの設定の詳細を次に示します。-
subnets
フィールドは必須です。 subnets
フィールドのタイプは、cidr
およびhostSubnet
です。-
cidr
はクラスターのサブネットであり、文字列値を受け入れます。 -
hostSubnet
は、クラスターサブネットが分割されるノードサブネット接頭辞を指定します。 -
IPv6 の場合、
hostSubnet
では/64
の長さのみがサポートされます。
-
-
次のコマンドを実行してリクエストを適用します。
oc create --validate=true -f <example_cluster_udn>.yaml
$ oc create --validate=true -f <example_cluster_udn>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この場合の
<example_cluster_udn>.yaml
はLayer2
またはLayer3
設定ファイルの名前です。次のコマンドを実行して、リクエストが成功したことを確認します。
oc get clusteruserdefinednetwork <cudn_name> -o yaml
$ oc get clusteruserdefinednetwork <cudn_name> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この場合の
<cudn_name>
は、クラスター全体のユーザー定義ネットワークに作成した名前です。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.4.3. Localnet トポロジー用の ClusterUserDefinedNetwork CR の作成 リンクのコピーリンクがクリップボードにコピーされました!
Localnet
トポロジーは、セカンダリーネットワークを物理アンダーレイに接続します。これにより、east-west クラスタートラフィックとクラスター外で実行されているサービスへのアクセスの両方が可能になります。このトポロジータイプでは、クラスターノード上の基盤となる Open vSwitch (OVS) システムの追加設定が必要です。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。 - Open vSwitch (OVS) ブリッジマッピングを作成して設定し、OVS ブリッジを介して論理 OVN-Kubernetes ネットワークを物理ノードネットワークに関連付けている。詳細は、「localnet スイッチドトポロジーの設定」を参照してください。
手順
Localnet
トポロジーを使用してクラスター全体のユーザー定義ネットワークを作成します。次の例のように、
localnet
トポロジーの要求を定義するには、cluster-udn-localnet.yaml
などの YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ClusterUserDefinedNetwork
(CUDN) CR の名前。- 2
- クラスター CUDN CR が適用される namespace のセットに対するラベルクエリー。標準の Kubernetes
MatchLabel
セレクターを使用します。default
、openshift-*
、またはその他のシステム namespace を指すことはできません。 - 3
matchLabels
セレクタータイプを使用します。このセレクタータイプでは、用語がAND
関係で評価されます。- 4 5
- この例では、CUDN CR は、
<label_1_key>=<label_1_value>
と<label_2_key>=<label_2_value>
の両方のラベルを含む namespace にデプロイされます。 - 6
- ネットワーク設定を記述します。
- 7
Localnet
トポロジータイプを指定すると、1 つのプロバイダーネットワークに直接ブリッジされる 1 つの論理スイッチが作成されます。- 8
- このフィールドは、
localnet
トポロジーを指定します。 - 9
- ネットワーク設定の
role
を指定します。Secondary
は、localnet
トポロジーでサポートされる唯一のrole
仕様です。 - 10
Localnet
トポロジータイプの場合、subnet
フィールドの設定の詳細を次に示します。- subnets フィールドは任意です。
-
subnets フィールドはタイプが
string
で、IPv4 と IPv6 の両方の標準 CIDR 形式を受け入れます。 -
subnets フィールドには 1 つまたは 2 つの項目を入力できます。2 つの項目の場合、異なる IP ファミリーである必要があります。たとえば、subnets の値は
10.100.0.0/16
と2001:db8::/64
です。 -
localnet
サブネットは省略できます。省略した場合、ユーザーは Pod の静的 IP アドレスを設定する必要があります。結果として、ポートセキュリティーは MAC スプーフィングのみを防止します。詳細は、「静的 IP アドレスを使用した Pod 設定」を参照してください。
次のコマンドを実行してリクエストを適用します。
oc create --validate=true -f <example_cluster_udn>.yaml
$ oc create --validate=true -f <example_cluster_udn>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<example_cluster_udn>.yaml
-
Localnet
設定ファイルの名前です。
次のコマンドを実行して、リクエストが成功したことを確認します。
oc get clusteruserdefinednetwork <cudn_name> -o yaml
$ oc get clusteruserdefinednetwork <cudn_name> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<cudn_name>
- クラスター全体のユーザー定義ネットワークに作成した名前です。
例2.1 出力例
2.1.4.4. Web コンソールを使用した ClusterUserDefinedNetwork CR の作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールで、Layer2
トポロジーを使用した ClusterUserDefinedNetwork
カスタムリソース (CR) を作成できます。
現在、OpenShift Container Platform Web コンソールを使用する場合、Layer3
トポロジーを使用した ClusterUserDefinedNetwork
CR を作成することはできません。
前提条件
-
cluster-admin
権限を持つユーザーとして OpenShift Container Platform Web コンソールにアクセスできる。 -
namespace を作成し、
k8s.ovn.org/primary-user-defined-network
ラベルを適用している。
手順
-
Administrator パースペクティブから、Networking
UserDefinedNetworks をクリックします。 - ClusterUserDefinedNetwork をクリックします。
- Name フィールドで、クラスタースコープの UDN の名前を指定します。
- Subnet フィールドに値を指定します。
- Project(s) Match Labels フィールドに適切なラベルを追加して、クラスター UDN が適用される namespace を選択します。
- Create をクリックします。クラスタースコープの UDN は、ステップ 5 で指定したラベルを含む namespace に配置された Pod のデフォルトプライマリーネットワークとして機能します。
2.1.5. UserDefinedNetwork CR について リンクのコピーリンクがクリップボードにコピーされました!
UserDefinedNetwork
(UDN) カスタムリソース (CR) は、ユーザーと管理者に高度なネットワークのセグメンテーションと分離を提供します。
次の図は、4 つのクラスター namespace を示しています。各 namespace には 1 つのユーザー定義ネットワーク (UDN) が割り当てられており、各 UDN には Pod IP 割り当て用のカスタムサブネットが割り当てられています。OVN-Kubernetes は重複する UDN サブネットを処理します。Kubernetes ネットワークポリシーを使用しなくても、UDN にアタッチされた Pod はその UDN 内の他の Pod と通信できます。デフォルトでは、これらの Pod は他の UDN に配置された Pod との通信から分離されます。マイクロセグメンテーションの場合、UDN 内でネットワークポリシーを適用できます。namespace には 1 つ以上の UDN を割り当てることができますが、1 つの namespace には 1 つのプライマリー UDN を、1 つの UDN には 1 つ以上の namespace を割り当てるという制限があります。
図2.4 UserDefinedNetwork CR を使用した namespace 分離
2.1.5.1. UserDefinedNetwork CR のベストプラクティス リンクのコピーリンクがクリップボードにコピーされました!
UserDefinedNetwork
カスタムリソース (CR) を設定する前に、次の情報を考慮する必要があります。
-
UserDefinedNetwork
CR の設定にopenshift-*
namespace は使用しないでください。 -
デフォルトの namespace に
UserDefinedNetwork
CR は作成しないでください。分離されず、その結果としてクラスターにセキュリティーリスクが生じる可能性があります。 プライマリーネットワークの場合、
UserDefinedNetwork
CR に使用される namespace にはk8s.ovn.org/primary-user-defined-network
ラベルが含まれている必要があります。このラベルは更新できず、namespace 作成時にのみ追加できます。k8s.ovn.org/primary-user-defined-network
namespace ラベルには次の条件が適用されます。-
namespace に
k8s.ovn.org/primary-user-defined-network
ラベルがなく、Pod が作成された場合、Pod はデフォルトのネットワークにアタッチされます。 -
namespace に
k8s.ovn.org/primary-user-defined-network
ラベルがなく、その namespace に一致するプライマリーUserDefinedNetwork
CR が作成されると、ステータスエラーが報告され、ネットワークは作成されません。 -
namespace に
k8s.ovn.org/primary-user-defined-network
ラベルがなく、プライマリーUserDefinedNetwork
CR がすでに存在する場合、その namespace 内に Pod が作成され、デフォルトのネットワークにアタッチされます。 -
namespace にラベルが あり、プライマリー
UserDefinedNetwork
CR が存在しない場合、UserDefinedNetwork
CR が作成されるまで、その namespace に Pod は作成されません。
-
namespace に
ユーザー定義ネットワークには 2 つのマスカレード IP アドレスが必要です。必要な数のネットワークを保持できる大きさになるように、マスカレードサブネットを再設定する必要があります。
重要-
OpenShift Container Platform 4.17 以降では、クラスターはデフォルトのマスカレードサブネットとして、IPv4 の場合は
169.254.0.0/17
、IPv6 の場合はfd69::/112
を使用します。ユーザーはこれらの範囲を避ける必要があります。更新されたクラスターの場合は、デフォルトのマスカレードサブネットに変更がありません。 -
プロジェクト用のユーザー定義ネットワークが設定された後は、クラスターのマスカレードサブネットの変更はサポートされません。
UserDefinedNetwork
CR を設定した後にマスカレードサブネットを変更しようとすると、ネットワーク接続が中断され、設定の問題が発生する可能性があります。
-
OpenShift Container Platform 4.17 以降では、クラスターはデフォルトのマスカレードサブネットとして、IPv4 の場合は
-
テナントが
NetworkAttachmentDefinition
(NAD) CR ではなくUserDefinedNetwork
リソースを使用していることを確認します。これにより、テナント間でセキュリティー上のリスクが生じる可能性があります。 -
ネットワークセグメンテーションを作成するときは、
UserDefinedNetwork
CR を使用してユーザー定義のネットワークセグメンテーションを完了できない場合にのみ、NetworkAttachmentDefinition
CR を使用する必要があります。 -
UserDefinedNetwork
CR のクラスターサブネットとサービス CIDR は、デフォルトのクラスターサブネット CIDR と重複できません。OVN-Kubernetes ネットワークプラグインは、ネットワークのデフォルトの結合サブネットとして100.64.0.0/16
を使用します。この値は、UserDefinedNetwork
CR のjoinSubnets
フィールドの設定値として使用しないでください。クラスターのネットワーク内のどこかでデフォルトのアドレス値が使用されている場合は、joinSubnets
フィールドを設定してデフォルト値をオーバーライドする必要があります。詳細は、「ユーザー定義ネットワークの追加設定の詳細」を参照してください。
2.1.5.2. CLI を使用した UserDefinedNetwork CR の作成 リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、namespace スコープの UserDefinedNetwork
CR を作成します。ユースケースに基づき、Layer2
トポロジータイプの場合は my-layer-two-udn.yaml
の例、Layer3
トポロジータイプの場合は my-layer-three-udn.yaml
の例を使用してリクエストを作成します。
前提条件
-
cluster-admin
権限でログインしているか、ロールベースのアクセス制御 (RBAC) のview
およびedit
権限がある。
手順
オプション: プライマリーネットワークを使用する
UserDefinedNetwork
CR の場合は、次のコマンドを入力して、k8s.ovn.org/primary-user-defined-network
ラベルを持つ namespace を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Layer2
またはLayer3
トポロジータイプのユーザー定義のネットワークのリクエストを作成します。Layer2
トポロジーのリクエストを定義するには、次の例のように、my-layer-two-udn.yaml
などの YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
UserDefinedNetwork
リソースの名前。これはdefault
にすべきではありません。また、Cluster Network Operator (CNO) によって作成されたグローバル namespace と重複してはなりません。- 2
topology
フィールドはネットワーク設定を記述します。受け入れられる値はLayer2
とLayer3
です。Layer2
トポロジータイプを指定すると、すべてのノードで共有される 1 つの論理スイッチが作成されます。- 3
- このフィールドは、トポロジー設定を指定します。
layer2
またはlayer3
に指定できます。 - 4
Primary
ロールまたはSecondary
ロールを指定します。- 5
Layer2
トポロジータイプの場合、以下はsubnet
フィールドの設定を指定します。- subnets フィールドは任意です。
-
subnets フィールドはタイプが
string
で、IPv4 と IPv6 の両方の標準 CIDR 形式を受け入れます。 -
subnets フィールドには 1 つまたは 2 つの項目を入力できます。2 つのアイテムは、異なるファミリーに属している必要があります。たとえば、subnets の値は
10.100.0.0/16
と2001:db8::/64
です。 -
Layer2
サブネットは省略できます。省略すると、ユーザーは Pod の IP アドレスを設定する必要があります。結果として、ポートセキュリティーは MAC スプーフィングのみを防止します。 -
ipamLifecycle
フィールドが指定されている場合、Layer2
subnets
フィールドは必須です。
Layer3
トポロジーのリクエストを定義するには、次の例のように、my-layer-three-udn.yaml
などの YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
UserDefinedNetwork
リソースの名前。これはdefault
にすべきではありません。また、Cluster Network Operator (CNO) によって作成されたグローバル namespace と重複してはなりません。- 2
topology
フィールドはネットワーク設定を記述します。受け入れられる値はLayer2
とLayer3
です。Layer3
トポロジータイプを指定すると、ノードごとにレイヤー 2 セグメントが作成され、それぞれに異なるサブネットが割り当てられます。レイヤー 3 ルーティングは、ノードサブネットを相互接続するために使用されます。- 3
- このフィールドは、トポロジー設定を指定します。有効な値は
layer2
またはlayer3
です。 - 4
Primary
ロールまたはSecondary
ロールを指定します。- 5
Layer3
トポロジータイプの場合、subnet
フィールドの設定の詳細を次に示します。-
subnets
フィールドは必須です。 subnets
フィールドのタイプは、cidr
およびhostSubnet
です。-
cidr
は、クラスターのclusterNetwork
設定に相当します。CIDR 内の IP アドレスは、ユーザー定義ネットワーク内の Pod に配布されます。このパラメーターは文字列値を受け入れます。 -
hostSubnet
は、ノードごとのサブネット接頭辞を定義します。 -
IPv6 の場合、
hostSubnet
では/64
の長さのみがサポートされます。
-
-
次のコマンドを実行してリクエストを適用します。
oc apply -f <my_layer_two_udn>.yaml
$ oc apply -f <my_layer_two_udn>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この場合の
<my_layer_two_udn.yaml>
は、Layer2
またはLayer3
設定ファイルの名前です。次のコマンドを実行して、リクエストが成功したことを確認します。
oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml
$ oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、
some_custom_namespace
は、ユーザー定義ネットワーク用に作成した namespace です。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.5.3. Web コンソールを使用した UserDefinedNetwork CR の作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、Layer2
トポロジーと Primary
ロールを使用した UserDefinedNetwork
カスタムリソース (CR) を作成できます。
現在、OpenShift Container Platform Web コンソールを使用する場合、Layer3
トポロジーまたは Secondary
ロールを使用した UserDefinedNetwork
CR を作成することはできません。
前提条件
-
cluster-admin
権限を持つユーザーとして OpenShift Container Platform Web コンソールにアクセスできる。 -
namespace を作成し、
k8s.ovn.org/primary-user-defined-network
ラベルを適用している。
手順
-
Administrator パースペクティブから、Networking
UserDefinedNetworks をクリックします。 - Create UserDefinedNetwork をクリックします。
- Project name リストから、以前に作成した namespace を選択します。
- Subnet フィールドに値を指定します。
- Create をクリックします。ユーザー定義ネットワークは、この namespace で作成する Pod のデフォルトのプライマリーネットワークとして機能します。
2.1.6. ユーザー定義ネットワークの追加設定の詳細 リンクのコピーリンクがクリップボードにコピーされました!
次の表では、オプションの ClusterUserDefinedNetwork
および UserDefinedNetwork
カスタムリソース (CR) の追加設定を説明します。OVN-Kubernetes ネットワークトポロジーに対する明示的な要件がなく、理解していない場合は、これらのフィールドを設定することは推奨しません。
- ユーザー定義ネットワークのオプション設定
CUDN のフィールド | UDN のフィールド | 型 | 説明 |
|
| object |
省略すると、プラットフォームは
|
|
| string |
|
|
| object |
Persistent の値は、 |
|
| object |
Enabled:
Disabled: |
|
| integer |
最大転送単位 (MTU)。デフォルト値は |
| 該当なし | object | このフィールドはオプションであり、仮想ローカルエリアネットワーク (VLAN) のタグ付けを設定し、物理ネットワークを複数の独立したブロードキャストドメインに分割できるようにします。 |
| 該当なし | object |
設定可能な値は |
| 該当なし | string |
物理ネットワークインターフェイスの名前を指定します。指定する値は、Open vSwitch (OVS) ブリッジマッピングで指定した |
ここでは、以下のようになります。
<topology>
-
UserDefinedNetwork
CR の場合、layer2
またはlayer3
のいずれかになります。ClusterUserDefinedNetwork
CR の場合、トポロジーはLocalnet
になることもできます。
2.1.7. ユーザー定義ネットワークのステータス条件タイプ リンクのコピーリンクがクリップボードにコピーされました!
次の表は、リソースを記述するときに ClusterUserDefinedNetwork
および UserDefinedNetwork
CR に返されるステータス条件タイプを説明しています。これらの条件は、デプロイメントのトラブルシューティングに使用できます。
条件タイプ | ステータス | 理由とメッセージ | |
---|---|---|---|
|
|
| |
理由 | メッセージ | ||
| 'NetworkAttachmentDefinition has been created in following namespaces: [example-namespace-1, example-namespace-2, example-namespace-3]'` | ||
|
|
| |
理由 | メッセージ | ||
|
| ||
|
| ||
|
| ||
|
| ||
|
| ||
|
| ||
|
|
条件タイプ | ステータス | 理由とメッセージ | |
---|---|---|---|
|
|
| |
理由 | メッセージ | ||
|
| ||
|
|
| |
理由 | メッセージ | ||
|
|
条件タイプ | 理由、メッセージ、解決策 | ||
---|---|---|---|
|
| ||
理由 | メッセージ | 解決方法 | |
|
本文の |
| |
|
本文の |
| |
IPv6 サブネットを使用する場合、 |
IPv6 サブネットを使用する場合、 |
ユーザー定義のネットワーク設定で IPv6 サブネットが定義されている場合は、 |
条件タイプ | 理由、メッセージ、解決策 | ||
---|---|---|---|
|
| ||
理由 | メッセージ | 解決方法 | |
物理ネットワークの名前が設定されていません。 |
|
| |
物理ネットワークの名前が長さの最小要件を満たしていません。 |
| 物理ネットワーク名は 1 文字以上の長さに設定する必要があります。 | |
物理ネットワークの名前が最大文字数 253 文字を超えています。 |
| 物理ネットワーク名の長さは 253 文字を超えないように設定する必要があります。 | |
物理ネットワークの名前には、、 |
|
物理ネットワーク名から |
条件タイプ | 理由、メッセージ、解決策 | ||
---|---|---|---|
|
| ||
理由 | メッセージ | 解決方法 | |
localnet トポロジーに対して |
|
| |
|
|
Localnet トポロジーの |
条件タイプ | 理由、メッセージ、解決策 | ||
---|---|---|---|
|
| ||
理由 | メッセージ | 解決方法 | |
オプションフィールド ( |
|
| |
このオプションフィールドを使用する場合、 |
|
| |
オプションの |
|
| |
|
|
| |
CIDR 範囲が無効です。 |
|
| |
|
|
| |
|
| CIDR 範囲の 1 つを別の IP ファミリーに変更する必要があります。 | |
|
|
オプションフィールド |
条件タイプ | 理由、メッセージ、解決策 | ||
---|---|---|---|
|
| ||
理由 | メッセージ | 解決方法 | |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
|
2.1.8. ユーザー定義のネットワーク Pod でデフォルトのネットワークポートを開く リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、ユーザー定義ネットワーク (UDN) 上の Pod はデフォルトネットワークから分離されています。つまり、モニタリングサービス (Prometheus または Alertmanager) や OpenShift Container Platform イメージレジストリーを実行しているデフォルトのネットワーク Pod は、UDN Pod への接続を開始できません。
デフォルトのネットワーク Pod がユーザー定義のネットワーク Pod に接続できるようにするには、k8s.ovn.org/open-default-ports
アノテーションを使用できます。このアノテーションは、デフォルトネットワークからのアクセス用に、ユーザー定義ネットワーク Pod 上の特定のポートを開きます。
次の Pod 仕様では、デフォルトネットワークからのポート 80
での着信 TCP 接続とポート 53
での UDP トラフィックが許可されます。
開いているポートは、UDN ネットワーク IP ではなく、Pod のデフォルトネットワーク IP でアクセスできます。