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. ユーザー定義ネットワークの利点

ユーザー定義ネットワークには次のような利点があります。

  1. セキュリティーのためのネットワーク分離の強化

    • テナントの分離: Red Hat OpenStack Platform (RHOSP) でテナントが分離される方法と同様に、namespace には独自の分離されたプライマリーネットワークを設定できます。これにより、テナント間のトラフィックのリスクが軽減され、セキュリティーが向上します。
  2. ネットワークの柔軟性

    • レイヤー 2 およびレイヤー 3 のサポート: クラスター管理者は、プライマリーネットワークをレイヤー 2 またはレイヤー 3 のネットワークタイプとして設定できます。
  3. 簡素化されたネットワーク管理

    • ネットワーク設定の複雑さの軽減: ユーザー定義ネットワークでは、異なるネットワーク内のワークロードをグループ化することで分離を実現できるため、複雑なネットワークポリシーが不要になります。
  4. 高度な機能

    • 一貫性があり選択可能な IP アドレス指定: ユーザーは、異なる namespace 間とクラスター間で IP サブネットを指定して再利用できるため、一貫性のあるネットワーク環境が実現します。
    • 複数のネットワークのサポート: ユーザー定義のネットワーク機能により、管理者は複数の namespace を単一のネットワークに接続したり、異なる namespace セットごとに個別のネットワークを作成したりできます。
  5. Red Hat OpenStack Platform (RHOSP) からのアプリケーション移行の簡素化

    • ネットワークパリティー: ユーザー定義ネットワークでは、同様のネットワーク分離および設定オプションが提供されるため、OpenStack から OpenShift Container Platform へのアプリケーションの移行が簡素化されます。

開発者と管理者は、カスタムリソースを使用して、namespace スコープのユーザー定義ネットワークを作成できます。プロセスの概要は次のとおりです。

  1. 管理者は、k8s.ovn.org/primary-user-defined-network ラベルを使用して、ユーザー定義ネットワークの namespace を作成します。
  2. UserDefinedNetwork CR は、クラスター管理者またはユーザーによって作成されます。
  3. ユーザーは 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 トポロジー

仮想スイッチを使用して node-1 と node-2 の仮想マシンが相互に通信するフラットなレイヤー 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)

仮想マシンを node-1 から node-2 に移行するためにレイヤー 2 トポロジーを使用する UDN

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

16.2.1.4. ClusterUserDefinedNetwork CR について

ClusterUserDefinedNetwork (UDN) カスタムリソース (CR) は、管理者のみにクラスタースコープのネットワークセグメンテーションと分離を提供します。

次の図は、クラスター管理者が ClusterUserDefinedNetwork CR を使用してテナント間のネットワーク分離を作成する方法を示しています。このネットワーク設定により、ネットワークを複数の namespace にまたがって構築できるようになります。この図では、udn-1udn-2 という 2 つのユーザー定義ネットワークを作成することでネットワークを分離しています。これらのネットワークは接続されておらず、spec.namespaceSelector.matchLabels フィールドを使用して異なる namespace を選択しています。たとえば、udn-1namespace-1namespace-2 の通信を設定および分離し、udn-2namespace-3namespace-4 の通信を設定および分離します。namespace を分離し、同じ namespace 内の Pod が通信できるようにすることで、分離されたテナント (Tenants 1 と Tenants 2) が作成されます。

図16.3 ClusterUserDefinedNetwork CR を使用したテナント分離

ユーザー定義ネットワーク (UDN) におけるテナント分離の概念
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 は作成されません。
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 権限を持つユーザーとしてログインしている。

手順

  1. オプション: プライマリーネットワークを使用する ClusterUserDefinedNetwork CR の場合は、次のコマンドを入力して、k8s.ovn.org/primary-user-defined-network ラベルを持つ namespace を作成します。

    Copy to Clipboard Toggle word wrap
    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: <cudn_namespace_name>
      labels:
        k8s.ovn.org/primary-user-defined-network: ""
    EOF
  2. Layer2 または Layer3 トポロジータイプのクラスター全体のユーザー定義ネットワークリクエストを作成します。

    1. Layer2 トポロジーのリクエストを定義するには、次の例のように、cluster-layer-two-udn.yaml などの YAML ファイルを作成します。

      Copy to Clipboard Toggle word wrap
      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 フィールドはネットワーク設定を記述します。受け入れられる値は Layer2Layer3 です。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/162001:db8::/64 です。
      • Layer2 サブネットは省略できます。省略した場合、ユーザーは Pod の静的 IP アドレスを設定する必要があります。結果として、ポートセキュリティーは MAC スプーフィングのみを防止します。詳細は、「静的 IP アドレスを使用した Pod 設定」を参照してください。
    2. Layer3 トポロジーの要求を定義するには、次の例のように、cluster-layer-three-udn.yaml などの YAML ファイルを作成します。

      Copy to Clipboard Toggle word wrap
      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 を指定します。有効な値には、InNotInExistsDoesNotExist などがあります。
      6
      matchExpressions タイプが使用されているため、<example_namespace_one> または <example_namespace_two> のいずれかに一致する namespace がプロビジョニングされます。
      7
      ネットワーク設定を記述します。
      8
      topology フィールドはネットワーク設定を記述します。受け入れられる値は Layer2Layer3 です。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 の長さのみがサポートされます。
  3. 次のコマンドを実行してリクエストを適用します。

    Copy to Clipboard Toggle word wrap
    $ oc create --validate=true -f <example_cluster_udn>.yaml

    この場合の <example_cluster_udn>.yamlLayer2 または Layer3 設定ファイルの名前です。

  4. 次のコマンドを実行して、リクエストが成功したことを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc get clusteruserdefinednetwork <cudn_name> -o yaml

    この場合の <cudn_name> は、クラスター全体のユーザー定義ネットワークに作成した名前です。

    出力例

    Copy to Clipboard Toggle word wrap
    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 ラベルを適用している。

手順

  1. Administrator パースペクティブから、Networking UserDefinedNetworks をクリックします。
  2. ClusterUserDefinedNetwork をクリックします。
  3. Name フィールドで、クラスタースコープの UDN の名前を指定します。
  4. Subnet フィールドに値を指定します。
  5. Project(s) Match Labels フィールドに適切なラベルを追加して、クラスター UDN が適用される namespace を選択します。
  6. 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 分離

ユーザー定義ネットワーク (UDN) における 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 は作成されません。
  • ユーザー定義ネットワークには 2 つのマスカレード IP アドレスが必要です。必要な数のネットワークを保持できる大きさになるように、マスカレードサブネットを再設定する必要があります。

    重要
    • OpenShift Container Platform 4.17 以降では、クラスターはデフォルトのマスカレードサブネットとして、IPv4 の場合は 169.254.0.0/17、IPv6 の場合は fd69::/112 を使用します。ユーザーはこれらの範囲を避ける必要があります。更新されたクラスターの場合は、デフォルトのマスカレードサブネットに変更がありません。
    • プロジェクト用のユーザー定義ネットワークが設定された後は、クラスターのマスカレードサブネットの変更はサポートされません。UserDefinedNetwork CR を設定した後にマスカレードサブネットを変更しようとすると、ネットワーク接続が中断され、設定の問題が発生する可能性があります。
  • テナントが 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 権限がある。

手順

  1. オプション: プライマリーネットワークを使用する UserDefinedNetwork CR の場合は、次のコマンドを入力して、k8s.ovn.org/primary-user-defined-network ラベルを持つ namespace を作成します。

    Copy to Clipboard Toggle word wrap
    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: <udn_namespace_name>
      labels:
        k8s.ovn.org/primary-user-defined-network: ""
    EOF
  2. Layer2 または Layer3 トポロジータイプのユーザー定義のネットワークのリクエストを作成します。

    1. Layer2 トポロジーのリクエストを定義するには、次の例のように、my-layer-two-udn.yaml などの YAML ファイルを作成します。

      Copy to Clipboard Toggle word wrap
      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 フィールドはネットワーク設定を記述します。受け入れられる値は Layer2Layer3 です。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/162001:db8::/64 です。
      • Layer2 サブネットは省略できます。省略すると、ユーザーは Pod の IP アドレスを設定する必要があります。結果として、ポートセキュリティーは MAC スプーフィングのみを防止します。
      • ipamLifecycle フィールドが指定されている場合、Layer2subnets フィールドは必須です。
    2. Layer3 トポロジーのリクエストを定義するには、次の例のように、my-layer-three-udn.yaml などの YAML ファイルを作成します。

      Copy to Clipboard Toggle word wrap
      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 フィールドはネットワーク設定を記述します。受け入れられる値は Layer2Layer3 です。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 の長さのみがサポートされます。
  3. 次のコマンドを実行してリクエストを適用します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f <my_layer_two_udn>.yaml

    この場合の <my_layer_two_udn.yaml> は、Layer2 または Layer3 設定ファイルの名前です。

  4. 次のコマンドを実行して、リクエストが成功したことを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml

    ここでは、some_custom_namespace は、ユーザー定義ネットワーク用に作成した namespace です。

    出力例

    Copy to Clipboard Toggle word wrap
    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 ラベルを適用している。

手順

  1. Administrator パースペクティブから、Networking UserDefinedNetworks をクリックします。
  2. Create UserDefinedNetwork をクリックします。
  3. Project name リストから、以前に作成した namespace を選択します。
  4. Subnet フィールドに値を指定します。
  5. Create をクリックします。ユーザー定義ネットワークは、この namespace で作成する Pod のデフォルトのプライマリーネットワークとして機能します。

16.2.1.6. ユーザー定義ネットワークの追加設定の詳細

次の表では、オプションの ClusterUserDefinedNetwork および UserDefinedNetwork カスタムリソース (CR) の追加設定について説明します。OVN-Kubernetes ネットワークトポロジーに対する明示的な要件がなく、理解していない場合は、これらのフィールドを設定することは推奨しません。

  1. ユーザー定義ネットワークのオプション設定

CUDN のフィールド

UDN のフィールド

説明

spec.network.<topology>.joinSubnets

spec.<topology>.joinSubnets

object

省略すると、プラットフォームは joinSubnets フィールドのデフォルト値を IPv4 の場合は 100.65.0.0/16、IPv6 の場合は fd99::/64 に設定します。クラスターのネットワーク内のどこかでデフォルトのアドレス値が使用されている場合は、joinSubnets フィールドを設定して上書きする必要があります。このフィールドを設定する場合は、クラスターサブネット、default ネットワーククラスターサブネット、マスカレードサブネットなど、クラスター内の他のサブネットと競合しないことを確認してください。

joinSubnets フィールドは、ユーザー定義ネットワーク内の異なるセグメント間のルーティングを設定します。デュアルスタッククラスターでは、IP ファミリーごとに 1 つずつ、合計 2 つのサブネットを設定できます。それ以外の場合は、1 つのサブネットのみが許可されます。このフィールドは Primary ネットワークに対してのみ許可されます。

spec.network.<topology>.ipam.lifecycle

spec.<topology>.ipam.lifecycle

object

spec.ipam.lifecycle フィールドは、IP アドレス管理システム (IPAM) を設定します。永続的な IP アドレスを確保するために、仮想ワークロードにこのフィールドを使用する場合があります。許可される値は Persistent のみであり、これにより、再起動後や移行後も仮想ワークロードの IP アドレスが永続的になります。Container Network Interface (CNI) によって割り当てられ、OVN-Kubernetes によって Pod の IP アドレスをプログラムするために使用されます。Pod アノテーションの場合はこれを変更しないでください。

Persistent の値は、ipam.mode パラメーターが Enabled に設定されている場合にのみ設定できます。

spec.network.<topology>.ipam.mode

spec.network.<topology>.ipam.mode

object

mode パラメーターは、OVN-Kubernetes が IP 設定を管理する範囲を制御します。以下のオプションが利用できます。

Enabled:
有効な場合、OVN-Kubernetes は IP 設定を SDN インフラストラクチャーに適用し、選択したサブネットの IP アドレスを個々の Pod に割り当てます。これはデフォルト設定です。Enabled に設定する場合は、subnets フィールドを定義する必要があります。Enabled はデフォルトの設定です。

Disabled:
無効な場合、OVN-Kubernetes は MAC アドレスのみを割り当て、レイヤー 2 通信を提供します。これにより、ユーザーは IP アドレスを設定できます。Disabled は、レイヤー 2 (セカンダリー) ネットワークでのみ使用できます。IPAM を無効にすると、ネットワークポリシーやサービスなど、IP での Pod 選択に依存する機能が動作しなくなります。さらに、このネットワークに接続されているインターフェイスでは IP ポートセキュリティーも無効になります。spec.ipam.modeDisabled. に設定されている場合、subnets フィールドは空でなければなりません。

spec.network.<topology>.mtu

spec.<topology>.mtu

integer

最大転送単位 (MTU)。デフォルト値は 1400 です。IPv4 の境界は 576 で、IPv6 の境界は 1280 です。

ここでは、以下のようになります。

<topology>
layer2 または layer3 のいずれかです。

16.2.1.7. ユーザー定義ネットワークのステータス条件タイプ

次の表は、リソースを記述するときに ClusterUserDefinedNetwork および UserDefinedNetwork CR に返されるステータス条件タイプについて説明しています。これらの条件は、デプロイメントのトラブルシューティングに使用できます。

表16.4 NetworkCreated 条件タイプ (ClusterDefinedNetwork および UserDefinedNetwork CR)
条件タイプステータス理由とメッセージ

NetworkCreated

True

True の場合、次の理由とメッセージが返されます。

理由

メッセージ

NetworkAttachmentDefinitionCreated

'NetworkAttachmentDefinition has been created in following namespaces: [example-namespace-1, example-namespace-2, example-namespace-3]'`

NetworkCreated

False

False の場合、次のいずれかのメッセージが返されます。

理由

メッセージ

SyncError

failed to generate NetworkAttachmentDefinition

SyncError

failed to update NetworkAttachmentDefinition

SyncError

primary network already exist in namespace "<namespace_name>": "<primary_network_name>"

SyncError

failed to create NetworkAttachmentDefinition: create NAD error

SyncError

foreign NetworkAttachmentDefinition with the desired name already exist

SyncError

failed to add finalizer to UserDefinedNetwork

NetworkAttachmentDefinitionDeleted

NetworkAttachmentDefinition is being deleted: [<namespace>/<nad_name>]

表16.5 NetworkAllocationSucceeded 条件タイプ (UserDefinedNetwork CR)
条件タイプステータス理由とメッセージ

NetworkAllocationSucceeded

True

True の場合、次の理由とメッセージが返されます。

理由

メッセージ

NetworkAllocationSucceeded

Network allocation succeeded for all synced nodes.

NetworkAllocationSucceeded

False

False の場合、次のメッセージが返されます。

理由

メッセージ

InternalError

Network allocation failed for at least one node: [<node_name>], check UDN events for more info.

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 トラフィックが許可されます。

Copy to Clipboard Toggle word wrap
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 ネームサーバーを削除します。

Copy to Clipboard Toggle word wrap
$ 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 権限を持つユーザーとしてログインしている。

手順

  1. オプション: プライマリーネットワークの namespace を作成します。

    Copy to Clipboard Toggle word wrap
    $ oc create namespace <namespace_name>
  2. CNO 設定を編集するには、以下のコマンドを入力します。

    Copy to Clipboard Toggle word wrap
    $ oc edit networks.operator.openshift.io cluster
  3. 以下のサンプル CR のように、作成されるプライマリーネットワークの設定を追加して、作成している CR を変更します。

    Copy to Clipboard Toggle word wrap
    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"
                }
              ]
            }
          }
  4. 変更を保存し、テキストエディターを終了して、変更をコミットします。

検証

  • 次のコマンドを実行して、CNO が NetworkAttachmentDefinition CRD を作成したことを確認します。CNO が CRD を作成するまでに遅延が発生する可能性があります。

    Copy to Clipboard Toggle word wrap
    $ oc get network-attachment-definitions -n <namespace>

    ここでは、以下のようになります。

    <namespace>
    CNO の設定に追加したネットワーク割り当ての namespace を指定します。

    出力例

    Copy to Clipboard Toggle word wrap
    NAME                 AGE
    test-network-1       14m

16.2.2.2.1. プライマリーネットワークアタッチメントの設定

プライマリーネットワークは、k8s.cni.cncf.io API グループの NetworkAttachmentDefinition API を使用して設定されます。

API の設定は、以下の表で説明されています。

表16.6 NetworkAttachmentDefinition API フィールド
フィールド説明

metadata.name

string

プライマリーネットワークの名前。

metadata.namespace

string

オブジェクトが関連付けられる namespace。

spec.config

string

JSON 形式の CNI プラグイン設定。

16.2.2.3. YAML マニフェストを適用したプライマリーネットワークアタッチメントの作成

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • NAD のデプロイ先となる namespace で作業している。

手順

  1. 以下の例のように、プライマリーネットワーク設定を含む YAML ファイルを作成します。

    Copy to Clipboard Toggle word wrap
    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 で作業している場合、この仕様は必要ありません。
  2. プライマリーネットワークを作成するには、次のコマンドを入力します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f <file>.yaml

    ここでは、以下のようになります。

    <file>
    YAML マニフェストを含むファイルの名前を指定します。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat, Inc.