16.2. プライマリーネットワーク
16.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 を使用することで、幅広いネットワークアーキテクチャーとトポロジーが可能になり、ネットワークの柔軟性、セキュリティー、パフォーマンスが向上します。
cgroupv1
Linux Control Groups (cgroup) を使用するノードは、ユーザー定義ネットワークを作成する前に、cgroupv1
から cgroupv2
に再設定する必要があります。詳細は、Linux cgroup の設定 を参照してください。
クラスター管理者は、ClusterUserDefinedNetwork
カスタムリソース (CR) を使用することで、クラスターレベルで複数の namespace にまたがるプライマリーまたはセカンダリーのネットワークを UDN を使用して作成および定義できます。クラスター管理者またはクラスターユーザーは、UDN を使用して、namespace レベルで UserDefinedNetwork
CR でセカンダリーネットワークを定義することもできます。
次のセクションでは、ユーザー定義ネットワークの利点と制限、ClusterUserDefinedNetwork
または UserDefinedNetwork
CR を作成する際のベストプラクティス、CR の作成方法、およびお客様のデプロイメントに関連する可能性のある追加設定の詳細についてさらに詳しく説明します。
16.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 を作成します。
16.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 からのトラフィックは成功します。
16.2.1.3. レイヤー 2 およびレイヤー 3 トポロジー
フラットなレイヤー 2 トポロジーでは、クラスター内のすべてのノードに分散される仮想スイッチを作成します。仮想マシンと Pod はこの仮想スイッチに接続し、これらすべてのコンポーネントが同じサブネット内で相互通信できるようにします。フラットなレイヤー 2 トポロジーは、クラスター内に存在するノード間で仮想マシンのライブマイグレーションを実行する場合に役立ちます。次の図は、ライブマイグレーションのために仮想スイッチを使用する 2 つのノードを含むフラットなレイヤー 2 トポロジーを示しています。
図16.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 経由のノードトラフィックを処理します。これにより、あるノードから別のノードへの仮想マシンのライブマイグレーションが可能になります。
図16.2 レイヤー 2 トポロジーを使用するユーザー定義ネットワーク (UDN)

レイヤー 3 トポロジーでは、クラスター内の各ノードに固有のレイヤー 2 セグメントが作成されます。レイヤー 3 ルーティングメカニズムはこれらのセグメントを相互接続し、異なるノードでホストされている仮想マシンと Pod が相互に通信できるようにします。レイヤー 3 トポロジーでは、各ドメインを特定のノードに割り当てることで大規模なブロードキャストドメインを効果的に管理できるため、ブロードキャストトラフィックの範囲は小さくなっています。レイヤー 3 トポロジーを設定するには、cidr
および hostSubnet
パラメーターを設定する必要があります。
16.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) が作成されます。
図16.3 ClusterUserDefinedNetwork CR を使用したテナント分離

16.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 に
16.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
トポロジーのみをサポートします。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
オプション: プライマリーネットワークを使用する
ClusterUserDefinedNetwork
CR の場合は、次のコマンドを入力して、k8s.ovn.org/primary-user-defined-network
ラベルを持つ namespace を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat << EOF | oc apply -f - apiVersion: v1 kind: Namespace metadata: name: <cudn_namespace_name> labels: k8s.ovn.org/primary-user-defined-network: "" EOF
$ cat << EOF | oc apply -f - apiVersion: v1 kind: Namespace metadata: name: <cudn_namespace_name> labels: k8s.ovn.org/primary-user-defined-network: "" EOF
Layer2
またはLayer3
トポロジータイプのクラスター全体のユーザー定義ネットワークリクエストを作成します。Layer2
トポロジーのリクエストを定義するには、次の例のように、cluster-layer-two-udn.yaml
などの YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: k8s.ovn.org/v1 kind: ClusterUserDefinedNetwork metadata: name: <cudn_name> spec: namespaceSelector: matchLabels: "<label_1_key>": "<label_1_value>" "<label_2_key>": "<label_2_value>" network: topology: Layer2 layer2: role: Primary subnets: - "2001:db8::/64" - "10.100.0.0/16"
apiVersion: k8s.ovn.org/v1 kind: ClusterUserDefinedNetwork metadata: name: <cudn_name>
1 spec: namespaceSelector:
2 matchLabels:
3 "<label_1_key>": "<label_1_value>"
4 "<label_2_key>": "<label_2_value>"
5 network:
6 topology: Layer2
7 layer2:
8 role: Primary
9 subnets: - "2001:db8::/64" - "10.100.0.0/16"
10 - 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.18 でサポートされる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 apiVersion: k8s.ovn.org/v1 kind: ClusterUserDefinedNetwork metadata: name: <cudn_name> spec: namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: In values: ["<example_namespace_one>", "<example_namespace_two>"] network: topology: Layer3 layer3: role: Primary subnets: - cidr: 10.100.0.0/16 hostSubnet: 24
apiVersion: k8s.ovn.org/v1 kind: ClusterUserDefinedNetwork metadata: name: <cudn_name>
1 spec: namespaceSelector:
2 matchExpressions:
3 - key: kubernetes.io/metadata.name
4 operator: In
5 values: ["<example_namespace_one>", "<example_namespace_two>"]
6 network:
7 topology: Layer3
8 layer3:
9 role: Primary
10 subnets:
11 - cidr: 10.100.0.0/16 hostSubnet: 24
- 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.18 でサポートされるrole
仕様はPrimary
のみです。- 11
Layer3
トポロジータイプの場合、subnet
フィールドの設定の詳細を次に示します。-
subnets
フィールドは必須です。 subnets
フィールドのタイプは、cidr
およびhostSubnet
です。-
cidr
はクラスターのサブネットであり、文字列値を受け入れます。 -
hostSubnet
は、クラスターサブネットが分割されるノードサブネット接頭辞を指定します。 -
IPv6 の場合、
hostSubnet
では/64
の長さのみがサポートされます。
-
-
次のコマンドを実行してリクエストを適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc create --validate=true -f <example_cluster_udn>.yaml
$ oc create --validate=true -f <example_cluster_udn>.yaml
この場合の
<example_cluster_udn>.yaml
はLayer2
またはLayer3
設定ファイルの名前です。次のコマンドを実行して、リクエストが成功したことを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get clusteruserdefinednetwork <cudn_name> -o yaml
$ oc get clusteruserdefinednetwork <cudn_name> -o yaml
この場合の
<cudn_name>
は、クラスター全体のユーザー定義ネットワークに作成した名前です。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: k8s.ovn.org/v1 kind: ClusterUserDefinedNetwork metadata: creationTimestamp: "2024-12-05T15:53:00Z" finalizers: - k8s.ovn.org/user-defined-network-protection generation: 1 name: my-cudn resourceVersion: "47985" uid: 16ee0fcf-74d1-4826-a6b7-25c737c1a634 spec: namespaceSelector: matchExpressions: - key: custom.network.selector operator: In values: - example-namespace-1 - example-namespace-2 - example-namespace-3 network: layer3: role: Primary subnets: - cidr: 10.100.0.0/16 topology: Layer3 status: conditions: - lastTransitionTime: "2024-11-19T16:46:34Z" message: 'NetworkAttachmentDefinition has been created in following namespaces: [example-namespace-1, example-namespace-2, example-namespace-3]' reason: NetworkAttachmentDefinitionReady status: "True" type: NetworkCreated
apiVersion: k8s.ovn.org/v1 kind: ClusterUserDefinedNetwork metadata: creationTimestamp: "2024-12-05T15:53:00Z" finalizers: - k8s.ovn.org/user-defined-network-protection generation: 1 name: my-cudn resourceVersion: "47985" uid: 16ee0fcf-74d1-4826-a6b7-25c737c1a634 spec: namespaceSelector: matchExpressions: - key: custom.network.selector operator: In values: - example-namespace-1 - example-namespace-2 - example-namespace-3 network: layer3: role: Primary subnets: - cidr: 10.100.0.0/16 topology: Layer3 status: conditions: - lastTransitionTime: "2024-11-19T16:46:34Z" message: 'NetworkAttachmentDefinition has been created in following namespaces: [example-namespace-1, example-namespace-2, example-namespace-3]' reason: NetworkAttachmentDefinitionReady status: "True" type: NetworkCreated
16.2.1.4.3. 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 のデフォルトプライマリーネットワークとして機能します。
16.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 を割り当てるという制限があります。
図16.4 UserDefinedNetwork CR を使用した namespace 分離

16.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
フィールドを設定してデフォルト値をオーバーライドする必要があります。詳細は、「ユーザー定義ネットワークの追加設定の詳細」を参照してください。
16.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 cat << EOF | oc apply -f - apiVersion: v1 kind: Namespace metadata: name: <udn_namespace_name> labels: k8s.ovn.org/primary-user-defined-network: "" EOF
$ cat << EOF | oc apply -f - apiVersion: v1 kind: Namespace metadata: name: <udn_namespace_name> labels: k8s.ovn.org/primary-user-defined-network: "" EOF
Layer2
またはLayer3
トポロジータイプのユーザー定義のネットワークのリクエストを作成します。Layer2
トポロジーのリクエストを定義するには、次の例のように、my-layer-two-udn.yaml
などの YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: k8s.ovn.org/v1 kind: UserDefinedNetwork metadata: name: udn-1 namespace: <some_custom_namespace> spec: topology: Layer2 layer2: role: Primary subnets: - "10.0.0.0/24" - "2001:db8::/60"
apiVersion: k8s.ovn.org/v1 kind: UserDefinedNetwork metadata: name: udn-1
1 namespace: <some_custom_namespace> spec: topology: Layer2
2 layer2:
3 role: Primary
4 subnets: - "10.0.0.0/24" - "2001:db8::/60"
5 - 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 apiVersion: k8s.ovn.org/v1 kind: UserDefinedNetwork metadata: name: udn-2-primary namespace: <some_custom_namespace> spec: topology: Layer3 layer3: role: Primary subnets: - cidr: 10.150.0.0/16 hostSubnet: 24 - cidr: 2001:db8::/60 hostSubnet: 64 # ...
apiVersion: k8s.ovn.org/v1 kind: UserDefinedNetwork metadata: name: udn-2-primary
1 namespace: <some_custom_namespace> spec: topology: Layer3
2 layer3:
3 role: Primary
4 subnets:
5 - cidr: 10.150.0.0/16 hostSubnet: 24 - cidr: 2001:db8::/60 hostSubnet: 64 # ...
- 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
の長さのみがサポートされます。
-
-
次のコマンドを実行してリクエストを適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f <my_layer_two_udn>.yaml
$ oc apply -f <my_layer_two_udn>.yaml
この場合の
<my_layer_two_udn.yaml>
は、Layer2
またはLayer3
設定ファイルの名前です。次のコマンドを実行して、リクエストが成功したことを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml
$ oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml
ここでは、
some_custom_namespace
は、ユーザー定義ネットワーク用に作成した namespace です。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: k8s.ovn.org/v1 kind: UserDefinedNetwork metadata: creationTimestamp: "2024-08-28T17:18:47Z" finalizers: - k8s.ovn.org/user-defined-network-protection generation: 1 name: udn-1 namespace: some-custom-namespace resourceVersion: "53313" uid: f483626d-6846-48a1-b88e-6bbeb8bcde8c spec: layer2: role: Primary subnets: - 10.0.0.0/24 - 2001:db8::/60 topology: Layer2 status: conditions: - lastTransitionTime: "2024-08-28T17:18:47Z" message: NetworkAttachmentDefinition has been created reason: NetworkAttachmentDefinitionReady status: "True" type: NetworkCreated
apiVersion: k8s.ovn.org/v1 kind: UserDefinedNetwork metadata: creationTimestamp: "2024-08-28T17:18:47Z" finalizers: - k8s.ovn.org/user-defined-network-protection generation: 1 name: udn-1 namespace: some-custom-namespace resourceVersion: "53313" uid: f483626d-6846-48a1-b88e-6bbeb8bcde8c spec: layer2: role: Primary subnets: - 10.0.0.0/24 - 2001:db8::/60 topology: Layer2 status: conditions: - lastTransitionTime: "2024-08-28T17:18:47Z" message: NetworkAttachmentDefinition has been created reason: NetworkAttachmentDefinitionReady status: "True" type: NetworkCreated
関連情報
16.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 のデフォルトのプライマリーネットワークとして機能します。
16.2.1.6. ユーザー定義ネットワークの追加設定の詳細
次の表では、オプションの ClusterUserDefinedNetwork
および UserDefinedNetwork
カスタムリソース (CR) の追加設定について説明します。OVN-Kubernetes ネットワークトポロジーに対する明示的な要件がなく、理解していない場合は、これらのフィールドを設定することは推奨しません。
- ユーザー定義ネットワークのオプション設定
CUDN のフィールド | UDN のフィールド | 型 | 説明 |
|
| object |
省略すると、プラットフォームは
|
|
| object |
Persistent の値は、 |
|
| object |
Enabled:
Disabled: |
|
| integer |
最大転送単位 (MTU)。デフォルト値は |
ここでは、以下のようになります。
<topology>
-
layer2
またはlayer3
のいずれかです。
16.2.1.7. ユーザー定義ネットワークのステータス条件タイプ
次の表は、リソースを記述するときに ClusterUserDefinedNetwork
および UserDefinedNetwork
CR に返されるステータス条件タイプについて説明しています。これらの条件は、デプロイメントのトラブルシューティングに使用できます。
条件タイプ | ステータス | 理由とメッセージ | |
---|---|---|---|
|
|
| |
理由 | メッセージ | ||
| 'NetworkAttachmentDefinition has been created in following namespaces: [example-namespace-1, example-namespace-2, example-namespace-3]'` | ||
|
|
| |
理由 | メッセージ | ||
|
| ||
|
| ||
|
| ||
|
| ||
|
| ||
|
| ||
|
|
条件タイプ | ステータス | 理由とメッセージ | |
---|---|---|---|
|
|
| |
理由 | メッセージ | ||
|
| ||
|
|
| |
理由 | メッセージ | ||
|
|
16.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 トラフィックが許可されます。
apiVersion: v1 kind: Pod metadata: annotations: k8s.ovn.org/open-default-ports: | - protocol: tcp port: 80 - protocol: udp port: 53 # ...
apiVersion: v1
kind: Pod
metadata:
annotations:
k8s.ovn.org/open-default-ports: |
- protocol: tcp
port: 80
- protocol: udp
port: 53
# ...
開いているポートは、UDN ネットワーク IP ではなく、Pod のデフォルトネットワーク IP でアクセスできます。
16.2.2. NetworkAttachmentDefinition を使用したプライマリーネットワークの作成
次のセクションでは、NetworkAttachmentDefinition
(NAD) リソースを使用してプライマリーネットワークを作成および管理する方法について説明します。
16.2.2.1. プライマリーネットワークの管理方法
NAD によって作成されたプライマリーネットワークのライフサイクルは、次のどちらかの方法で管理できます。
-
Cluster Network Operator (CNO) 設定を変更します。この方法を使用すると、CNO によって
NetworkAttachmentDefinition
オブジェクトが自動的に作成および管理されます。CNO は、オブジェクトのライフサイクルを管理するだけでなく、DHCP によって割り当てられる IP アドレスを使用するプライマリーネットワークで DHCP が利用可能であることを確認します。 -
YAML マニフェストを適用します。この方法を使用すると、
NetworkAttachmentDefinition
オブジェクトを作成してプライマリーネットワークを直接管理できます。この方法では、Pod にプライマリーネットワークインターフェイスを割り当てるために複数の CNI プラグインを呼び出すことができます。
各アプローチは同時に使用できず、プライマリーネットワークを管理する場合に 1 つのアプローチしか使用できません。どちらのアプローチでも、プライマリーネットワークは、お客様が設定した Container Network Interface (CNI) プラグインによって管理されます。
OVN SDN を使用して、Red Hat OpenStack Platform (RHOSP) に複数のネットワークインターフェイスを持つ OpenShift Container Platform ノードをデプロイすると、セカンダリーインターフェイスの DNS 設定がプライマリーインターフェイスの DNS 設定よりも優先される場合があります。その場合は、次のコマンドを実行して、セカンダリーインターフェイスに割り当てられているサブネット ID の DNS ネームサーバーを削除します。
openstack subnet set --dns-nameserver 0.0.0.0 <subnet_id>
$ openstack subnet set --dns-nameserver 0.0.0.0 <subnet_id>
16.2.2.2. Cluster Network Operator によるプライマリーネットワーク割り当ての作成
Cluster Network Operator (CNO) は追加ネットワークの定義を管理します。作成するプライマリーネットワークを指定すると、CNO によって NetworkAttachmentDefinition
CRD が自動的に作成されます。
Cluster Network Operator によって管理される NetworkAttachmentDefinition
CRD は編集しないでください。これを実行すると、プライマリーネットワークのネットワークトラフィックが中断する可能性があります。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
オプション: プライマリーネットワークの namespace を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc create namespace <namespace_name>
$ oc create namespace <namespace_name>
CNO 設定を編集するには、以下のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io cluster
以下のサンプル CR のように、作成されるプライマリーネットワークの設定を追加して、作成している CR を変更します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: # ... additionalNetworks: - name: tertiary-net namespace: namespace2 type: Raw rawCNIConfig: |- { "cniVersion": "0.3.1", "name": "tertiary-net", "type": "ipvlan", "master": "eth1", "mode": "l2", "ipam": { "type": "static", "addresses": [ { "address": "192.168.1.23/24" } ] } }
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: # ... additionalNetworks: - name: tertiary-net namespace: namespace2 type: Raw rawCNIConfig: |- { "cniVersion": "0.3.1", "name": "tertiary-net", "type": "ipvlan", "master": "eth1", "mode": "l2", "ipam": { "type": "static", "addresses": [ { "address": "192.168.1.23/24" } ] } }
- 変更を保存し、テキストエディターを終了して、変更をコミットします。
検証
次のコマンドを実行して、CNO が
NetworkAttachmentDefinition
CRD を作成したことを確認します。CNO が CRD を作成するまでに遅延が発生する可能性があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>
ここでは、以下のようになります。
<namespace>
- CNO の設定に追加したネットワーク割り当ての namespace を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NAME AGE test-network-1 14m
NAME AGE test-network-1 14m
16.2.2.2.1. プライマリーネットワークアタッチメントの設定
プライマリーネットワークは、k8s.cni.cncf.io
API グループの NetworkAttachmentDefinition
API を使用して設定されます。
API の設定は、以下の表で説明されています。
フィールド | 型 | 説明 |
---|---|---|
|
| プライマリーネットワークの名前。 |
|
| オブジェクトが関連付けられる namespace。 |
|
| JSON 形式の CNI プラグイン設定。 |
16.2.2.3. YAML マニフェストを適用したプライマリーネットワークアタッチメントの作成
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - NAD のデプロイ先となる namespace で作業している。
手順
以下の例のように、プライマリーネットワーク設定を含む YAML ファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: next-net spec: config: |- { "cniVersion": "0.3.1", "name": "work-network", "namespace": "namespace2", "type": "host-device", "device": "eth1", "ipam": { "type": "dhcp" } }
apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: next-net spec: config: |- { "cniVersion": "0.3.1", "name": "work-network", "namespace": "namespace2",
1 "type": "host-device", "device": "eth1", "ipam": { "type": "dhcp" } }
- 1
- オプション: NAD が適用される namespace を指定できます。NAD のデプロイ先となる namespace で作業している場合、この仕様は必要ありません。
プライマリーネットワークを作成するには、次のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f <file>.yaml
$ oc apply -f <file>.yaml
ここでは、以下のようになります。
<file>
- YAML マニフェストを含むファイルの名前を指定します。