18.2. 追加のネットワークの設定


クラスター管理者は、クラスターの追加のネットワークを設定できます。以下のネットワークタイプに対応しています。

18.2.1. 追加のネットワークを管理するためのアプローチ

追加したネットワークのライフサイクルを管理するには、2 つのアプローチがあります。各アプローチは同時に使用できず、追加のネットワークを管理する場合に 1 つのアプローチしか使用できません。いずれの方法でも、追加のネットワークは、お客様が設定した Container Network Interface (CNI) プラグインで管理します。

追加ネットワークの場合には、IP アドレスは、追加ネットワークの一部として設定する IPAM(IP Address Management)CNI プラグインでプロビジョニングされます。IPAM プラグインは、DHCP や静的割り当てなど、さまざまな IP アドレス割り当ての方法をサポートしています。

  • Cluster Network Operator (CNO) の設定を変更する: CNO は自動的に NetworkAttachmentDefinition オブジェクトを作成し、管理します。CNO は、オブジェクトのライフサイクル管理に加えて、DHCP で割り当てられた IP アドレスを使用する追加のネットワークで確実に DHCP が利用できるようにします。
  • YAML マニフェストを適用する: NetworkAttachmentDefinition オブジェクトを作成することで、追加のネットワークを直接管理できます。この方法では、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>

18.2.2. ネットワーク追加割り当ての設定

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

重要

NetworkAttachmentDefinition オブジェクトには、プロジェクト管理ユーザーがアクセスできるので、機密情報やシークレットを保存しないでください。

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

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

metadata.name

string

追加のネットワークの名前です。

metadata.namespace

string

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

spec.config

string

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

18.2.2.1. Cluster Network Operator による追加ネットワークの設定

追加のネットワーク割り当ての設定は、Cluster Network Operator (CNO) の設定の一部として指定します。

以下の YAML は、CNO で追加のネットワークを管理するための設定パラメーターを記述しています。

Cluster Network Operator (CNO) の設定

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
  additionalNetworks: 1
  - name: <name> 2
    namespace: <namespace> 3
    rawCNIConfig: |- 4
      {
        ...
      }
    type: Raw

1
1 つまたは複数の追加ネットワーク設定の配列。
2
作成している追加ネットワーク割り当ての名前。名前は指定された namespace 内で一意である必要があります。
3
ネットワークの割り当てを作成する namespace。値を指定しない場合、default の namespace が使用されます。
重要

OVN-Kubernetes ネットワークプラグインの namespace の問題を阻止するには、追加のネットワークアタッチメントに default という名前を付けないでください。この namespace は、default の追加のネットワークアタッチメント用に予約されているためです。

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

18.2.2.2. YAML マニフェストからの追加ネットワークの設定

追加ネットワークの設定は、以下の例のように YAML 設定ファイルから指定します。

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: <name> 1
spec:
  config: |- 2
    {
      ...
    }
1
作成している追加ネットワーク割り当ての名前。
2
JSON 形式の CNI プラグイン設定。

18.2.3. 追加のネットワークタイプの設定

次のセクションでは、追加のネットワークの具体的な設定フィールドを説明します。

18.2.3.1. ブリッジネットワークの追加設定

次のオブジェクトは、Bridge CNI プラグインの設定パラメーターを説明します。

表18.2 Bridge CNI プラグイン JSON 設定オブジェクト
フィールド説明

cniVersion

string

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

name

string

CNO 設定に以前に指定した name パラメーターの値。

type

string

設定する CNI プラグインの名前: bridge

ipam

object

IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。

bridge

string

オプション: 使用する仮想ブリッジの名前を指定します。ブリッジインターフェイスがホストに存在しない場合は、これが作成されます。デフォルト値は cni0 です。

ipMasq

boolean

オプション: 仮想ネットワークから外すトラフィックの IP マスカレードを有効にするには、true に設定します。すべてのトラフィックの送信元 IP アドレスは、ブリッジの IP アドレスに書き換えられます。ブリッジに IP アドレスがない場合は、この設定は影響を与えません。デフォルト値は false です。

isGateway

boolean

オプション: IP アドレスをブリッジに割り当てるには true に設定します。デフォルト値は false です。

isDefaultGateway

boolean

オプション: ブリッジを仮想ネットワークのデフォルトゲートウェイとして設定するには、true に設定します。デフォルト値は false です。isDefaultGatewaytrue に設定される場合、isGateway も自動的に true に設定されます。

forceAddress

boolean

オプション: 仮想ブリッジの事前に割り当てられた IP アドレスの割り当てを許可するには、true に設定します。false に設定される場合、重複サブセットの IPv4 アドレスまたは IPv6 アドレスが仮想ブリッジに割り当てられるとエラーが発生します。デフォルト値は false です。

hairpinMode

boolean

オプション: 仮想ブリッジが受信時に使用した仮想ポートでイーサネットフレームを送信できるようにするには、true に設定します。このモードは、Reflective Relay (リフレクティブリレー) としても知られています。デフォルト値は false です。

promiscMode

boolean

オプション: ブリッジで無作為検出モード (Promiscuous Mode) を有効にするには、true に設定します。デフォルト値は false です。

vlan

string

オプション: 仮想 LAN (VLAN) タグを整数値として指定します。デフォルトで、VLAN タグは割り当てません。

preserveDefaultVlan

string

オプション: デフォルトの VLAN をブリッジに接続されている veth 側で保持する必要があるか示します。デフォルトは true です。

vlanTrunk

list

オプション: VLAN トランクタグを割り当てます。デフォルト値は none です。

mtu

integer

オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。

enabledad

boolean

オプション: コンテナー側の veth の重複アドレス検出を有効にします。デフォルト値は false です。

macspoofchk

boolean

オプション: MAC スプーフィングチェックを有効にして、コンテナーから発信されるトラフィックをインターフェイスの MAC アドレスに制限します。デフォルト値は false です。

注記

VLAN パラメーターは、veth のホスト側に VLAN タグを設定し、ブリッジインターフェイスで vlan_filtering 機能を有効にします。

注記

L2 ネットワークのアップリンクを設定するには、次のコマンドを使用してアップリンクインターフェイスで VLAN を許可する必要があります。

$  bridge vlan add vid VLAN_ID dev DEV
18.2.3.1.1. ブリッジ CNI プラグインの設定例

以下の例では、bridge-net という名前の追加のネットワークを設定します。

{
  "cniVersion": "0.3.1",
  "name": "bridge-net",
  "type": "bridge",
  "isGateway": true,
  "vlan": 2,
  "ipam": {
    "type": "dhcp"
    }
}

18.2.3.2. ホストデバイスの追加ネットワークの設定

注記

devicehwaddrkernelpath、または pciBusID のいずれかのパラメーターを設定してネットワークデバイスを指定します。

以下のオブジェクトは、ホストデバイス CNI プラグインの設定パラメーターを説明しています。

表18.3 ホストデバイス CNI プラグイン JSON 設定オブジェクト
フィールド説明

cniVersion

string

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

name

string

CNO 設定に以前に指定した name パラメーターの値。

type

string

設定する CNI プラグインの名前: host-device

device

string

オプション: eth0 などのデバイスの名前。

hwaddr

string

オプション: デバイスハードウェアの MAC アドレス。

kernelpath

string

オプション: /sys/devices/pci0000:00/0000:00:1f.6 などの Linux カーネルデバイス。

pciBusID

string

オプション: 0000:00:1f.6 などのネットワークデバイスの PCI アドレスを指定します。

18.2.3.2.1. ホストデバイス設定例

以下の例では、hostdev-net という名前の追加のネットワークを設定します。

{
  "cniVersion": "0.3.1",
  "name": "hostdev-net",
  "type": "host-device",
  "device": "eth1"
}

18.2.3.3. VLAN 追加ネットワークの設定

以下のオブジェクトは、VLAN CNI プラグインの設定パラメーターを説明しています。

表18.4 VLAN CNI プラグイン JSON 設定オブジェクト
フィールド説明

cniVersion

string

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

name

string

CNO 設定に以前に指定した name パラメーターの値。

type

string

設定する CNI プラグインの名前: vlan

master

string

ネットワーク割り当てに関連付けるイーサネットインターフェイス。master が指定されない場合、デフォルトのネットワークルートのインターフェイスが使用されます。

vlanId

integer

vlan の ID を設定します。

ipam

object

IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。

mtu

integer

オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。

dns

integer

オプション: 返す DNS 情報 (DNS ネームサーバーの優先順位リストなど)。

linkInContainer

boolean

オプション: マスターインターフェイスが、コンテナーネットワーク namespace とメインネットワーク namespace のどちらにあるかを指定します。コンテナー namespace マスターインターフェイスの使用を要求するには、値を true に設定します。

18.2.3.3.1. vlan 設定例

以下の例では、vlan-net という名前の追加ネットワークを設定します。

{
  "name": "vlan-net",
  "cniVersion": "0.3.1",
  "type": "vlan",
  "master": "eth0",
  "mtu": 1500,
  "vlanId": 5,
  "linkInContainer": false,
  "ipam": {
      "type": "host-local",
      "subnet": "10.1.1.0/24"
  },
  "dns": {
      "nameservers": [ "10.1.1.1", "8.8.8.8" ]
  }
}

18.2.3.4. ipvlan 追加ネットワークの設定

以下のオブジェクトは、IPVLAN CNI プラグインの設定パラメーターを説明しています。

表18.5 IPVLAN CNI プラグイン JSON 設定オブジェクト
フィールド説明

cniVersion

string

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

name

string

CNO 設定に以前に指定した name パラメーターの値。

type

string

設定する CNI プラグインの名前: ipvlan

ipam

object

IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。これは、プラグインが連鎖している場合を除き必要です。

mode

string

オプション: 仮想ネットワークの操作モードを指定します。この値は、l2l3、または l3s である必要があります。デフォルト値は l2 です。

master

string

オプション: ネットワーク割り当てに関連付けるイーサネットインターフェイスを指定します。master が指定されない場合、デフォルトのネットワークルートのインターフェイスが使用されます。

mtu

integer

オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。

linkInContainer

boolean

オプション: マスターインターフェイスが、コンテナーネットワーク namespace とメインネットワーク namespace のどちらにあるかを指定します。コンテナー namespace マスターインターフェイスの使用を要求するには、値を true に設定します。

重要
  • ipvlan オブジェクトは、仮想インターフェイスが master インターフェイスと通信することを許可しません。したがって、コンテナーは ipvlan インターフェイスを使用してホストに到達できません。コンテナーが、Precision Time Protocol (PTP) をサポートするネットワークなど、ホストへの接続を提供するネットワークに参加していることを確認してください。
  • 1 つのの master インターフェイスを、macvlanipvlan の両方を使用するように同時に設定することはできません。
  • インターフェイスに依存できない IP 割り当てスキームの場合、ipvlan プラグインは、このロジックを処理する以前のプラグインと連鎖させることができます。master が省略された場合、前の結果にはスレーブにする ipvlan プラグインのインターフェイス名が 1 つ含まれていなければなりません。ipam が省略された場合、ipvlan インターフェイスの設定には前の結果が使用されます。
18.2.3.4.1. IPVLAN CNI プラグインの設定例

以下の例では、ipvlan-net という名前の追加のネットワークを設定します。

{
  "cniVersion": "0.3.1",
  "name": "ipvlan-net",
  "type": "ipvlan",
  "master": "eth1",
  "linkInContainer": false,
  "mode": "l3",
  "ipam": {
    "type": "static",
    "addresses": [
       {
         "address": "192.168.10.10/24"
       }
    ]
  }
}

18.2.3.5. macvlan 追加ネットワークの設定

以下のオブジェクトは、MACVLAN CNI プラグインの設定パラメーターを説明しています。

表18.6 MACVLAN CNI プラグイン JSON 設定オブジェクト
フィールド説明

cniVersion

string

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

name

string

CNO 設定に以前に指定した name パラメーターの値。

type

string

設定する CNI プラグインの名前: macvlan

ipam

object

IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。

mode

string

オプション: 仮想ネットワークのトラフィックの可視性を設定します。bridgepassthruprivate、または vepa のいずれかである必要があります。値が指定されない場合、デフォルト値は bridge になります。

master

string

オプション: 新しく作成された macvlan インターフェイスに関連付けるホストネットワークインターフェイス。値が指定されていない場合は、デフォルトのルートインターフェイスが使用されます。

mtu

string

オプション: 指定された値への最大転送単位 (MTU)。デフォルト値はカーネルによって自動的に設定されます。

linkInContainer

boolean

オプション: マスターインターフェイスが、コンテナーネットワーク namespace とメインネットワーク namespace のどちらにあるかを指定します。コンテナー namespace マスターインターフェイスの使用を要求するには、値を true に設定します。

注記

プラグイン設定の master キーを指定する場合は、競合の可能性を回避するために、プライマリーネットワークプラグインに関連付けられているものとは異なる物理ネットワークインターフェイスを使用してください。

18.2.3.5.1. MACVLAN CNI プラグイン設定の例

以下の例では、macvlan-net という名前の追加のネットワークを設定します。

{
  "cniVersion": "0.3.1",
  "name": "macvlan-net",
  "type": "macvlan",
  "master": "eth1",
  "linkInContainer": false,
  "mode": "bridge",
  "ipam": {
    "type": "dhcp"
    }
}

18.2.3.6. TAP 追加ネットワークの設定

以下のオブジェクトは、TAP CNI プラグインの設定パラメーターを説明しています。

表18.7 TAP CNI プラグイン JSON 設定オブジェクト
フィールド説明

cniVersion

string

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

name

string

CNO 設定に以前に指定した name パラメーターの値。

type

string

設定する CNI プラグインの名前: tap

mac

string

オプション: インターフェイスの指定された MAC アドレスを要求します。

mtu

integer

オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。

selinuxcontext

string

オプション: タップデバイスに関連付ける SELinux コンテキスト。

注記

OpenShift Container Platform には、値 system_u:system_r:container_t:s0 が必要です。

multiQueue

boolean

オプション: マルチキューを有効にするには true に設定します。

owner

integer

オプション: タップデバイスを所有するユーザー。

group

integer

オプション: タップデバイスを所有するグループ。

bridge

string

オプション: タップデバイスを既存のブリッジのポートとして設定します。

18.2.3.6.1. Tap 設定の例

以下の例では、mynet という名前の追加ネットワークを設定します。

{
 "name": "mynet",
 "cniVersion": "0.3.1",
 "type": "tap",
 "mac": "00:11:22:33:44:55",
 "mtu": 1500,
 "selinuxcontext": "system_u:system_r:container_t:s0",
 "multiQueue": true,
 "owner": 0,
 "group": 0
 "bridge": "br1"
}
18.2.3.6.2. TAP CNI プラグインの SELinux ブール値の設定

Container_t SELinux コンテキストを使用して Tap デバイスを作成するには、Machine Config Operator (MCO) を使用してホスト上で container_use_devices ブール値を有効にします。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次の詳細を含む、setsebool-container-use-devices.yaml などの名前の新しい YAML ファイルを作成します。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 99-worker-setsebool
    spec:
      config:
        ignition:
          version: 3.2.0
        systemd:
          units:
          - enabled: true
            name: setsebool.service
            contents: |
              [Unit]
              Description=Set SELinux boolean for the TAP CNI plugin
              Before=kubelet.service
    
              [Service]
              Type=oneshot
              ExecStart=/usr/sbin/setsebool container_use_devices=on
              RemainAfterExit=true
    
              [Install]
              WantedBy=multi-user.target graphical.target
  2. 次のコマンドを実行して、新しい MachineConfig オブジェクトを作成します。

    $ oc apply -f setsebool-container-use-devices.yaml
    注記

    MachineConfig オブジェクトに変更を適用すると、変更が適用された後、影響を受けるすべてのノードが正常に再起動します。この更新が適用されるまでに、時間がかかる場合があります。

  3. 次のコマンドを実行して、変更が適用されていることを確認します。

    $ oc get machineconfigpools

    予想される出力

    NAME        CONFIG                                                UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master      rendered-master-e5e0c8e8be9194e7c5a882e047379cfa      True      False      False      3              3                   3                     0                      7d2h
    worker      rendered-worker-d6c9ca107fba6cd76cdcbfcedcafa0f2      True      False      False      3              3                   3                     0                      7d

    注記

    すべてのノードが更新され、準備完了状態になっている必要があります。

関連情報

18.2.3.7. OVN-Kubernetes 追加ネットワークの設定

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

注記

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

OVN-Kubernetes 追加ネットワークは、レイヤー 2 または ローカルネット トポロジーで設定できます。

  • レイヤ 2 トポロジーは、East-West クラスタートラフィックをサポートしますが、基礎となる物理ネットワークへのアクセスは許可しません。
  • ローカルネットトポロジーでは物理ネットワークへの接続が可能ですが、クラスターノード上の基盤となる Open vSwitch (OVS) ブリッジの追加設定が必要です。

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

注記

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

18.2.3.7.1. OVN-Kubernetes 追加ネットワークでサポートされるプラットフォーム

OVN-Kubernetes 追加ネットワークは、次のサポートされているプラットフォームで使用できます。

  • ベアメタル
  • IBM Power®
  • IBM Z®
  • IBM® LinuxONE
  • VMware vSphere
  • Red Hat OpenStack Platform (RHOSP)
18.2.3.7.2. OVN-Kubernetes ネットワークプラグインの JSON 設定テーブル

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

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

cniVersion

string

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

name

string

ネットワークの名前。これらのネットワークには namespace が使用されていません。たとえば、l2-network という名前のネットワークを、2 つの異なる namespace に存在する 2 つの異なる NetworkAttachmentDefinition から参照させることができます。これにより、独自の異なる namespace で NetworkAttachmentDefinition を使用する Pod が同じセカンダリーネットワーク上で通信できるようになります。ただし、これら 2 つの異なる NetworkAttachmentDefinition は、topologysubnetsmtuexcludeSubnets などの同じネットワーク固有のパラメーターも共有する必要があります。

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)。デフォルト値 1300 は、カーネルによって自動的に設定されます。

netAttachDefName

string

この設定が含まれるネットワーク接続定義オブジェクトのメタデータ namespacename。たとえば、この設定が l2-network という namespace ns1NetworkAttachmentDefinition で定義されている場合、これを ns1/l2-network に設定する必要があります。

excludeSubnets

string

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

vlanID

integer

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

18.2.3.7.3. マルチネットワークポリシーとの互換性

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

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

はい

  • podSelectornamespaceSelector
  • ipBlock

いいえ

  • ipBlock

たとえば、次のマルチネットワークポリシーは、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
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}

次の例では、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

18.2.3.7.4. レイヤー 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"
}
18.2.3.7.5. ローカルネットトポロジーの設定

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

18.2.3.7.5.1. OVN-Kubernetes 追加ネットワークを設定するための前提条件
18.2.3.7.5.2. OVN-Kubernetes 追加ネットワークマッピングの設定

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

nmstate.io/v1 API グループの一部である NodeNetworkConfigurationPolicy オブジェクトを作成して、宣言的にマッピングを作成できます。この API は NMState Operator によって提供されます。この API を使用すると、指定した nodeSelector 式 (node-role.kubernetes.io/worker: '' など) に一致するノードにブリッジマッピングを適用できます。

追加のネットワークを接続する場合、既存の 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

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

次の例では、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
        port:
        - name: eth1 4
    ovn:
      bridge-mappings:
      - localnet: localnet2 5
        bridge: ovs-br1 6
        state: present 7

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

NMState Operator は、ノードセレクターによって指定されたすべてのノードに追加のネットワーク設定を自動的かつ透過的に適用するため、この宣言的アプローチが推奨されます。

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

{
  "cniVersion": "0.3.1",
  "name": "ns1-localnet-network",
  "type": "ovn-k8s-cni-overlay",
  "topology":"localnet",
  "subnets": "202.10.130.112/28",
  "vlanID": 33,
  "mtu": 1500,
  "netAttachDefName": "ns1/localnet-network"
  "excludeSubnets": "10.100.200.0/29"
}
18.2.3.7.6. 追加ネットワーク用の 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
18.2.3.7.7. 静的 IP アドレスを使用して Pod を設定する

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

注記
  • レイヤー 2 割り当てに対する 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
1
ネットワークの名前。この値は、すべての NetworkAttachmentDefinitions で一意である必要があります。
2
インターフェイスに割り当てられる MAC アドレス。
3
Pod 用に作成されるネットワークインターフェイスの名前。
4
ネットワークインターフェイスに割り当てられる IP アドレス。

18.2.4. 追加ネットワークの IP アドレス割り当ての設定

IPAM (IP アドレス管理) Container Network Interface (CNI) プラグインは、他の CNI プラグインの IP アドレスを提供します。

以下の IP アドレスの割り当てタイプを使用できます。

  • 静的割り当て。
  • DHCP サーバーを使用した動的割り当て。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
  • Whereabouts IPAM CNI プラグインを使用した動的割り当て。

18.2.4.1. 静的 IP アドレス割り当ての設定

以下の表は、静的 IP アドレスの割り当ての設定を説明しています。

表18.10 ipam 静的設定オブジェクト
フィールド説明

type

string

IPAM のアドレスタイプ。値 static が必要です。

addresses

array

仮想インターフェイスに割り当てる IP アドレスを指定するオブジェクトの配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。

routes

array

Pod 内で設定するルートを指定するオブジェクトの配列です。

dns

array

オプション: DNS の設定を指定するオブジェクトの配列です。

addressesの配列には、以下のフィールドのあるオブジェクトが必要です。

表18.11 ipam.addresses[] 配列
フィールド説明

address

string

指定する IP アドレスおよびネットワーク接頭辞。たとえば、10.10.21.10/24 を指定すると、追加のネットワークに IP アドレスの 10.10.21.10 が割り当てられ、ネットマスクは 255.255.255.0 になります。

gateway

string

Egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。

表18.12 ipam.routes[] 配列
フィールド説明

dst

string

CIDR 形式の IP アドレス範囲 (192.168.17.0/24、またはデフォルトルートの 0.0.0.0/0)。

gw

string

ネットワークトラフィックがルーティングされるゲートウェイ。

表18.13 ipam.dns オブジェクト
フィールド説明

nameservers

array

DNS クエリーの送信先となる 1 つ以上の IP アドレスの配列。

domain

array

ホスト名に追加するデフォルトのドメイン。たとえば、ドメインが example.com に設定されている場合、example-host の DNS ルックアップクエリーは example-host.example.com として書き換えられます。

search

array

DNS ルックアップのクエリー時に非修飾ホスト名に追加されるドメイン名の配列 (例: example-host)。

静的 IP アドレス割り当ての設定例

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

18.2.4.2. 動的 IP アドレス (DHCP) 割り当ての設定

以下の JSON は、DHCP を使用した動的 IP アドレスの割り当ての設定を説明しています。

DHCP リースの更新

Pod は、作成時に元の DHCP リースを取得します。リースは、クラスターで実行している最小限の DHCP サーバーデプロイメントで定期的に更新する必要があります。

DHCP サーバーのデプロイメントをトリガーするには、以下の例にあるように Cluster Network Operator 設定を編集して shim ネットワーク割り当てを作成する必要があります。

shim ネットワーク割り当ての定義例

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

表18.14 ipam DHCP 設定オブジェクト
フィールド説明

type

string

IPAM のアドレスタイプ。値 dhcp が必要です。

動的 IP アドレス (DHCP) 割り当ての設定例

{
  "ipam": {
    "type": "dhcp"
  }
}

18.2.4.3. Whereabouts を使用した動的 IP アドレス割り当ての設定

Whereabouts CNI プラグインにより、DHCP サーバーを使用せずに IP アドレスを追加のネットワークに動的に割り当てることができます。

Whereabouts CNI プラグインは、重複する IP アドレス範囲と、別々の NetworkAttachmentDefinitions 内での同じ CIDR 範囲の複数回の設定もサポートします。これにより、マルチテナント環境での柔軟性と管理機能が向上します。

18.2.4.3.1. 動的 IP アドレス設定オブジェクト

以下の表は、Whereabouts を使用した動的 IP アドレス割り当ての設定オブジェクトを説明しています。

表18.15 ipam whereabouts 設定オブジェクト
フィールド説明

type

string

IPAM のアドレスタイプ。値 whereabouts が必要です。

range

string

IP アドレスと範囲を CIDR 表記。IP アドレスは、この範囲内のアドレスから割り当てられます。

exclude

array

オプション: CIDR 表記の IP アドレスと範囲 (0 個以上) のリスト。除外されたアドレス範囲内の IP アドレスは割り当てられません。

network_name

string

オプション: 同じ範囲の IP アドレスを共有する場合でも、Pod の各グループまたはドメインが独自の IP アドレスセットを取得するようにします。このフィールドを設定することは、特にマルチテナント環境でネットワークを分離して整理しておく場合に重要です。

18.2.4.3.2. Whereabouts を使用した動的 IP アドレス割り当て設定

次の例は、Whereabouts を使用する動的アドレス割り当て設定を示しています。

whereabouts 動的 IP アドレスの割り当て

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

18.2.4.3.3. IP アドレス範囲が重複する場合に Whereabouts を使用した動的 IP アドレス割り当て

次の例は、マルチテナントネットワークで重複する IP アドレスの範囲を使用する、動的な IP アドレスの割り当てを示しています。

NetworkAttachmentDefinition 1

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/29",
    "network_name": "example_net_common", 1
  }
}

1
任意。設定されている場合、NetworkAttachmentDefinition 2 の network_name と一致する必要があります。

NetworkAttachmentDefinition 2

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/24",
    "network_name": "example_net_common", 1
  }
}

1
任意。設定されている場合、NetworkAttachmentDefinition 1 の network_name と一致する必要があります。

18.2.4.4. whereabouts-reconciler デーモンセットの作成

Whereabouts reconciler は、Whereabouts IP アドレス管理 (IPAM) ソリューションを使用して、クラスター内の Pod の動的 IP アドレス割り当てを管理します。これにより、各 Pod が指定の IP アドレス範囲から一意の IP アドレスを確実に取得します。また、Pod が削除またはスケールダウンされた場合の IP アドレスの解放も処理します。

注記

NetworkAttachmentDefinition カスタムリソース (CR) を使用して動的 IP アドレスを割り当てることもできます。

whereabouts-reconciler デーモンセットは、Cluster Network Operator を通じて追加のネットワークを設定するときに自動的に作成されます。YAML マニフェストから追加のネットワークを設定する場合、これは自動的には作成されません。

whereabouts-reconciler デーモンセットのデプロイをトリガーするには、Cluster Network Operator のカスタムリソース (CR) ファイルを編集して、whereabouts-shim ネットワーク割り当てを手動で作成する必要があります。

whereabouts-reconciler デーモンセットをデプロイするには、次の手順を使用します。

手順

  1. 以下のコマンドを実行して、Network.operator.openshift.io カスタムリソース (CR) を編集します。

    $ oc edit network.operator.openshift.io cluster
  2. この例で展開されている YAML の additionalNetworks セクションを、カスタムリソース (CR) の spec 定義内に含めます。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    # ...
    spec:
      additionalNetworks:
      - name: whereabouts-shim
        namespace: default
        rawCNIConfig: |-
          {
           "name": "whereabouts-shim",
           "cniVersion": "0.3.1",
           "type": "bridge",
           "ipam": {
             "type": "whereabouts"
           }
          }
        type: Raw
    # ...
  3. ファイルを保存し、テキストエディターを編集します。
  4. 次のコマンドを実行して、whereabouts-reconciler デーモンセットが正常にデプロイされたことを確認します。

    $ oc get all -n openshift-multus | grep whereabouts-reconciler

    出力例

    pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s
    pod/whereabouts-reconciler-k76gg 1/1 Running 0 6s
    pod/whereabouts-reconciler-k86t9 1/1 Running 0 6s
    pod/whereabouts-reconciler-p4sxw 1/1 Running 0 6s
    pod/whereabouts-reconciler-rvfdv 1/1 Running 0 6s
    pod/whereabouts-reconciler-svzw9 1/1 Running 0 6s
    daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 6s

18.2.4.5. Whereabouts IP リコンサイラーのスケジュールの設定

Whereabouts IPAM CNI プラグインは、IP リコンサイラーを毎日実行します。このプロセスは、IP が枯渇して新しい Pod に IP が割り当てられなくなる状態を避けるために、完了せずに残っている IP 割り当てをクリーンアップします。

IP リコンサイラーを実行する頻度を変更するには、次の手順を使用します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • whereabouts-reconciler デーモンセットがデプロイされており、whereabouts-reconciler Pod が起動して実行されている。

手順

  1. 次のコマンドを実行して、IP リコンサイラー用の特定の cron 式を使用し、openshift-multus namespace に whereabouts-config という名前の ConfigMap オブジェクトを作成します。

    $ oc create configmap whereabouts-config -n openshift-multus --from-literal=reconciler_cron_expression="*/15 * * * *"

    この cron 式は、IP リコンサイラーを 15 分ごとに実行するよう指定します。この式は固有の要件に基づいて調整してください。

    注記

    whereabouts-reconciler デーモンセットは、5 つのアスタリスクを含む cron 式パターンのみを使用できます。秒を表すために使用される 6 番目のアスタリスクは、現在サポートされていません。

  2. 次のコマンドを実行して、openshift-multus namespace 内の whereabouts-reconciler デーモンセットおよび Pod に関連するリソースに関する情報を取得します。

    $ oc get all -n openshift-multus | grep whereabouts-reconciler

    出力例

    pod/whereabouts-reconciler-2p7hw                   1/1     Running   0             4m14s
    pod/whereabouts-reconciler-76jk7                   1/1     Running   0             4m14s
    pod/whereabouts-reconciler-94zw6                   1/1     Running   0             4m14s
    pod/whereabouts-reconciler-mfh68                   1/1     Running   0             4m14s
    pod/whereabouts-reconciler-pgshz                   1/1     Running   0             4m14s
    pod/whereabouts-reconciler-xn5xz                   1/1     Running   0             4m14s
    daemonset.apps/whereabouts-reconciler          6         6         6       6            6           kubernetes.io/os=linux   4m16s

  3. 次のコマンドを実行して、設定した間隔で whereabouts-reconciler Pod が IP リコンサイラーを実行していることを確認します。

    $ oc -n openshift-multus logs whereabouts-reconciler-2p7hw

    出力例

    2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_33_54.1375928161": CREATE
    2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_33_54.1375928161": CHMOD
    2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..data_tmp": RENAME
    2024-02-02T16:33:54Z [verbose] using expression: */15 * * * *
    2024-02-02T16:33:54Z [verbose] configuration updated to file "/cron-schedule/..data". New cron expression: */15 * * * *
    2024-02-02T16:33:54Z [verbose] successfully updated CRON configuration id "00c2d1c9-631d-403f-bb86-73ad104a6817" - new cron expression: */15 * * * *
    2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/config": CREATE
    2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_26_17.3874177937": REMOVE
    2024-02-02T16:45:00Z [verbose] starting reconciler run
    2024-02-02T16:45:00Z [debug] NewReconcileLooper - inferred connection data
    2024-02-02T16:45:00Z [debug] listing IP pools
    2024-02-02T16:45:00Z [debug] no IP addresses to cleanup
    2024-02-02T16:45:00Z [verbose] reconciler success

18.2.4.6. デュアルスタック IP アドレスを動的に割り当てる設定の作成

デュアルスタックの IP アドレスの割り当ては、ipRanges パラメーターで設定できます。

  • IPv4 アドレス
  • IPv6 アドレス
  • 複数の IP アドレスの割り当て

手順

  1. typewhereabouts に設定します。
  2. 以下の例のように、ipRanges を使用して IP アドレスを割り当てます。

    cniVersion: operator.openshift.io/v1
    kind: Network
    =metadata:
      name: cluster
    spec:
      additionalNetworks:
      - name: whereabouts-shim
        namespace: default
        type: Raw
        rawCNIConfig: |-
          {
           "name": "whereabouts-dual-stack",
           "cniVersion": "0.3.1,
           "type": "bridge",
           "ipam": {
             "type": "whereabouts",
             "ipRanges": [
                      {"range": "192.168.10.0/24"},
                      {"range": "2001:db8::/64"}
                  ]
           }
          }
  3. ネットワークを Pod にアタッチします。詳細は、「追加のネットワークへの Pod の追加」を参照してください。
  4. すべての IP アドレスが割り当てられていることを確認します。
  5. 以下のコマンドを実行して、IP アドレスがメタデータとして割り当てられることを確認します。

    $ oc exec -it mypod -- ip a

18.2.5. Cluster Network Operator による追加ネットワーク割り当ての作成

Cluster Network Operator (CNO) は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、CNO は NetworkAttachmentDefinition オブジェクトを自動的に作成します。

重要

Cluster Network Operator が管理する NetworkAttachmentDefinition オブジェクトは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

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

検証

  • 以下のコマンドを実行して、CNO が NetworkAttachmentDefinition オブジェクトを作成していることを確認します。CNO がオブジェクトを作成するまでに遅延が生じる可能性があります。

    $ oc get network-attachment-definitions -n <namespace>

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

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

    出力例

    NAME                 AGE
    test-network-1       14m

18.2.6. YAML マニフェストを適用した追加のネットワーク割り当ての作成

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  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 マニフェストを含むファイルの名前を指定します。

18.2.7. コンテナーネットワーク namespace でのマスターインターフェイスの設定について

OpenShift Container Platform 4.14 以降では、ユーザーがコンテナー namespace 内のマスターインターフェイスに基づいて MAC-VLAN、IP-VLAN、および VLAN サブインターフェイスを作成できる機能が一般提供されるようになりました。

この機能を使用すると、別のネットワーク割り当て定義で、Pod ネットワーク設定の一部としてマスターインターフェイスを作成できます。その後、ノードのネットワーク設定の知識を必要とせずに、このインターフェイスに基づいて VLAN、MACVLAN、または IPVLAN を構築できます。

コンテナー namespace マスターインターフェイスを確実に使用するには、追加ネットワークの特定の種類に応じて、VLAN、MACVLAN、または IPVLAN プラグイン設定で linkInContainer を指定し、値を true に設定します。

18.2.7.1. SR-IOV VF 上で複数の VLAN を作成する

この機能を利用するユースケースの例として、SR-IOV VF に基づいて複数の VLAN を作成することが挙げられます。これを行うには、まず SR-IOV ネットワークを作成し、次に VLAN インターフェイスのネットワーク割り当てを定義します。

次の例は、この図に示されているセットアップを設定する方法を示しています。

図18.1 VLAN の作成

VLAN の作成

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • SR-IOV Network Operator がインストールされている。

手順

  1. 次のコマンドを使用して、Pod をデプロイする専用のコンテナー namespace を作成します。

    $ oc new-project test-namespace
  2. SR-IOV ノードポリシーを作成します。

    1. SriovNetworkNodePolicy オブジェクトを作成してから、YAML を sriov-node-network-policy.yaml ファイルに保存します。

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetworkNodePolicy
      metadata:
       name: sriovnic
       namespace: openshift-sriov-network-operator
      spec:
       deviceType: netdevice
       isRdma: false
       needVhostNet: true
       nicSelector:
         vendor: "15b3" 1
         deviceID: "101b" 2
         rootDevices: ["00:05.0"]
       numVfs: 10
       priority: 99
       resourceName: sriovnic
       nodeSelector:
          feature.node.kubernetes.io/network-sriov.capable: "true"
      注記

      deviceType: netdevice を設定した SR-IOV ネットワークノードポリシーの設定例は、Mellanox ネットワークインターフェイスカード (NIC) 向けに特別に調整されています。

      1
      SR-IOV ネットワークデバイスのベンダーの 16 進数コード。15b3 の値は Mellanox NIC に関連付けられています。
      2
      SR-IOV ネットワークデバイスのデバイスの 16 進数コード。
    2. 以下のコマンドを実行して YAML を適用します。

      $ oc apply -f sriov-node-network-policy.yaml
      注記

      ノードの再起動が必要なため、YAML の適用には時間がかかる場合があります。

  3. SR-IOV ネットワークを作成します。

    1. 次の CR の例のように、追加の SR-IOV ネットワーク割り当て用の SriovNetwork カスタムリソース (CR) を作成します。YAML を sriov-network-attachment.yaml ファイルとして保存します。

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetwork
      metadata:
       name: sriov-network
       namespace: openshift-sriov-network-operator
      spec:
       networkNamespace: test-namespace
       resourceName: sriovnic
       spoofChk: "off"
       trust: "on"
    2. 以下のコマンドを実行して YAML を適用します。

      $ oc apply -f sriov-network-attachment.yaml
  4. VLAN 追加ネットワークを作成します。

    1. 以下の YAML の例を使用して、vlan100-additional-network-configuration.yaml という名前のファイルを作成します。

      apiVersion: k8s.cni.cncf.io/v1
      kind: NetworkAttachmentDefinition
      metadata:
        name: vlan-100
        namespace: test-namespace
      spec:
        config: |
          {
            "cniVersion": "0.4.0",
            "name": "vlan-100",
            "plugins": [
              {
                "type": "vlan",
                "master": "ext0", 1
                "mtu": 1500,
                "vlanId": 100,
                "linkInContainer": true, 2
                "ipam": {"type": "whereabouts", "ipRanges": [{"range": "1.1.1.0/24"}]}
              }
            ]
          }
      1
      VLAN 設定ではマスター名を指定する必要があります。これは Pod ネットワークアノテーションで設定できます。
      2
      linkInContainer パラメーターを指定する必要があります。
    2. 以下のコマンドを実行して、YAML ファイルを適用します。

      $ oc apply -f vlan100-additional-network-configuration.yaml
  5. 前に指定したネットワークを使用して、Pod 定義を作成します。

    1. 次の YAML の例を使用して、pod-a.yaml という名前のファイルを作成します。

      注記

      以下のマニフェストには 2 つのリソースが含まれています。

      • セキュリティーラベルのある namespace
      • 適切なネットワークアノテーションを含む Pod 定義
      apiVersion: v1
      kind: Namespace
      metadata:
        name: test-namespace
        labels:
          pod-security.kubernetes.io/enforce: privileged
          pod-security.kubernetes.io/audit: privileged
          pod-security.kubernetes.io/warn: privileged
          security.openshift.io/scc.podSecurityLabelSync: "false"
      ---
      apiVersion: v1
      kind: Pod
      metadata:
        name: nginx-pod
        namespace: test-namespace
        annotations:
          k8s.v1.cni.cncf.io/networks: '[
            {
              "name": "sriov-network",
              "namespace": "test-namespace",
              "interface": "ext0" 1
            },
            {
              "name": "vlan-100",
              "namespace": "test-namespace",
              "interface": "ext0.100"
            }
          ]'
      spec:
        securityContext:
          runAsNonRoot: true
        containers:
          - name: nginx-container
            image: nginxinc/nginx-unprivileged:latest
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop: ["ALL"]
            ports:
              - containerPort: 80
            seccompProfile:
              type: "RuntimeDefault"
      1
      VLAN インターフェイスのマスターとして使用される名前。
    2. 以下のコマンドを実行して、YAML ファイルを適用します。

      $ oc apply -f pod-a.yaml
  6. 次のコマンドを実行して、test-namespace 内の nginx-pod に関する詳細情報を取得します。

    $ oc describe pods nginx-pod -n test-namespace

    出力例

    Name:         nginx-pod
    Namespace:    test-namespace
    Priority:     0
    Node:         worker-1/10.46.186.105
    Start Time:   Mon, 14 Aug 2023 16:23:13 -0400
    Labels:       <none>
    Annotations:  k8s.ovn.org/pod-networks:
                    {"default":{"ip_addresses":["10.131.0.26/23"],"mac_address":"0a:58:0a:83:00:1a","gateway_ips":["10.131.0.1"],"routes":[{"dest":"10.128.0.0...
                  k8s.v1.cni.cncf.io/network-status:
                    [{
                        "name": "ovn-kubernetes",
                        "interface": "eth0",
                        "ips": [
                            "10.131.0.26"
                        ],
                        "mac": "0a:58:0a:83:00:1a",
                        "default": true,
                        "dns": {}
                    },{
                        "name": "test-namespace/sriov-network",
                        "interface": "ext0",
                        "mac": "6e:a7:5e:3f:49:1b",
                        "dns": {},
                        "device-info": {
                            "type": "pci",
                            "version": "1.0.0",
                            "pci": {
                                "pci-address": "0000:d8:00.2"
                            }
                        }
                    },{
                        "name": "test-namespace/vlan-100",
                        "interface": "ext0.100",
                        "ips": [
                            "1.1.1.1"
                        ],
                        "mac": "6e:a7:5e:3f:49:1b",
                        "dns": {}
                    }]
                  k8s.v1.cni.cncf.io/networks:
                    [ { "name": "sriov-network", "namespace": "test-namespace", "interface": "ext0" }, { "name": "vlan-100", "namespace": "test-namespace", "i...
                  openshift.io/scc: privileged
    Status:       Running
    IP:           10.131.0.26
    IPs:
      IP:  10.131.0.26

18.2.7.2. コンテナー namespace のブリッジマスターインターフェイスをベースにしてサブインターフェイスを作成する

サブインターフェイスの作成は、他のタイプのインターフェイスに適用できます。コンテナー namespace のブリッジマスターインターフェイスをベースとしてサブインターフェイスを作成するには、次の手順を実行します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインしている。

手順

  1. 次のコマンドを実行して、Pod のデプロイ先となる専用のコンテナー namespace を作成します。

    $ oc new-project test-namespace
  2. 以下の YAML の例を使用して、bridge-nad.yaml という名前のブリッジ NetworkAttachmentDefinition カスタムリソース (CR) ファイルを作成します。

    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: bridge-network
    spec:
      config: '{
        "cniVersion": "0.4.0",
        "name": "bridge-network",
        "type": "bridge",
        "bridge": "br-001",
        "isGateway": true,
        "ipMasq": true,
        "hairpinMode": true,
        "ipam": {
          "type": "host-local",
          "subnet": "10.0.0.0/24",
          "routes": [{"dst": "0.0.0.0/0"}]
        }
      }'
  3. 以下のコマンドを実行して、NetworkAttachmentDefinition CR を OpenShift Container Platform クラスターに適用します。

    $ oc apply -f bridge-nad.yaml
  4. 以下のコマンドを実行して、NetworkAttachmentDefinition CR が正常に作成されていることを確認します。

    $ oc get network-attachment-definitions

    出力例

    NAME             AGE
    bridge-network   15s

  5. 以下の YAML の例を使用して、追加の IPVLAN ネットワーク設定用に ipvlan-additional-network-configuration.yaml という名前のファイルを作成します。

    apiVersion: k8s.cni.cncf.io/v1
    kind: NetworkAttachmentDefinition
    metadata:
      name: ipvlan-net
      namespace: test-namespace
    spec:
      config: '{
        "cniVersion": "0.3.1",
        "name": "ipvlan-net",
        "type": "ipvlan",
        "master": "ext0", 1
        "mode": "l3",
        "linkInContainer": true, 2
        "ipam": {"type": "whereabouts", "ipRanges": [{"range": "10.0.0.0/24"}]}
      }'
    1
    ネットワーク接続に関連付けるイーサネットインターフェイスを指定します。これはその後、Pod ネットワークアノテーションで設定されます。
    2
    マスターインターフェイスがコンテナーネットワーク namespace にあることを指定します。
  6. 以下のコマンドを実行して、YAML ファイルを適用します。

    $ oc apply -f ipvlan-additional-network-configuration.yaml
  7. 以下のコマンドを実行して、NetworkAttachmentDefinition CR が正常に作成されていることを確認します。

    $ oc get network-attachment-definitions

    出力例

    NAME             AGE
    bridge-network   87s
    ipvlan-net       9s

  8. 以下の YAML の例を使用して、Pod 定義用に pod-a.yaml という名前のファイルを作成します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-a
      namespace: test-namespace
      annotations:
        k8s.v1.cni.cncf.io/networks: '[
          {
            "name": "bridge-network",
            "interface": "ext0" 1
          },
          {
            "name": "ipvlan-net",
            "interface": "ext1"
          }
        ]'
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: test-pod
        image: quay.io/openshifttest/hello-sdn@sha256:c89445416459e7adea9a5a416b3365ed3d74f2491beb904d61dc8d1eb89a72a4
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: [ALL]
    1
    IPVLAN インターフェイスのマスターとして使用する名前を指定します。
  9. 以下のコマンドを実行して、YAML ファイルを適用します。

    $ oc apply -f pod-a.yaml
  10. 以下のコマンドを使用して、Pod が実行されていることを確認します。

    $ oc get pod -n test-namespace

    出力例

    NAME    READY   STATUS    RESTARTS   AGE
    pod-a   1/1     Running   0          2m36s

  11. 次のコマンドを実行して、test-namespace 内の pod-a リソースに関するネットワークインターフェイス情報を表示します。

    $ oc exec -n test-namespace pod-a -- ip a

    出力例

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host
           valid_lft forever preferred_lft forever
    3: eth0@if105: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default
        link/ether 0a:58:0a:d9:00:5d brd ff:ff:ff:ff:ff:ff link-netnsid 0
        inet 10.217.0.93/23 brd 10.217.1.255 scope global eth0
           valid_lft forever preferred_lft forever
        inet6 fe80::488b:91ff:fe84:a94b/64 scope link
           valid_lft forever preferred_lft forever
    4: ext0@if107: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
        link/ether be:da:bd:7e:f4:37 brd ff:ff:ff:ff:ff:ff link-netnsid 0
        inet 10.0.0.2/24 brd 10.0.0.255 scope global ext0
           valid_lft forever preferred_lft forever
        inet6 fe80::bcda:bdff:fe7e:f437/64 scope link
           valid_lft forever preferred_lft forever
    5: ext1@ext0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
        link/ether be:da:bd:7e:f4:37 brd ff:ff:ff:ff:ff:ff
        inet 10.0.0.1/24 brd 10.0.0.255 scope global ext1
           valid_lft forever preferred_lft forever
        inet6 fe80::beda:bd00:17e:f437/64 scope link
           valid_lft forever preferred_lft forever

    この出力は、ネットワークインターフェイス ext1 が物理インターフェイス ext0 に関連付けられていることを示しています。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.