17.3. セカンダリーネットワーク


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

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

注記

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

17.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、またはローカルネットトポロジーで設定できます。これらのトポロジーでサポートされる機能の詳細は、「UserDefinedNetwork および NetworkAttachmentDefinition のサポートマトリックス」を参照してください。

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

注記

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

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

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

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

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

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

cniVersion

string

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

name

string

ネットワークの名前。このネットワークは namespace スコープではありません。たとえば、l2-network という名前のネットワークは、別の namespace に存在する NetworkAttachmentDefinition カスタムリソース (CR) によって参照できます。この設定により、別の namespace で NetworkAttachmentDefinition CR を使用する Pod が同じセカンダリーネットワークを介して通信できるようになります。ただし、NetworkAttachmentDefinition CR は、topologysubnetsmtuexcludeSubnetsvlanID などの同じネットワーク固有のパラメーターを共有する必要があります。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)。デフォルト値 1300 は、カーネルによって自動的に設定されます。

netAttachDefName

string

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

excludeSubnets

string

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

vlanID

integer

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

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

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

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

はい

  • podSelectornamespaceSelector
  • ipBlock

いいえ

  • ipBlock

たとえば、次のマルチネットワークポリシーは、blue2 という名前のセカンダリーネットワークのセカンダリーネットワーク CNI 設定で subnets フィールドが定義されている場合にのみ有効です。

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

Copy to Clipboard Toggle word wrap
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 ブロックセレクターを使用するマルチネットワークポリシーの例

Copy to Clipboard Toggle word wrap
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

17.3.1.1.4. localnet スイッチドトポロジーの設定

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

OVN-Kubernetes セカンダリーネットワークとして使用するには、セカンダリーネットワークを OVN ブリッジにマップする必要があります。ブリッジマッピングにより、ネットワークトラフィックが物理ネットワークに到達できるようになります。ブリッジマッピングは、インターフェイスラベルとも呼ばれる物理ネットワーク名を、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 ブリッジにマッピングされています。

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

Copy to Clipboard Toggle word wrap
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 CRD の spec.config.name フィールドの名前と一致する必要があります。
4
ノード上の OVS ブリッジの名前。この値は、state: present を指定する場合にのみ必要です。
5
マッピングの状態。ブリッジを追加する場合は present、ブリッジを削除する場合は absent である必要があります。デフォルト値は present です。

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

Copy to Clipboard Toggle word wrap
{
  "cniVersion": "0.3.1",
  "name": "ns1-localnet-network",
  "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"
}

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

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

Copy to Clipboard Toggle word wrap
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

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 セカンダリーネットワークを設定します。

Copy to Clipboard Toggle word wrap
{
  "cniVersion": "0.3.1",
  "name": "ns1-localnet-network",
  "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"
}
17.3.1.1.4.1. レイヤー 2 スイッチドトポロジーの設定

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

注記

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

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

Copy to Clipboard Toggle word wrap
{
  "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"
}
17.3.1.1.5. セカンダリーネットワーク用の Pod の設定

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

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

Copy to Clipboard Toggle word wrap
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
17.3.1.1.6. 静的 IP アドレスを使用して Pod を設定する

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

注記
  • セカンダリーネットワークアタッチメント (namespace スコープのオブジェクト) がレイヤー 2 または localnet トポロジーを使用している場合にのみ、Pod のセカンダリーネットワークアタッチメントの IP アドレスを指定できます。
  • Pod の静的 IP アドレスを指定できるのは、割り当て設定にサブネットが含まれていない場合のみです。
Copy to Clipboard Toggle word wrap
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
ネットワークの名前。この値は、すべての NetworkAttachmentDefinition CRD にわたって一意である必要があります。
2
インターフェイスに割り当てられる MAC アドレス。
3
Pod 用に作成されるネットワークインターフェイスの名前。
4
ネットワークインターフェイスに割り当てられる IP アドレス。

17.3.2. 他の CNI プラグインを使用したセカンダリーネットワークの作成

次のセクションでは、セカンダリーネットワーク用の特定の設定フィールドについて説明します。

17.3.2.1. ブリッジセカンダリーネットワークの設定

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

表17.4 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 を許可する必要があります。

Copy to Clipboard Toggle word wrap
$  bridge vlan add vid VLAN_ID dev DEV
17.3.2.1.1. ブリッジ CNI プラグインの設定例

次の例では、bridge-net という名前のセカンダリーネットワークを設定します。

Copy to Clipboard Toggle word wrap
{
  "cniVersion": "0.3.1",
  "name": "bridge-net",
  "type": "bridge",
  "isGateway": true,
  "vlan": 2,
  "ipam": {
    "type": "dhcp"
    }
}

17.3.2.2. ホストデバイスのセカンダリーネットワークの設定

注記

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

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

表17.5 ホストデバイス 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 アドレスを指定します。

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

次の例では、hostdev-net という名前のセカンダリーネットワークを設定します。

Copy to Clipboard Toggle word wrap
{
  "cniVersion": "0.3.1",
  "name": "hostdev-net",
  "type": "host-device",
  "device": "eth1"
}

17.3.2.3. VLAN セカンダリーネットワークの設定

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

表17.6 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

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

重要

vlan 設定を持つ NetworkAttachmentDefinition カスタムリソース定義 (CRD) は、ノード内の単一の Pod でのみ使用できます。CNI プラグインは、同じ master インターフェイス上に同じ vlanId を持つ vlan サブインターフェイスを複数作成できないためです。

17.3.2.3.1. VLAN 設定例

次の例は、vlan-net という名前のセカンダリーネットワークを含む vlan 設定を示しています。

Copy to Clipboard Toggle word wrap
{
  "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" ]
  }
}

17.3.2.4. IPVLAN セカンダリーネットワークの設定

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

表17.7 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

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

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

次の例では、ipvlan-net という名前のセカンダリーネットワークを設定します。

Copy to Clipboard Toggle word wrap
{
  "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"
       }
    ]
  }
}

17.3.2.5. MACVLAN セカンダリーネットワークの設定

以下のオブジェクトは、MAC 仮想 LAN (MACVLAN) Container Network Interface (CNI) プラグインの設定パラメーターについて説明しています。

表17.8 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

integer

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

linkInContainer

boolean

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

注記

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

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

次の例では、macvlan-net という名前のセカンダリーネットワークを設定します。

Copy to Clipboard Toggle word wrap
{
  "cniVersion": "0.3.1",
  "name": "macvlan-net",
  "type": "macvlan",
  "master": "eth1",
  "linkInContainer": false,
  "mode": "bridge",
  "ipam": {
    "type": "dhcp"
    }
}

17.3.2.6. TAP セカンダリーネットワークの設定

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

表17.9 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

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

17.3.2.6.1. Tap 設定の例

次の例では、mynet という名前のセカンダリーネットワークを設定します。

Copy to Clipboard Toggle word wrap
{
 "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"
}
17.3.2.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 ファイルを作成します。

    Copy to Clipboard Toggle word wrap
    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 オブジェクトを作成します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f setsebool-container-use-devices.yaml
    注記

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

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

    Copy to Clipboard Toggle word wrap
    $ oc get machineconfigpools

    予想される出力

    Copy to Clipboard Toggle word wrap
    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

    注記

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

17.3.2.7. セカンダリーネットワークで route-override プラグインを使用してルートを設定する

次のオブジェクトは、route-override CNI プラグインの設定パラメーターを示しています。

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

type

string

設定する CNI プラグインの名前: route-override

flushroutes

boolean

オプション: 既存ルートをフラッシュするには true に設定します。

flushgateway

boolean

オプション: デフォルトルート、つまりゲートウェイルートをフラッシュするには true に設定します。

delroutes

object

オプション: コンテナー namespace から削除するルートのリストを指定します。

addroutes

object

オプション: コンテナー namespace に追加するルートのリストを指定します。各ルートは、dst フィールドとオプションの gw フィールドを含むディクショナリーです。gw が省略されている場合、プラグインはデフォルトのゲートウェイ値を使用します。

skipcheck

boolean

オプション: check コマンドをスキップするには、これを true に設定します。デフォルトでは、CNI プラグインはコンテナーのライフサイクル中にネットワーク設定を検証します。route-override を使用してルートを動的に変更する場合、このチェックをスキップすると、最終設定に更新されたルートが確実に反映されます。

17.3.2.7.1. route-override プラグインの設定例

route-override CNI は、親 CNI と連鎖して使用するように設計された CNI タイプです。独立して動作するのではなく、まず親 CNI を利用してネットワークインターフェイスを作成して IP アドレスを割り当てます。その後、ルーティングルールの変更が可能になります。

次の例では、mymacvlan という名前のセカンダリーネットワークを設定します。親 CNI は、eth1 にアタッチされたネットワークインターフェイスを作成し、host-local IPAM を使用して 192.168.1.0/24 の範囲の IP アドレスを割り当てます。これにより route-override CNI が親 CNI に連結され、既存ルートをフラッシュし、192.168.0.0/24 へのルートを削除し、カスタムゲートウェイを使用して 192.168.0.0/24 の新しいルートを追加することで、ルーティングルールが変更されます。

Copy to Clipboard Toggle word wrap
{
    "cniVersion": "0.3.0",
    "name": "mymacvlan",
    "plugins": [
        {
            "type": "macvlan",         
1

            "master": "eth1",
            "mode": "bridge",
            "ipam": {
                "type": "host-local",
                "subnet": "192.168.1.0/24"
            }
        },
        {
            "type": "route-override",    
2

            "flushroutes": true,
            "delroutes": [
                {
                    "dst": "192.168.0.0/24"
                }
            ],
            "addroutes": [
                {
                    "dst": "192.168.0.0/24",
                    "gw": "10.1.254.254"
                }
            ]
        }
    ]
}
1
親 CNI は eth1 にアタッチされたネットワークインターフェイスを作成します。
2
連結された route-override CNI はルーティングルールを変更します。

関連情報

17.3.3. Pod をセカンダリーネットワークにアタッチする

クラスターユーザーとして、Pod をセカンダリーネットワークにアタッチできます。

17.3.3.1. セカンダリーネットワークに Pod を追加する

セカンダリーネットワークに Pod を追加できます。Pod は、デフォルトネットワークで通常のクラスター関連のネットワークトラフィックを継続的に送信します。

Pod が作成されると、セカンダリーネットワークが Pod にアタッチされます。ただし、Pod がすでに存在する場合は、セカンダリーネットワークをその Pod にアタッチすることはできません。

Pod はセカンダリーネットワークと同じ namespace に存在する必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • クラスターにログインする。

手順

  1. アノテーションを Pod オブジェクトに追加します。以下のアノテーション形式のいずれかのみを使用できます。

    1. カスタマイズせずにセカンダリーネットワークをアタッチするには、次の形式でアノテーションを追加します。<network> が、Pod に関連付けるセカンダリーネットワークの名前に置き換えます。

      Copy to Clipboard Toggle word wrap
      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 
      1
      1
      複数のセカンダリーネットワークを指定するには、各ネットワークをコンマで区切ります。コンマの間にはスペースを入れないでください。同じセカンダリーネットワークを複数回指定した場合、Pod は複数のネットワークインターフェイスをそのネットワークにアタッチします。
    2. カスタマイズしてセカンダリーネットワークをアタッチするには、次の形式でアノテーションを追加します。

      Copy to Clipboard Toggle word wrap
      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "<network>", 
      1
      
                "namespace": "<namespace>", 
      2
      
                "default-route": ["<default-route>"] 
      3
      
              }
            ]
      1
      NetworkAttachmentDefinition オブジェクトによって定義されたセカンダリーネットワークの名前を指定します。
      2
      NetworkAttachmentDefinition オブジェクトが定義される namespace を指定します。
      3
      オプション: 192.168.17.1 などのデフォルトルートのオーバーライドを指定します。
  2. Pod を作成するには、以下のコマンドを入力します。<name> を Pod の名前に置き換えます。

    Copy to Clipboard Toggle word wrap
    $ oc create -f <name>.yaml
  3. オプション: アノテーションが Pod CR に存在することを確認するには、<name> を Pod の名前に置き換えて、以下のコマンドを入力します。

    Copy to Clipboard Toggle word wrap
    $ oc get pod <name> -o yaml

    次の例では、example-pod Pod が net1 セカンダリーネットワークにアタッチされています。

    Copy to Clipboard Toggle word wrap
    $ oc get pod example-pod -o yaml
    apiVersion: v1
    kind: Pod
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/networks: macvlan-bridge
        k8s.v1.cni.cncf.io/network-status: |- 
    1
    
          [{
              "name": "ovn-kubernetes",
              "interface": "eth0",
              "ips": [
                  "10.128.2.14"
              ],
              "default": true,
              "dns": {}
          },{
              "name": "macvlan-bridge",
              "interface": "net1",
              "ips": [
                  "20.2.2.100"
              ],
              "mac": "22:2f:60:a5:f8:00",
              "dns": {}
          }]
      name: example-pod
      namespace: default
    spec:
      ...
    status:
      ...
    1
    k8s.v1.cni.cncf.io/network-status パラメーターは、オブジェクトの JSON 配列です。各オブジェクトは、Pod にアタッチされているセカンダリーネットワークのステータスを表します。アノテーションの値はプレーンテキストの値として保存されます。
17.3.3.1.1. Pod 固有のアドレスおよびルーティングオプションの指定

Pod をセカンダリーネットワークに割り当てる場合、特定の Pod でそのネットワークに関するその他のプロパティーを指定する必要がある場合があります。これにより、ルーティングの一部を変更することができ、静的 IP アドレスおよび MAC アドレスを指定できます。これを実行するには、JSON 形式のアノテーションを使用できます。

前提条件

  • Pod はセカンダリーネットワークと同じ namespace に存在する必要があります。
  • OpenShift CLI (oc) がインストールされている。
  • クラスターにログインすること。

手順

アドレスおよび/またはルーティングオプションを指定する間に Pod をセカンダリーネットワークに追加するには、以下の手順を実行します。

  1. Pod リソース定義を編集します。既存の Pod リソースを編集する場合は、以下のコマンドを実行してデフォルトエディターでその定義を編集します。<name> を、編集する Pod リソースの名前に置き換えます。

    Copy to Clipboard Toggle word wrap
    $ oc edit pod <name>
  2. Pod リソース定義で、k8s.v1.cni.cncf.io/networks パラメーターを Pod の metadata マッピングに追加します。k8s.v1.cni.cncf.io/networks は、追加のプロパティーを指定するだけでなく、NetworkAttachmentDefinition カスタムリソース (CR) 名を参照するオブジェクトリストの JSON 文字列を受け入れます。

    Copy to Clipboard Toggle word wrap
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]' 
    1
    1
    <network> を、以下の例にあるように JSON オブジェクトに置き換えます。一重引用符が必要です。
  3. 以下の例では、アノテーションで default-route パラメーターを使用して、デフォルトルートを持つネットワーク割り当てを指定します。

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    kind: Pod
    metadata:
      name: example-pod
      annotations:
        k8s.v1.cni.cncf.io/networks: '[
        {
          "name": "net1"
        },
        {
          "name": "net2", 
    1
    
          "default-route": ["192.0.2.1"] 
    2
    
        }]'
    spec:
      containers:
      - name: example-pod
        command: ["/bin/bash", "-c", "sleep 2000000000000"]
        image: centos/tools
    1
    name キーは、Pod に関連付けるセカンダリーネットワークの名前です。
    2
    default-route キーは、ルーティングテーブルに他のルーティングテーブルがない場合に、ルーティングされるトラフィックに使用されるゲートウェイ値を指定します。複数の default-route キーを指定すると、Pod がアクティブでなくなります。

デフォルトのルートにより、他のルートに指定されていないトラフィックがゲートウェイにルーティングされます。

重要

OpenShift Container Platform のデフォルトのネットワークインターフェイス以外のインターフェイスへのデフォルトのルートを設定すると、Pod 間のトラフィックに予想されるトラフィックが別のインターフェイスでルーティングされる可能性があります。

Pod のルーティングプロパティーを確認する場合、oc コマンドを Pod 内で ip コマンドを実行するために使用できます。

Copy to Clipboard Toggle word wrap
$ oc exec -it <pod_name> -- ip route
注記

また、Pod の k8s.v1.cni.cncf.io/network-status を参照して、JSON 形式の一覧のオブジェクトで default-route キーの有無を確認し、デフォルトルートが割り当てられているセカンダリーネットワークを確認することができます。

Pod に静的 IP アドレスまたは MAC アドレスを設定するには、JSON 形式のアノテーションを使用できます。これには、この機能をとくに許可するネットワークを作成する必要があります。これは、CNO の rawCNIConfig で指定できます。

  1. 以下のコマンドを実行して CNO CR を編集します。

    Copy to Clipboard Toggle word wrap
    $ oc edit networks.operator.openshift.io cluster

以下の YAML は、CNO の設定パラメーターを説明しています。

Cluster Network Operator YAML の設定

Copy to Clipboard Toggle word wrap
name: <name> 
1

namespace: <namespace> 
2

rawCNIConfig: '{ 
3

  ...
}'
type: Raw

1
作成するセカンダリーネットワークアタッチメントの名前を指定します。名前は指定された namespace 内で一意である必要があります。
2
ネットワークの割り当てを作成する namespace を指定します。値を指定しない場合、default の namespace が使用されます。
3
以下のテンプレートに基づく CNI プラグイン設定を JSON 形式で指定します。

以下のオブジェクトは、macvlan CNI プラグインを使用して静的 MAC アドレスと IP アドレスを使用するための設定パラメーターを説明しています。

静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト

Copy to Clipboard Toggle word wrap
{
  "cniVersion": "0.3.1",
  "name": "<name>", 
1

  "plugins": [{ 
2

      "type": "macvlan",
      "capabilities": { "ips": true }, 
3

      "master": "eth0", 
4

      "mode": "bridge",
      "ipam": {
        "type": "static"
      }
    }, {
      "capabilities": { "mac": true }, 
5

      "type": "tuning"
    }]
}

1
作成するセカンダリーネットワークアタッチメントの名前を指定します。名前は指定された namespace 内で一意である必要があります。
2
CNI プラグイン設定の配列を指定します。1 つ目のオブジェクトは、macvlan プラグイン設定を指定し、2 つ目のオブジェクトはチューニングプラグイン設定を指定します。
3
CNI プラグインのランタイム設定機能の静的 IP 機能を有効にするために要求が実行されるように指定します。
4
macvlan プラグインが使用するインターフェイスを指定します。
5
CNI プラグインの静的 MAC アドレス機能を有効にするために要求が実行されるように指定します。

上記のネットワーク割り当ては、特定の Pod に割り当てられる静的 IP アドレスと MAC アドレスを指定するキーと共に、JSON 形式のアノテーションで参照できます。

以下を使用して Pod を編集します。

Copy to Clipboard Toggle word wrap
$ oc edit pod <name>

静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト

Copy to Clipboard Toggle word wrap
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
      {
        "name": "<name>", 
1

        "ips": [ "192.0.2.205/24" ], 
2

        "mac": "CA:FE:C0:FF:EE:00" 
3

      }
    ]'

1
上記の rawCNIConfig を作成する際に、指定されるように <name> を使用します。
2
サブネットマスクを含む IP アドレスを指定します。
3
MAC アドレスを指定します。
注記

静的 IP アドレスおよび MAC アドレスを同時に使用することはできません。これらは個別に使用することも、一緒に使用することもできます。

セカンダリーネットワークを持つ Pod の IP アドレスと MAC プロパティーを検証するには、oc コマンドを使用して Pod 内で ip コマンドを実行します。

Copy to Clipboard Toggle word wrap
$ oc exec -it <pod_name> -- ip a

17.3.4. マルチネットワークポリシーの設定

管理者は MultiNetworkPolicy API を使用して、セカンダリーネットワークに接続された Pod のトラフィックを管理する複数のネットワークポリシーを作成できます。たとえば、特定のポート、IP/範囲、またはラベルに基づいてトラフィックを許可または拒否するポリシーを作成できます。

マルチネットワークポリシーを使用すると、クラスター内のセカンダリーネットワーク上のトラフィックを管理できます。これらのポリシーでは、ユーザー定義ネットワークのデフォルトのクラスターネットワークまたはプライマリーネットワークを管理できません。

クラスター管理者は、以下のネットワークタイプのいずれかにマルチネットワークポリシーを設定できます。

  • Single-Root I/O Virtualization (SR-IOV)
  • MAC Virtual Local Area Network (MacVLAN)
  • IPVLAN (IP 仮想ローカルエリアネットワーク)
  • SR-IOV 上のボンディング Container Network Interface (CNI)
  • OVN-Kubernetes セカンダリーネットワーク
注記

SR-IOV セカンダリーネットワークのマルチネットワークポリシーの設定のサポートは、カーネルネットワークインターフェイスコントローラー (NIC) でのみサポートされます。SR-IOV は、データプレーン開発キット (DPDK) アプリケーションではサポートされていません。

17.3.4.1. マルチネットワークポリシーとネットワークポリシーの違い

MultiNetworkPolicy API は、NetworkPolicy API を実装していますが、いくつかの重要な違いがあります。

  • 以下の場合は、MultiNetworkPolicy API を使用する必要があります。

    Copy to Clipboard Toggle word wrap
    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
  • CLI を使用してマルチネットワークポリシーと対話する場合は、multi-networkpolicy リソース名を使用する必要があります。たとえば、oc get multi-networkpolicy <name> コマンドを使用してマルチネットワークポリシーオブジェクトを表示できます。ここで、<name> はマルチネットワークポリシーの名前になります。
  • macvlan または SR-IOV 追加ネットワークを定義するネットワーク割り当て定義の名前でアノテーションを指定する必要があります。

    Copy to Clipboard Toggle word wrap
    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/policy-for: <network_name>

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

    <network_name>
    ネットワーク割り当て定義の名前を指定します。

17.3.4.2. クラスターのマルチネットワークポリシーの有効化

クラスター管理者は、クラスターでマルチネットワークポリシーのサポートを有効にすることができます。

前提条件

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

手順

  1. 以下の YAML で multinetwork-enable-patch.yaml ファイルを作成します。

    Copy to Clipboard Toggle word wrap
    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      useMultiNetworkPolicy: true
  2. マルチネットワークポリシーを有効にするようにクラスターを設定します。

    Copy to Clipboard Toggle word wrap
    $ oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml

    出力例

    Copy to Clipboard Toggle word wrap
    network.operator.openshift.io/cluster patched

17.3.4.3. IPv6 ネットワークでのマルチネットワークポリシーのサポート

ICMPv6 近隣探索プロトコル (NDP) は、デバイスが近隣ノードに関する情報を検出して維持できるようにするための、メッセージとプロセスのセットです。NDP は IPv6 ネットワークで重要な役割を果たし、同じリンク上のデバイス間の対話を促進します。

useMultiNetworkPolicy パラメーターが true に設定されている場合、Cluster Network Operator (CNO) はマルチネットワークポリシーの iptables 実装をデプロイします。

IPv6 ネットワークでマルチネットワークポリシーをサポートするために、Cluster Network Operator は、マルチネットワークポリシーの影響を受けるすべての Pod に次のルールのセットをデプロイします。

マルチネットワークポリシーのカスタムルール

Copy to Clipboard Toggle word wrap
kind: ConfigMap
apiVersion: v1
metadata:
  name: multi-networkpolicy-custom-rules
  namespace: openshift-multus
data:

  custom-v6-rules.txt: |
    # accept NDP
    -p icmpv6 --icmpv6-type neighbor-solicitation -j ACCEPT 
1

    -p icmpv6 --icmpv6-type neighbor-advertisement -j ACCEPT 
2

    # accept RA/RS
    -p icmpv6 --icmpv6-type router-solicitation -j ACCEPT 
3

    -p icmpv6 --icmpv6-type router-advertisement -j ACCEPT 
4

1
このルールは、近隣探索プロトコル (NDP) の一部である ICMPv6 ネイバー要請メッセージの受信を許可します。これらのメッセージは、近隣ノードのリンクレイヤーアドレスを決定するのに役立ちます。
2
このルールは、NDP の一部であり、送信者のリンクレイヤーアドレスに関する情報を提供する、受信 ICMPv6 近隣アドバタイズメントメッセージを許可します。
3
このルールは、ICMPv6 ルーター要請メッセージの受信を許可します。ホストは、これらのメッセージを使用してルーター設定情報を要求します。
4
このルールは、ホストに設定情報を提供する ICMPv6 ルーターアドバタイズメントメッセージの受信を許可します。
注記

これらの事前定義されたルールは編集できません。

これらのルールが集合することで、IPv6 環境でのアドレス解決やルーター通信などを含め、ネットワークが正しく機能するために不可欠な ICMPv6 トラフィックが有効になります。これらのルールが適用され、トラフィックを拒否するマルチネットワークポリシーがあれば、アプリケーションで接続の問題が発生することは考えられません。

17.3.4.4. マルチネットワークポリシーの使用

クラスター管理者は、マルチネットワークポリシーを作成、編集、表示、および削除することができます。

17.3.4.4.1. 前提条件
  • クラスターのマルチネットワークポリシーサポートを有効にしている。
17.3.4.4.2. CLI を使用したマルチネットワークポリシーの作成

マルチネットワークポリシーを作成し、クラスターの namespace に許可される Ingress または Egress ネットワークトラフィックを記述する詳細なルールを定義することができます。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
  • マルチネットワークポリシーが適用される namespace で作業していること。

手順

  1. ポリシールールを作成します。

    1. <policy_name>.yaml ファイルを作成します。

      Copy to Clipboard Toggle word wrap
      $ touch <policy_name>.yaml

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

      <policy_name>
      マルチネットワークポリシーのファイル名を指定します。
    2. 作成したばかりのファイルで、以下の例のようなマルチネットワークポリシーを定義します。

      すべての namespace のすべての Pod から Ingress を拒否します。

      これは基本的なポリシーであり、他のネットワークポリシーの設定によって許可されたクロス Pod トラフィック以外のすべてのクロス Pod ネットワーキングをブロックします。

      Copy to Clipboard Toggle word wrap
      apiVersion: k8s.cni.cncf.io/v1beta1
      kind: MultiNetworkPolicy
      metadata:
        name: deny-by-default
        annotations:
          k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
      spec:
        podSelector: {}
        policyTypes:
        - Ingress
        ingress: []

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

      <network_name>
      ネットワーク割り当て定義の名前を指定します。

      同じ namespace のすべての Pod から Ingress を許可します。

      Copy to Clipboard Toggle word wrap
      apiVersion: k8s.cni.cncf.io/v1beta1
      kind: MultiNetworkPolicy
      metadata:
        name: allow-same-namespace
        annotations:
          k8s.v1.cni.cncf.io/policy-for: <network_name>
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}

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

      <network_name>
      ネットワーク割り当て定義の名前を指定します。

      特定の namespace から 1 つの Pod への上りトラフィックを許可する

      このポリシーは、namespace-y で実行されている Pod から pod-a というラベルの付いた Pod へのトラフィックを許可します。

      Copy to Clipboard Toggle word wrap
      apiVersion: k8s.cni.cncf.io/v1beta1
      kind: MultiNetworkPolicy
      metadata:
        name: allow-traffic-pod
        annotations:
          k8s.v1.cni.cncf.io/policy-for: <network_name>
      spec:
        podSelector:
         matchLabels:
            pod: pod-a
        policyTypes:
        - Ingress
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                 kubernetes.io/metadata.name: namespace-y

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

      <network_name>
      ネットワーク割り当て定義の名前を指定します。

      サービスへのトラフィックを制限する

      このポリシーを適用すると、app=bookstorerole=api の両方のラベルを持つすべての Pod に、app=bookstore というラベルを持つ Pod のみがアクセスできるようになります。この例では、アプリケーションは、ラベル app=bookstore および role=api でマークされた REST API サーバーである可能性があります。

      この例では、次のユースケースに対応します。

      • サービスへのトラフィックを、それを使用する必要がある他のマイクロサービスのみに制限します。
      • データベースへの接続を制限して、それを使用するアプリケーションのみを許可します。

        Copy to Clipboard Toggle word wrap
        apiVersion: k8s.cni.cncf.io/v1beta1
        kind: MultiNetworkPolicy
        metadata:
          name: api-allow
          annotations:
            k8s.v1.cni.cncf.io/policy-for: <network_name>
        spec:
          podSelector:
            matchLabels:
              app: bookstore
              role: api
          ingress:
          - from:
              - podSelector:
                  matchLabels:
                    app: bookstore

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

        <network_name>
        ネットワーク割り当て定義の名前を指定します。
  2. マルチネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f <policy_name>.yaml -n <namespace>

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

    <policy_name>
    マルチネットワークポリシーのファイル名を指定します。
    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

    出力例

    Copy to Clipboard Toggle word wrap
    multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接作成できます。

17.3.4.4.3. マルチネットワークポリシーの編集

namespace のマルチネットワークポリシーを編集できます。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
  • マルチネットワークポリシーが存在する namespace で作業している。

手順

  1. オプション: namespace のマルチネットワークポリシーオブジェクトをリスト表示するには、以下のコマンドを入力します。

    Copy to Clipboard Toggle word wrap
    $ oc get multi-networkpolicy

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

    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
  2. マルチネットワークポリシーオブジェクトを編集します。

    • マルチネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。

      Copy to Clipboard Toggle word wrap
      $ oc apply -n <namespace> -f <policy_file>.yaml

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

      <namespace>
      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
      <policy_file>
      ネットワークポリシーを含むファイルの名前を指定します。
    • マルチネットワークポリシーオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。

      Copy to Clipboard Toggle word wrap
      $ oc edit multi-networkpolicy <policy_name> -n <namespace>

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

      <policy_name>
      ネットワークポリシーの名前を指定します。
      <namespace>
      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
  3. マルチネットワークポリシーオブジェクトが更新されていることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc describe multi-networkpolicy <policy_name> -n <namespace>

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

    <policy_name>
    マルチネットワークポリシーの名前を指定します。
    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接編集できます。

17.3.4.4.4. CLI を使用したマルチネットワークポリシーの表示

namespace のマルチネットワークポリシーを検査できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
  • マルチネットワークポリシーが存在する namespace で作業している。

手順

  • namespace のマルチネットワークポリシーをリスト表示します。

    • namespace で定義されたマルチネットワークポリシーオブジェクトを表示するには、以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap
      $ oc get multi-networkpolicy
    • オプション: 特定のマルチネットワークポリシーを検査するには、以下のコマンドを入力します。

      Copy to Clipboard Toggle word wrap
      $ oc describe multi-networkpolicy <policy_name> -n <namespace>

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

      <policy_name>
      検査するマルチネットワークポリシーの名前を指定します。
      <namespace>
      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接表示できます。

17.3.4.4.5. CLI を使用したマルチネットワークポリシーの削除

namespace のマルチネットワークポリシーを削除できます。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
  • マルチネットワークポリシーが存在する namespace で作業している。

手順

  • マルチネットワークポリシーオブジェクトを削除するには、以下のコマンドを入力します。

    Copy to Clipboard Toggle word wrap
    $ oc delete multi-networkpolicy <policy_name> -n <namespace>

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

    <policy_name>
    マルチネットワークポリシーの名前を指定します。
    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

    出力例

    Copy to Clipboard Toggle word wrap
    multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接削除できます。

17.3.4.4.6. デフォルトのすべてのマルチネットワーク拒否ポリシーの作成

このポリシーは、デプロイされた他のネットワークポリシーの設定によって許可されたネットワークトラフィックと、ホストネットワークを使用する Pod 間のトラフィック以外のすべての Pod 間ネットワークをブロックします。この手順では、my-project namespace に deny-by-default ポリシーを適用することにより、強力な拒否ポリシーを強制します。

警告

トラフィック通信を許可する NetworkPolicy カスタムリソース (CR) を設定しない場合、次のポリシーによってクラスター全体で通信問題が発生する可能性があります。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
  • マルチネットワークポリシーが適用される namespace で作業していること。

手順

  1. すべての namespace におけるすべての Pod からの Ingress を拒否する deny-by-default ポリシーを定義する次の YAML を作成します。YAML を deny-by-default.yaml ファイルに保存します。

    Copy to Clipboard Toggle word wrap
    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
    metadata:
      name: deny-by-default
      namespace: my-project 
    1
    
      annotations:
        k8s.v1.cni.cncf.io/policy-for: <namespace_name>/<network_name> 
    2
    
    spec:
      podSelector: {} 
    3
    
      policyTypes: 
    4
    
      - Ingress 
    5
    
      ingress: [] 
    6
    1
    ポリシーをデプロイする namespace を指定します。たとえば、my-project namespace です。
    2
    ネットワーク割り当て定義の名前を指定します。
    3
    このフィールドが空の場合、設定はすべての Pod と一致します。したがって、ポリシーは my-project namespace 内のすべての Pod に適用されます。
    4
    NetworkPolicy が関連するルールタイプのリストを指定します。
    5
    Ingress 専用の policyTypes を指定します。
    6
    Ingress ルールを指定します。指定しない場合は、すべての Pod へのすべての着信トラフィックがドロップされます。
  2. 次のコマンドを入力して、ポリシーを適用します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f deny-by-default.yaml

    出力例

    Copy to Clipboard Toggle word wrap
    multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created

17.3.4.4.7. 外部クライアントからのトラフィックを許可するマルチネットワークポリシーの作成

deny-by-default ポリシーを設定すると、外部クライアントからラベル app=web を持つ Pod へのトラフィックを許可するポリシーの設定に進むことができます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。

この手順に従って、パブリックインターネットから直接、またはロードバランサーを使用して Pod にアクセスすることにより、外部サービスを許可するポリシーを設定します。トラフィックは、ラベル app=web を持つ Pod にのみ許可されます。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
  • マルチネットワークポリシーが適用される namespace で作業していること。

手順

  1. パブリックインターネットからのトラフィックが直接、またはロードバランサーを使用して Pod にアクセスできるようにするポリシーを作成します。YAML を web-allow-external.yaml ファイルに保存します。

    Copy to Clipboard Toggle word wrap
    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
    metadata:
      name: web-allow-external
      namespace: default
      annotations:
        k8s.v1.cni.cncf.io/policy-for: <network_name>
    spec:
      policyTypes:
      - Ingress
      podSelector:
        matchLabels:
          app: web
      ingress:
        - {}
  2. 次のコマンドを入力して、ポリシーを適用します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f web-allow-external.yaml

    出力例

    Copy to Clipboard Toggle word wrap
    multinetworkpolicy.k8s.cni.cncf.io/web-allow-external created

    このポリシーは、次の図に示すように、外部トラフィックを含むすべてのリソースからのトラフィックを許可します。

外部クライアントからのトラフィックを許可する
17.3.4.4.8. すべての namespace からアプリケーションへのトラフィックを許可するマルチネットワークポリシーの作成
注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。

この手順に従って、すべての namespace 内のすべての Pod から特定のアプリケーションへのトラフィックを許可するポリシーを設定します。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
  • マルチネットワークポリシーが適用される namespace で作業していること。

手順

  1. すべての namespace のすべての Pod から特定のアプリケーションへのトラフィックを許可するポリシーを作成します。YAML を web-allow-all-namespaces.yaml ファイルに保存します。

    Copy to Clipboard Toggle word wrap
    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
    metadata:
      name: web-allow-all-namespaces
      namespace: default
      annotations:
        k8s.v1.cni.cncf.io/policy-for: <network_name>
    spec:
      podSelector:
        matchLabels:
          app: web 
    1
    
      policyTypes:
      - Ingress
      ingress:
      - from:
        - namespaceSelector: {} 
    2
    1
    デフォルトの namespace の app:web Pod にのみポリシーを適用します。
    2
    すべての namespace のすべての Pod を選択します。
    注記

    デフォルトでは、namespaceSelector の指定を省略した場合、namespace は選択されません。つまり、ポリシーは、ネットワークポリシーがデプロイされている namespace からのトラフィックのみを許可します。

  2. 次のコマンドを入力して、ポリシーを適用します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f web-allow-all-namespaces.yaml

    出力例

    Copy to Clipboard Toggle word wrap
    multinetworkpolicy.k8s.cni.cncf.io/web-allow-all-namespaces created

検証

  1. 次のコマンドを入力して、default namespace で Web サービスを開始します。

    Copy to Clipboard Toggle word wrap
    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
  2. 次のコマンドを実行して、alpine イメージを secondary namespace にデプロイし、シェルを開始します。

    Copy to Clipboard Toggle word wrap
    $ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
  3. シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。

    Copy to Clipboard Toggle word wrap
    # wget -qO- --timeout=2 http://web.default

    予想される出力

    Copy to Clipboard Toggle word wrap
    <!DOCTYPE html>
    <html>
    <head>
    <title>Welcome to nginx!</title>
    <style>
    html { color-scheme: light dark; }
    body { width: 35em; margin: 0 auto;
    font-family: Tahoma, Verdana, Arial, sans-serif; }
    </style>
    </head>
    <body>
    <h1>Welcome to nginx!</h1>
    <p>If you see this page, the nginx web server is successfully installed and
    working. Further configuration is required.</p>
    
    <p>For online documentation and support please refer to
    <a href="http://nginx.org/">nginx.org</a>.<br/>
    Commercial support is available at
    <a href="http://nginx.com/">nginx.com</a>.</p>
    
    <p><em>Thank you for using nginx.</em></p>
    </body>
    </html>

17.3.4.4.9. namespace からアプリケーションへのトラフィックを許可するマルチネットワークポリシーの作成
注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。

特定の namespace からラベル app=web を持つ Pod へのトラフィックを許可するポリシーを設定するには、次の手順に従います。以下の場合にこれを行うことができます。

  • 運用データベースへのトラフィックを、運用ワークロードがデプロイされている namespace のみに制限します。
  • 特定の namespace にデプロイされた監視ツールを有効にして、現在の namespace からメトリクスをスクレイピングします。

前提条件

  • クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
  • マルチネットワークポリシーが適用される namespace で作業していること。

手順

  1. ラベルが purpose=production の特定の namespace 内にあるすべての Pod からのトラフィックを許可するポリシーを作成します。YAML を web-allow-prod.yaml ファイルに保存します。

    Copy to Clipboard Toggle word wrap
    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
    metadata:
      name: web-allow-prod
      namespace: default
      annotations:
        k8s.v1.cni.cncf.io/policy-for: <network_name>
    spec:
      podSelector:
        matchLabels:
          app: web 
    1
    
      policyTypes:
      - Ingress
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              purpose: production 
    2
    1
    デフォルトの namespace の app:web Pod にのみポリシーを適用します。
    2
    ラベルが purpose=production の namespace 内にある Pod のみにトラフィックを制限します。
  2. 次のコマンドを入力して、ポリシーを適用します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f web-allow-prod.yaml

    出力例

    Copy to Clipboard Toggle word wrap
    multinetworkpolicy.k8s.cni.cncf.io/web-allow-prod created

検証

  1. 次のコマンドを入力して、default namespace で Web サービスを開始します。

    Copy to Clipboard Toggle word wrap
    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
  2. 次のコマンドを実行して、prod namespace を作成します。

    Copy to Clipboard Toggle word wrap
    $ oc create namespace prod
  3. 次のコマンドを実行して、prod namespace にラベルを付けます。

    Copy to Clipboard Toggle word wrap
    $ oc label namespace/prod purpose=production
  4. 次のコマンドを実行して、dev namespace を作成します。

    Copy to Clipboard Toggle word wrap
    $ oc create namespace dev
  5. 次のコマンドを実行して、dev namespace にラベルを付けます。

    Copy to Clipboard Toggle word wrap
    $ oc label namespace/dev purpose=testing
  6. 次のコマンドを実行して、alpine イメージを dev namespace にデプロイし、シェルを開始します。

    Copy to Clipboard Toggle word wrap
    $ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
  7. シェルで次のコマンドを実行し、リクエストがブロックされていることを確認します。

    Copy to Clipboard Toggle word wrap
    # wget -qO- --timeout=2 http://web.default

    予想される出力

    Copy to Clipboard Toggle word wrap
    wget: download timed out

  8. 次のコマンドを実行して、alpine イメージを prod namespace にデプロイし、シェルを開始します。

    Copy to Clipboard Toggle word wrap
    $ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
  9. シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。

    Copy to Clipboard Toggle word wrap
    # wget -qO- --timeout=2 http://web.default

    予想される出力

    Copy to Clipboard Toggle word wrap
    <!DOCTYPE html>
    <html>
    <head>
    <title>Welcome to nginx!</title>
    <style>
    html { color-scheme: light dark; }
    body { width: 35em; margin: 0 auto;
    font-family: Tahoma, Verdana, Arial, sans-serif; }
    </style>
    </head>
    <body>
    <h1>Welcome to nginx!</h1>
    <p>If you see this page, the nginx web server is successfully installed and
    working. Further configuration is required.</p>
    
    <p>For online documentation and support please refer to
    <a href="http://nginx.org/">nginx.org</a>.<br/>
    Commercial support is available at
    <a href="http://nginx.com/">nginx.com</a>.</p>
    
    <p><em>Thank you for using nginx.</em></p>
    </body>
    </html>

17.3.4.5. 関連情報

17.3.5. セカンダリーネットワークから Pod を削除する

クラスターユーザーとして、セカンダリーネットワークから Pod を削除できます。

17.3.5.1. セカンダリーネットワークから Pod を削除する

Pod を削除することによってのみ、セカンダリーネットワークから Pod を削除できます。

前提条件

  • セカンダリーネットワークが Pod にアタッチされている。
  • OpenShift CLI (oc) がインストールされている。
  • クラスターにログインする。

手順

  • Pod を削除するには、以下のコマンドを入力します。

    Copy to Clipboard Toggle word wrap
    $ oc delete pod <name> -n <namespace>
    • <name> は Pod の名前です。
    • <namespace> は Pod が含まれる namespace です。

17.3.6. セカンダリーネットワークの編集

クラスター管理者は、既存のセカンダリーネットワークの設定を変更できます。

17.3.6.1. セカンダリーネットワークアタッチメントの定義を変更する

クラスター管理者は、既存のセカンダリーネットワークに変更を加えることができます。セカンダリーネットワークにアタッチされている既存の Pod は更新されません。

前提条件

  • クラスターのセカンダリーネットワークを設定した。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

クラスターのセカンダリーネットワークを編集するには、次の手順を実行します。

  1. 以下のコマンドを実行し、デフォルトのテキストエディターで Cluster Network Operator (CNO) CR を編集します。

    Copy to Clipboard Toggle word wrap
    $ oc edit networks.operator.openshift.io cluster
  2. additionalNetworks コレクションで、セカンダリーネットワークを変更して更新します。
  3. 変更を保存し、テキストエディターを終了して、変更をコミットします。
  4. オプション: 以下のコマンドを実行して、CNO が NetworkAttachmentDefinition オブジェクトを更新していることを確認します。<network-name> は、表示するセカンダリーネットワークの名前に置き換えます。CNO が NetworkAttachmentDefinition オブジェクトを更新して変更内容が反映されるまでに遅延が生じる可能性があります。

    Copy to Clipboard Toggle word wrap
    $ oc get network-attachment-definitions <network-name> -o yaml

    たとえば、以下のコンソールの出力は net1 という名前の NetworkAttachmentDefinition オブジェクトを表示します。

    Copy to Clipboard Toggle word wrap
    $ oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'
    { "cniVersion": "0.3.1", "type": "macvlan",
    "master": "ens5",
    "mode": "bridge",
    "ipam":       {"type":"static","routes":[{"dst":"0.0.0.0/0","gw":"10.128.2.1"}],"addresses":[{"address":"10.128.2.100/23","gateway":"10.128.2.1"}],"dns":{"nameservers":["172.30.0.10"],"domain":"us-west-2.compute.internal","search":["us-west-2.compute.internal"]}} }

17.3.7. セカンダリーネットワークでの IP アドレス割り当ての設定

次のセクションでは、セカンダリーネットワークの IP アドレスの割り当てを設定する方法についての手順と情報を提供します。

17.3.7.1. ネットワークアタッチメントの IP アドレス割り当ての設定

セカンダリーネットワークでは、Dynamic Host Configuration Protocol (DHCP) や静的割り当てなど、さまざまな割り当て方法をサポートする IP アドレス管理 (IPAM) CNI プラグインを使用して IP アドレスを割り当てることができます。

IP アドレスの動的割り当てを担当する DHCP IPAM CNI プラグインは、2 つの異なるコンポーネントを使用して動作します。

  • CNI プラグイン: Kubernetes ネットワークスタックと統合して IP アドレスを要求および解放する役割を担います。
  • DHCP IPAM CNI デーモン: 環境内の既存の DHCP サーバーと連携して IP アドレス割り当て要求を処理する DHCP イベントのリスナー。このデーモン自体は DHCP サーバーでは ありません

IPAM 設定で type: dhcp を必要とするネットワークの場合は、次の点を確認してください。

  • DHCP サーバーが環境内で利用可能かつ実行されている。DHCP サーバーはクラスターの外部にあり、お客様の既存のネットワークインフラストラクチャーの一部である必要があります。
  • DHCP サーバーが、ノードに IP アドレスを提供するように適切に設定されている。

環境内で DHCP サーバーが利用可能でない場合は、代わりに Whereabouts IPAM CNI プラグインを使用することを推奨します。Whereabouts CNI は、外部 DHCP サーバーを必要とせずに同様の IP アドレス管理機能を提供します。

注記

外部 DHCP サーバーがない場合、または静的 IP アドレス管理が望ましい場合は、Whereabouts CNI プラグインを使用してください。Whereabouts プラグインには、古くなった IP アドレスの割り当てを管理するためのリコンサイラーデーモンが含まれています。

コンテナーの有効期間中、DHCP リースを定期的に更新する必要があるため、別のデーモンである DHCP IPAM CNI デーモンが必要です。DHCP IPAM CNI デーモンをデプロイするには、セカンダリーネットワーク設定の一部としてこのデーモンのデプロイをトリガーするように Cluster Network Operator (CNO) 設定を変更します。

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

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

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

type

string

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

addresses

array

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

routes

array

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

dns

array

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

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

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

address

string

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

gateway

string

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

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

dst

string

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

gw

string

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

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

nameservers

array

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

domain

array

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

search

array

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

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

Copy to Clipboard Toggle word wrap
{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

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

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

重要

イーサネットネットワークアタッチメントの場合、SR-IOV Network Operator は DHCP サーバーデプロイメントを作成しません。Cluster Network Operator は最小限の DHCP サーバーデプロイメントを作成します。

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

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

Copy to Clipboard Toggle word wrap
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"
        }
      }
  # ...

次の表は、DHCP による動的 IP アドレス割り当ての設定パラメーターを示しています。

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

type

string

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

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

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

Copy to Clipboard Toggle word wrap
{
  "ipam": {
    "type": "dhcp"
  }
}

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

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

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

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

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

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

type

string

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

range

string

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

exclude

array

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

network_name

string

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

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

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

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

Copy to Clipboard Toggle word wrap
{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

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

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

NetworkAttachmentDefinition 1

Copy to Clipboard Toggle word wrap
{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/29",
    "network_name": "example_net_common", 
1

  }
}

1
オプション: 設定されている場合、NetworkAttachmentDefinition 2network_name と一致する必要があります。

NetworkAttachmentDefinition 2

Copy to Clipboard Toggle word wrap
{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/24",
    "network_name": "example_net_common", 
1

  }
}

1
オプション: 設定されている場合、NetworkAttachmentDefinition 1network_name と一致する必要があります。
17.3.7.1.4. whereabouts-reconciler デーモンセットの作成

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

注記

動的 IP アドレスの割り当てには、NetworkAttachmentDefinition カスタムリソース定義 (CRD) を使用することもできます。

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

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

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

手順

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

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

    Copy to Clipboard Toggle word wrap
    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 デーモンセットが正常にデプロイされたことを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc get all -n openshift-multus | grep whereabouts-reconciler

    出力例

    Copy to Clipboard Toggle word wrap
    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

17.3.7.1.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 オブジェクトを作成します。

    Copy to Clipboard Toggle word wrap
    $ 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 に関連するリソースに関する情報を取得します。

    Copy to Clipboard Toggle word wrap
    $ oc get all -n openshift-multus | grep whereabouts-reconciler

    出力例

    Copy to Clipboard Toggle word wrap
    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 リコンサイラーを実行していることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc -n openshift-multus logs whereabouts-reconciler-2p7hw

    出力例

    Copy to Clipboard Toggle word wrap
    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

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

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

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

手順

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

    Copy to Clipboard Toggle word wrap
    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 アドレスがメタデータとして割り当てられることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc exec -it mypod -- ip a

17.3.8. コンテナーネットワーク namespace での master インターフェイスの設定

次のセクションでは、master インターフェイスに基づいて MAC-VLAN、IP-VLAN、および VLAN サブインターフェイスを作成および管理する方法について手順と情報を提供します。

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

コンテナー namespace に存在する master インターフェイスに基づいて、MAC-VLAN、IP-VLAN、または VLAN サブインターフェイスを作成できます。別のネットワークアタッチメント定義 CRD で、Pod ネットワーク設定の一部として master インターフェイスを作成することもできます。

コンテナー namespace の master インターフェイスを使用するには、NetworkAttachmentDefinition CRD のサブインターフェイス設定に存在する linkInContainer パラメーターに true を指定する必要があります。

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

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

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

図17.4 VLAN の作成

VLAN の作成

前提条件

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

手順

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

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

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

      Copy to Clipboard Toggle word wrap
      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 を適用します。

      Copy to Clipboard Toggle word wrap
      $ oc apply -f sriov-node-network-policy.yaml
      注記

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

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

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

      Copy to Clipboard Toggle word wrap
      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 を適用します。

      Copy to Clipboard Toggle word wrap
      $ oc apply -f sriov-network-attachment.yaml
  4. VLAN セカンダリーネットワークを作成します。

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

      Copy to Clipboard Toggle word wrap
      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 設定では master 名を指定する必要があります。これは Pod ネットワークアノテーションで設定できます。
      2
      linkInContainer パラメーターを指定する必要があります。
    2. 以下のコマンドを実行して、YAML ファイルを適用します。

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

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

      注記

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

      • セキュリティーラベルのある namespace
      • 適切なネットワークアノテーションを含む Pod 定義
      Copy to Clipboard Toggle word wrap
      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 インターフェイスの master として使用される名前。
    2. 以下のコマンドを実行して、YAML ファイルを適用します。

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

    Copy to Clipboard Toggle word wrap
    $ oc describe pods nginx-pod -n test-namespace

    出力例

    Copy to Clipboard Toggle word wrap
    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

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

コンテナー namespace に存在するブリッジ master インターフェイスに基づいてサブインターフェイスを作成できます。サブインターフェイスの作成は、他のタイプのインターフェイスに適用できます。

前提条件

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

手順

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

    Copy to Clipboard Toggle word wrap
    $ oc new-project test-namespace
  2. 次の YAML の例を使用して、bridge-nad.yaml という名前のブリッジ NetworkAttachmentDefinition カスタムリソース定義 (CRD) ファイルを作成します。

    Copy to Clipboard Toggle word wrap
    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 CRD を OpenShift Container Platform クラスターに適用します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f bridge-nad.yaml
  4. 次のコマンドを入力して、NetworkAttachmentDefinition CRD が正常に作成されたことを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc get network-attachment-definitions

    出力例

    Copy to Clipboard Toggle word wrap
    NAME             AGE
    bridge-network   15s

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

    Copy to Clipboard Toggle word wrap
    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": "net1", 
    1
    
        "mode": "l3",
        "linkInContainer": true, 
    2
    
        "ipam": {"type": "whereabouts", "ipRanges": [{"range": "10.0.0.0/24"}]}
      }'
    1
    ネットワーク接続に関連付けるイーサネットインターフェイスを指定します。これはその後、Pod ネットワークアノテーションで設定されます。
    2
    master インターフェイスがコンテナーネットワーク namespace にあることを指定します。
  6. 以下のコマンドを実行して、YAML ファイルを適用します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f ipvlan-additional-network-configuration.yaml
  7. 次のコマンドを実行して、NetworkAttachmentDefinition CRD が正常に作成されたことを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc get network-attachment-definitions

    出力例

    Copy to Clipboard Toggle word wrap
    NAME             AGE
    bridge-network   87s
    ipvlan-net       9s

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

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-a
      namespace: test-namespace
      annotations:
        k8s.v1.cni.cncf.io/networks: '[
          {
            "name": "bridge-network",
            "interface": "net1" 
    1
    
          },
          {
            "name": "ipvlan-net",
            "interface": "net2"
          }
        ]'
    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 インターフェイスの master として使用する名前を指定します。
  9. 以下のコマンドを実行して、YAML ファイルを適用します。

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

    Copy to Clipboard Toggle word wrap
    $ oc get pod -n test-namespace

    出力例

    Copy to Clipboard Toggle word wrap
    NAME    READY   STATUS    RESTARTS   AGE
    pod-a   1/1     Running   0          2m36s

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

    Copy to Clipboard Toggle word wrap
    $ oc exec -n test-namespace pod-a -- ip a

    出力例

    Copy to Clipboard Toggle word wrap
    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: net1@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 net1
           valid_lft forever preferred_lft forever
        inet6 fe80::bcda:bdff:fe7e:f437/64 scope link
           valid_lft forever preferred_lft forever
    5: net2@net1: <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 net2
           valid_lft forever preferred_lft forever
        inet6 fe80::beda:bd00:17e:f437/64 scope link
           valid_lft forever preferred_lft forever

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

17.3.9. 追加ネットワークの削除

クラスター管理者は、追加のネットワーク割り当てを削除できます。

17.3.9.1. セカンダリーネットワークアタッチメントの定義を削除する

クラスター管理者は、セカンダリーネットワークを OpenShift Container Platform クラスターから削除できます。セカンダリーネットワークは、アタッチされているどの Pod からも削除されません。

前提条件

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

手順

クラスターからセカンダリーネットワークを削除するには、次の手順を実行します。

  1. 以下のコマンドを実行して、デフォルトのテキストエディターで Cluster Network Operator (CNO) を編集します。

    Copy to Clipboard Toggle word wrap
    $ oc edit networks.operator.openshift.io cluster
  2. 削除するセカンダリーネットワークの additionalNetworks コレクションから CNO が作成した設定を削除して、CR を変更します。

    Copy to Clipboard Toggle word wrap
    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks: [] 
    1
    1
    additionalNetworks コレクションのセカンダリーネットワークアタッチメントのみの設定マッピングを削除する場合、空のコレクションを指定する必要があります。
  3. クラスターのネットワークからネットワークアタッチメント定義を削除するには、次のコマンドを入力します。

    Copy to Clipboard Toggle word wrap
    $ oc delete net-attach-def <name_of_NAD> 
    1
    1
    <name_of_NAD> は、ネットワークアタッチメント定義の名前に置き換えます。
  4. 変更を保存し、テキストエディターを終了して、変更をコミットします。
  5. オプション: 次のコマンドを実行して、セカンダリーネットワーク CR が削除されたことを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc get network-attachment-definition --all-namespaces
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.