18.2. プライマリーネットワーク

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 へのアプリケーションの移行が簡素化されます。

手順

1. Layer2 または Layer3 トポロジータイプのユーザー定義のネットワークの要求を作成します。

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

      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 を指定します。4.17 でサポートされる role 仕様は Primary のみです。

      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 フィールドが指定されている場合、Layer2subnets フィールドは必須です。

   2. 次の例のように、Layer3 トポロジーの要求を定義するには、my-layer-three-udn.yaml などの YAML ファイルを作成します。

      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 ロールを指定します。4.17 でサポートされる role 仕様は Primary のみです。

      5

      Layer3 トポロジータイプの場合、subnet フィールドの設定の詳細を次に示します。

      • subnets フィールドは必須です。

      • subnets フィールドのタイプは、cidr および hostSubnet です。

        • cidr はクラスターのサブネットであり、文字列値を受け入れます。
        • hostSubnet は、クラスターサブネットが分割されるノードサブネット接頭辞を指定します。
        • IPv6 の場合、hostSubnet では /64 の長さのみがサポートされます。

2. 次のコマンドを実行してリクエストを適用します。

   $ oc apply -f <my_layer_two_udn.yaml>

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

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

   $ oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml

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

   出力例

   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: NetworkReady

手順

1. オプション: 追加のネットワークの namespace を作成します。

   $ oc create namespace <namespace_name>

2. CNO 設定を編集するには、以下のコマンドを入力します。

   $ oc edit networks.operator.openshift.io cluster

3. 以下のサンプル CR のように、作成される追加ネットワークの設定を追加して、作成している CR を変更します。

   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. 変更を保存し、テキストエディターを終了して、変更をコミットします。

手順

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

   apiVersion: k8s.cni.cncf.io/v1
   kind: NetworkAttachmentDefinition
   metadata:
     name: next-net
   spec:
     config: |-
       {
         "cniVersion": "0.3.1",
         "name": "work-network",
         "type": "host-device",
         "device": "eth1",
         "ipam": {
           "type": "dhcp"
         }
       }

2. 追加のネットワークを作成するには、次のコマンドを入力します。

   $ oc apply -f <file>.yaml

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

   <file>

   YAML マニフェストを含むファイルの名前を指定します。