Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第3章 セカンダリーネットワーク

3.1. OVN-Kubernetes でのセカンダリーネットワークの作成
リンクのコピー

クラスター管理者は、NetworkAttachmentDefinition (NAD) リソースを使用して、クラスターのセカンダリーネットワークを設定できます。

注記

セカンダリーネットワークとしてのユーザー定義ネットワークのサポートが、OpenShift Container Platform の今後のバージョンで追加される予定です。

3.1.1. OVN-Kubernetes セカンダリーネットワークの設定
リンクのコピー

Red Hat OpenShift Networking OVN-Kubernetes ネットワークプラグインを使用すると、Pod のセカンダリーネットワークインターフェイスを設定できます。セカンダリーネットワークインターフェイスを設定するには、NetworkAttachmentDefinition カスタムリソース定義 (CRD) で設定を定義する必要があります。

注記

Pod およびマルチネットワークポリシーの作成は、ノード内の OVN-Kubernetes コントロールプレーンエージェントが関連する network-attachment-definition CRD を処理するまで、保留状態のままになる場合があります。

OVN-Kubernetes セカンダリーネットワークは、レイヤー 2、レイヤー 3、または localnet トポロジーで設定できます。これらのトポロジーでサポートされる機能の詳細は、「UserDefinedNetwork および NetworkAttachmentDefinition のサポートマトリックス」を参照してください。

次のセクションでは、OVN-Kubernetes で現在セカンダリーネットワークに許可されている各トポロジーの設定例を示します。

注記

ネットワーク名は一意である必要があります。たとえば、同じネットワークを参照する異なる設定を持つ複数の NetworkAttachmentDefinition CRD の作成はサポートされていません。

3.1.1.1. OVN-Kubernetes セカンダリーネットワークのサポート対象プラットフォーム
リンクのコピー

次のサポート対象プラットフォームで OVN-Kubernetes セカンダリーネットワークを使用できます。

  • ベアメタル
  • IBM Power®
  • IBM Z®
  • IBM® LinuxONE
  • VMware vSphere
  • Red Hat OpenStack Platform (RHOSP)

3.1.1.2. OVN-Kubernetes ネットワークプラグインの JSON 設定テーブル
リンクのコピー

次の表は、OVN-Kubernetes CNI ネットワークプラグインの設定パラメーターを示しています。

Expand
表3.1 OVN-Kubernetes ネットワークプラグインの JSON 設定テーブル
フィールド型説明

cniVersion

string

CNI 仕様のバージョン。必要な値は 0.3.1 です。

name

string

ネットワークの名前。このネットワークは namespace スコープではありません。たとえば、l2-network という名前のネットワークは、別の namespace に存在する NetworkAttachmentDefinition カスタムリソース (CR) によって参照できます。この設定により、別の namespace で NetworkAttachmentDefinition CR を使用する Pod が同じセカンダリーネットワークを介して通信できるようになります。ただし、NetworkAttachmentDefinition CR は、topology、subnets、mtu、excludeSubnets、vlanID などの同じネットワーク固有のパラメーターを共有する必要があります。vlanID パラメーターは、topology フィールドが localnet に設定されている場合にのみ適用されます。

type

string

設定する CNI プラグインの名前。この値は ovn-k8s-cni-overlay に設定する必要があります。

topology

string

ネットワークのトポロジー設定。layer2 または localnet のいずれかである必要があります。

subnets

string

クラスター全体のネットワークに使用するサブネット。

"topology":"layer2" デプロイメントでは、IPv6 (2001:DBB::/64) およびデュアルスタック (192.168.100.0/24,2001:DBB::/64) サブネットがサポートされています。

省略した場合、ネットワークを実装する論理スイッチはレイヤー 2 通信のみを提供し、ユーザーは Pod の IP アドレスを設定する必要があります。ポートセキュリティーは、MAC スプーフィングのみを防止します。

mtu

string

最大伝送単位 (MTU)。この値を設定しなかった場合、Cluster Network Operator (CNO) が、プライマリーネットワークインターフェイスのアンダーレイ MTU、Geneve (Generic Network Virtualization Encapsulation) などの Pod ネットワークのオーバーレイ MTU、および IPsec などの有効な機能のバイト容量の差を計算して、デフォルトの MTU 値を設定します。

netAttachDefName

string

この設定が含まれるネットワークアタッチメント定義 CRD のメタデータの namespace と name。たとえば、この設定が namespace ns1 内の NetworkAttachmentDefinition CRD で l2-network という名前で定義されている場合、このフィールドは ns1/l2-network に設定する必要があります。

excludeSubnets

string

CIDR と IP アドレスのコンマ区切りのリスト。IP アドレスは割り当て可能な IP アドレスプールから削除され、Pod に渡されることはありません。

vlanID

integer

トポロジーが localnet に設定されている場合、指定された VLAN タグがこのセカンダリーネットワークからのトラフィックに割り当てられます。デフォルトでは、VLAN タグは割り当てられません。

physicalNetworkName

string

トポロジーが localnet に設定されている場合、複数のネットワークオーバーレイで同じ物理ネットワークマッピングを再利用できます。OVN オーバーレイが接続する物理ネットワークの名前を指定します。省略した場合、デフォルト値は localnet ネットワークの name になります。異なるネットワークを分離するには、オーバーレイ間で同じ物理ネットワークを共有するときに、異なる VLAN タグが使用されていることを確認します。

3.1.1.3. マルチネットワークポリシーとの互換性
リンクのコピー

k8s.cni.cncf.io API グループの MultiNetworkPolicy カスタムリソース定義 (CRD) によって提供されるマルチネットワークポリシー API は、OVN-Kubernetes セカンダリーネットワークと互換性があります。ネットワークポリシーを定義する場合、使用できるネットワークポリシールールは、OVN-Kubernetes セカンダリーネットワークが subnets フィールドを定義しているかどうかによって異なります。詳細は、次の表を参照してください。

Expand
表3.2 subnets CNI 設定に基づいてサポートされるマルチネットワークポリシーセレクター
subnets フィールドの指定許可されたマルチネットワークポリシーセレクター

はい

  • podSelector と namespaceSelector
  • ipBlock

いいえ

  • ipBlock

MultiNetworkPolicy オブジェクトで k8s.v1.cni.cncf.io/policy-for アノテーションを使用することで、NetworkAttachmentDefinition (NAD) カスタムリソース (CR) を指定できます。NAD CR は、ポリシーを適用するネットワークを定義します。次のマルチネットワークポリシーの例は、blue2 という名前のセカンダリーネットワークのセカンダリーネットワーク CNI 設定で subnets フィールドが定義されている場合にのみ有効です。

Pod セレクターを使用するマルチネットワークポリシーの例

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: allow-same-namespace
  annotations:
    k8s.v1.cni.cncf.io/policy-for: blue2
1 

spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}
Copy to Clipboard Toggle word wrap

次の例では、ipBlock ネットワークポリシーセレクターを使用します。これは、OVN-Kubernetes セカンダリーネットワークに対して常に有効です。

IP ブロックセレクターを使用するマルチネットワークポリシーの例

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name:  ingress-ipblock
  annotations:
    k8s.v1.cni.cncf.io/policy-for: default/flatl2net
spec:
  podSelector:
    matchLabels:
      name: access-control
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 10.200.0.0/30
Copy to Clipboard Toggle word wrap

3.1.1.4. localnet スイッチドトポロジーの設定
リンクのコピー

スイッチド localnet トポロジーは、ネットワークアタッチメント定義 (NAD) として作成されたワークロードを、クラスター全体の論理スイッチを介して物理ネットワークに相互接続します。

セカンダリーネットワークを ovs-bridge にマッピングして、OVN-Kubernetes セカンダリーネットワークとして使用する必要があります。ブリッジマッピングにより、ネットワークトラフィックが物理ネットワークに到達できるようになります。ブリッジマッピングは、インターフェイスラベルとも呼ばれる物理ネットワーク名を、Open vSwitch (OVS) で作成されたブリッジに関連付けます。

nmstate.io/v1 API グループの一部である NodeNetworkConfigurationPolicy (NNCP) オブジェクトを作成して、宣言的にマッピングを作成できます。この API は NMState Operator によって提供されます。この API を使用すると、指定した nodeSelector 式 (node-role.kubernetes.io/worker: '' など) に一致するノードにブリッジマッピングを適用できます。この宣言的なアプローチにより、NMState Operator は、ノードセレクターによって指定されたすべてのノードにセカンダリーネットワーク設定を自動的かつ透過的に適用します。

セカンダリーネットワークを接続する場合、既存の br-ex ブリッジを使用することも、新しいブリッジを作成することもできます。どのアプローチを使用するかは、特定のネットワークインフラストラクチャーによって異なります。次のアプローチを検討してください。

  • ノードにネットワークインターフェイスが 1 つしか含まれていない場合は、既存のブリッジを使用する必要があります。このネットワークインターフェイスは OVN-Kubernetes によって所有および管理されているため、br-ex ブリッジから削除したり、インターフェイス設定を変更したりしないでください。ネットワークインターフェイスを削除または変更すると、クラスターネットワークは正しく動作しなくなります。
  • ノードに複数のネットワークインターフェイスが含まれている場合は、別のネットワークインターフェイスを新しいブリッジに接続して、セカンダリーネットワークに使用できます。このアプローチでは、プライマリークラスターネットワークからトラフィックが分離されます。

次の例では、localnet1 ネットワークが br-ex ブリッジにマッピングされています。

ブリッジを共有するためのマッピングの例

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: mapping
1 

spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ''
2 

  desiredState:
    ovn:
      bridge-mappings:
      - localnet: localnet1
3 

        bridge: br-ex
4 

        state: present
5
Copy to Clipboard Toggle word wrap

1 1
設定オブジェクトの名前。
2
ノードネットワーク設定ポリシーを適用するノードを指定するノードセレクター。
3
トラフィックが OVS ブリッジに転送されるセカンダリーネットワークの名前。このセカンダリーネットワークは、OVN-Kubernetes セカンダリーネットワークを定義する NetworkAttachmentDefinition CRD の spec.config.name フィールドの名前と一致する必要があります。
4
ノード上の OVS ブリッジの名前。この値は、state: present を指定する場合にのみ必要です。
5
マッピングの状態。ブリッジを追加する場合は present、ブリッジを削除する場合は absent である必要があります。デフォルト値は present です。

次の JSON の例では、localnet1 という名前の localnet セカンダリーネットワークを設定します。mtu パラメーターの値は、br-ex ブリッジインターフェイスにマッピングされるセカンダリーネットワークインターフェイスに設定された MTU 値と一致する必要があることに注意してください。 

{
  "cniVersion": "0.3.1",
  "name": "localnet1",
  "type": "ovn-k8s-cni-overlay",
  "topology":"localnet",
  "physicalNetworkName": "localnet1",
  "subnets": "202.10.130.112/28",
  "vlanID": 33,
  "mtu": 1500,
  "netAttachDefName": "ns1/localnet-network",
  "excludeSubnets": "10.100.200.0/29"
}
Copy to Clipboard Toggle word wrap

次の例では、localnet2 ネットワークインターフェイスが ovs-br1 ブリッジに接続されています。この接続を使って、ネットワークインターフェイスを OVN-Kubernetes ネットワークプラグインでセカンダリーネットワークとして利用できるようになります。

複数のインターフェイスを持つノードのマッピング例

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ovs-br1-multiple-networks
1 

spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ''
2 

  desiredState:
    interfaces:
    - name: ovs-br1
3 

      description: |-
        A dedicated OVS bridge with eth1 as a port
        allowing all VLANs and untagged traffic
      type: ovs-bridge
      state: up
      bridge:
        allow-extra-patch-ports: true
        options:
          stp: false
          mcast-snooping-enable: true
4 

        port:
        - name: eth1
5 

    ovn:
      bridge-mappings:
      - localnet: localnet2
6 

        bridge: ovs-br1
7 

        state: present
8
Copy to Clipboard Toggle word wrap

1
設定オブジェクトの名前を指定します。
2
ノードネットワーク設定ポリシーが適用されるノードを識別するノードセレクターを指定します。
3
クラスタートラフィック用に OVN-Kubernetes によって使用されるデフォルトのブリッジとは別に動作する新しい OVS ブリッジを指定します。
4
マルチキャストスヌーピングを有効にするかどうかを指定します。マルチキャストスヌーピングを有効にすると、ネットワークデバイスがすべてのネットワークメンバーにマルチキャストトラフィックをフラッディングすることを防止します。デフォルトでは、OVS ブリッジはマルチキャストスヌーピングを有効にしません。デフォルト値は false です。
5
新しい OVS ブリッジに関連付けるホストシステム上のネットワークデバイスを指定します。
6
トラフィックを OVS ブリッジに転送するセカンダリーネットワークの名前を指定します。この名前は、OVN-Kubernetes セカンダリーネットワークを定義する NetworkAttachmentDefinition CRD の spec.config.name フィールドの値と一致する必要があります。
7
ノード上の OVS ブリッジの名前を指定します。値は、state: present が設定されている場合にのみ必要です。
8
マッピングの状態を指定します。有効な値は、ブリッジを追加する場合は present、ブリッジを削除する場合は absent です。デフォルト値は present です。

次の JSON の例では、localnet2 という名前の localnet セカンダリーネットワークを設定します。mtu パラメーターの値は、eth1 セカンダリーネットワークインターフェイスに設定された MTU 値と一致する必要があることに注意してください。 

{
  "cniVersion": "0.3.1",
  "name": "localnet2",
  "type": "ovn-k8s-cni-overlay",
  "topology":"localnet",
  "physicalNetworkName": "localnet2",
  "subnets": "202.10.130.112/28",
  "vlanID": 33,
  "mtu": 1500,
  "netAttachDefName": "ns1/localnet-network",
  "excludeSubnets": "10.100.200.0/29"
}
Copy to Clipboard Toggle word wrap
3.1.1.4.1. レイヤー 2 スイッチドトポロジーの設定
リンクのコピー

スイッチド (レイヤー 2) トポロジーネットワークは、クラスター全体の論理スイッチを介してワークロードを相互接続します。この設定は、IPv6 およびデュアルスタックデプロイメントに使用できます。

注記

レイヤー 2 スイッチドトポロジーネットワークでは、クラスター内の Pod 間のデータパケットの転送のみが許可されます。

次の JSON 例では、スイッチドセカンダリーネットワークを設定します。 

{
  "cniVersion": "0.3.1",
  "name": "l2-network",
  "type": "ovn-k8s-cni-overlay",
  "topology":"layer2",
  "subnets": "10.100.200.0/24",
  "mtu": 1300,
  "netAttachDefName": "ns1/l2-network",
  "excludeSubnets": "10.100.200.0/29"
}
Copy to Clipboard Toggle word wrap

3.1.1.5. セカンダリーネットワーク用の Pod の設定
リンクのコピー

k8s.v1.cni.cncf.io/networks アノテーションを使用して、セカンダリーネットワーク割り当てを指定する必要があります。

次の例では、このガイドに示されている割り当て設定ごとに 1 つずつ、2 つのセカンダリー割り当てを持つ Pod をプロビジョニングします。 

apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: l2-network
  name: tinypod
  namespace: ns1
spec:
  containers:
  - args:
    - pause
    image: k8s.gcr.io/e2e-test-images/agnhost:2.36
    imagePullPolicy: IfNotPresent
    name: agnhost-container
Copy to Clipboard Toggle word wrap

3.1.1.6. 静的 IP アドレスを使用して Pod を設定する
リンクのコピー

次の例では、静的 IP アドレスを使用して Pod をプロビジョニングします。

注記
  • セカンダリーネットワークアタッチメント (namespace スコープのオブジェクト) がレイヤー 2 または localnet トポロジーを使用している場合にのみ、Pod のセカンダリーネットワークアタッチメントの IP アドレスを指定できます。
  • Pod の静的 IP アドレスを指定できるのは、割り当て設定にサブネットが含まれていない場合のみです。 
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
      {
        "name": "l2-network",
1 

        "mac": "02:03:04:05:06:07",
2 

        "interface": "myiface1",
3 

        "ips": [
          "192.0.2.20/24"
          ]
4 

      }
    ]'
  name: tinypod
  namespace: ns1
spec:
  containers:
  - args:
    - pause
    image: k8s.gcr.io/e2e-test-images/agnhost:2.36
    imagePullPolicy: IfNotPresent
    name: agnhost-container
Copy to Clipboard Toggle word wrap
1
ネットワークの名前。この値は、すべての NetworkAttachmentDefinition CRD にわたって一意である必要があります。
2
インターフェイスに割り当てられる MAC アドレス。
3
Pod 用に作成されるネットワークインターフェイスの名前。
4
ネットワークインターフェイスに割り当てられる IP アドレス。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat