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 ネットワークプラグインの設定パラメーターを示しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNI 仕様のバージョン。必要な値は |
|
|
ネットワークの名前。このネットワークは namespace スコープではありません。たとえば、 |
|
|
設定する CNI プラグインの名前。この値は |
|
|
ネットワークのトポロジー設定。 |
|
| クラスター全体のネットワークに使用するサブネット。
省略した場合、ネットワークを実装する論理スイッチはレイヤー 2 通信のみを提供し、ユーザーは Pod の IP アドレスを設定する必要があります。ポートセキュリティーは、MAC スプーフィングのみを防止します。 |
|
|
最大伝送単位 (MTU)。デフォルト値 |
|
|
この設定が含まれるネットワークアタッチメント定義 CRD のメタデータの |
|
| CIDR と IP アドレスのコンマ区切りのリスト。IP アドレスは割り当て可能な IP アドレスプールから削除され、Pod に渡されることはありません。 |
|
|
トポロジーが |
17.3.1.1.3. マルチネットワークポリシーとの互換性
k8s.cni.cncf.io
API グループの MultiNetworkPolicy
カスタムリソース定義 (CRD) によって提供されるマルチネットワークポリシー API は、OVN-Kubernetes セカンダリーネットワークと互換性があります。ネットワークポリシーを定義する場合、使用できるネットワークポリシールールは、OVN-Kubernetes セカンダリーネットワークが subnets
フィールドを定義しているかどうかによって異なります。詳細は、次の表を参照してください。
subnets フィールドの指定 | 許可されたマルチネットワークポリシーセレクター |
---|---|
はい |
|
いいえ |
|
たとえば、次のマルチネットワークポリシーは、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: {}
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
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
ブリッジにマッピングされています。
ブリッジを共有するためのマッピングの例
apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: mapping spec: nodeSelector: node-role.kubernetes.io/worker: '' desiredState: ovn: bridge-mappings: - localnet: localnet1 bridge: br-ex state: present
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: mapping
spec:
nodeSelector:
node-role.kubernetes.io/worker: ''
desiredState:
ovn:
bridge-mappings:
- localnet: localnet1
bridge: br-ex
state: present
- 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 Copied! Toggle word wrap Toggle overflow { "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" }
{ "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 ネットワークプラグインでセカンダリーネットワークとして利用できるようになります。
複数のインターフェイスを持つノードのマッピング例
apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: ovs-br1-multiple-networks spec: nodeSelector: node-role.kubernetes.io/worker: '' desiredState: interfaces: - name: ovs-br1 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 port: - name: eth1 ovn: bridge-mappings: - localnet: localnet2 bridge: ovs-br1 state: present
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: ovs-br1-multiple-networks
spec:
nodeSelector:
node-role.kubernetes.io/worker: ''
desiredState:
interfaces:
- name: ovs-br1
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
port:
- name: eth1
ovn:
bridge-mappings:
- localnet: localnet2
bridge: ovs-br1
state: present
- 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 Copied! Toggle word wrap Toggle overflow { "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" }
{ "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 例では、スイッチドセカンダリーネットワークを設定します。
{ "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" }
{
"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 をプロビジョニングします。
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
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 アドレスを指定できるのは、割り当て設定にサブネットが含まれていない場合のみです。
apiVersion: v1 kind: Pod metadata: annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "l2-network", "mac": "02:03:04:05:06:07", "interface": "myiface1", "ips": [ "192.0.2.20/24" ] } ]' name: tinypod namespace: ns1 spec: containers: - args: - pause image: k8s.gcr.io/e2e-test-images/agnhost:2.36 imagePullPolicy: IfNotPresent name: agnhost-container
apiVersion: v1
kind: Pod
metadata:
annotations:
k8s.v1.cni.cncf.io/networks: '[
{
"name": "l2-network",
"mac": "02:03:04:05:06:07",
"interface": "myiface1",
"ips": [
"192.0.2.20/24"
]
}
]'
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.2. 他の CNI プラグインを使用したセカンダリーネットワークの作成
次のセクションでは、セカンダリーネットワーク用の特定の設定フィールドについて説明します。
17.3.2.1. ブリッジセカンダリーネットワークの設定
次のオブジェクトは、Bridge CNI プラグインの設定パラメーターを説明します。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNI 仕様のバージョン。値 |
|
|
CNO 設定に以前に指定した |
|
|
設定する CNI プラグインの名前: |
|
| IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。 |
|
|
オプション: 使用する仮想ブリッジの名前を指定します。ブリッジインターフェイスがホストに存在しない場合は、これが作成されます。デフォルト値は |
|
|
オプション: 仮想ネットワークから外すトラフィックの IP マスカレードを有効にするには、 |
|
|
オプション: IP アドレスをブリッジに割り当てるには |
|
|
オプション: ブリッジを仮想ネットワークのデフォルトゲートウェイとして設定するには、 |
|
|
オプション: 仮想ブリッジの事前に割り当てられた IP アドレスの割り当てを許可するには、 |
|
|
オプション: 仮想ブリッジが受信時に使用した仮想ポートでイーサネットフレームを送信できるようにするには、 |
|
|
オプション: ブリッジで無作為検出モード (Promiscuous Mode) を有効にするには、 |
|
| オプション: 仮想 LAN (VLAN) タグを整数値として指定します。デフォルトで、VLAN タグは割り当てません。 |
|
|
オプション: デフォルトの VLAN をブリッジに接続されている |
|
|
オプション: VLAN トランクタグを割り当てます。デフォルト値は |
|
| オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。 |
|
|
オプション: コンテナー側の |
|
|
オプション: MAC スプーフィングチェックを有効にして、コンテナーから発信されるトラフィックをインターフェイスの MAC アドレスに制限します。デフォルト値は |
VLAN パラメーターは、veth
のホスト側に VLAN タグを設定し、ブリッジインターフェイスで vlan_filtering
機能を有効にします。
L2 ネットワークのアップリンクを設定するには、次のコマンドを使用してアップリンクインターフェイスで VLAN を許可する必要があります。
bridge vlan add vid VLAN_ID dev DEV
$ bridge vlan add vid VLAN_ID dev DEV
17.3.2.1.1. ブリッジ CNI プラグインの設定例
次の例では、bridge-net
という名前のセカンダリーネットワークを設定します。
{ "cniVersion": "0.3.1", "name": "bridge-net", "type": "bridge", "isGateway": true, "vlan": 2, "ipam": { "type": "dhcp" } }
{
"cniVersion": "0.3.1",
"name": "bridge-net",
"type": "bridge",
"isGateway": true,
"vlan": 2,
"ipam": {
"type": "dhcp"
}
}
17.3.2.2. ホストデバイスのセカンダリーネットワークの設定
device
、hwaddr
、kernelpath
、または pciBusID
のいずれかのパラメーターを設定してネットワークデバイスを指定します。
以下のオブジェクトは、ホストデバイス CNI プラグインの設定パラメーターを説明しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNI 仕様のバージョン。値 |
|
|
CNO 設定に以前に指定した |
|
|
設定する CNI プラグインの名前: |
|
|
オプション: |
|
| オプション: デバイスハードウェアの MAC アドレス。 |
|
|
オプション: |
|
|
オプション: |
17.3.2.2.1. ホストデバイス設定例
次の例では、hostdev-net
という名前のセカンダリーネットワークを設定します。
{ "cniVersion": "0.3.1", "name": "hostdev-net", "type": "host-device", "device": "eth1" }
{
"cniVersion": "0.3.1",
"name": "hostdev-net",
"type": "host-device",
"device": "eth1"
}
17.3.2.3. VLAN セカンダリーネットワークの設定
次のオブジェクトは、VLAN、vlan
、CNI プラグインの設定パラメーターを示しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNI 仕様のバージョン。値 |
|
|
CNO 設定に以前に指定した |
|
|
設定する CNI プラグインの名前: |
|
|
ネットワーク割り当てに関連付けるイーサネットインターフェイス。 |
|
|
|
|
| IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。 |
|
| オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。 |
|
| オプション: 返される DNS 情報。たとえば、DNS ネームサーバーの優先順位順リストなどです。 |
|
|
オプション: |
vlan
設定を持つ NetworkAttachmentDefinition
カスタムリソース定義 (CRD) は、ノード内の単一の Pod でのみ使用できます。CNI プラグインは、同じ master
インターフェイス上に同じ vlanId
を持つ vlan
サブインターフェイスを複数作成できないためです。
17.3.2.3.1. VLAN 設定例
次の例は、vlan-net
という名前のセカンダリーネットワークを含む vlan
設定を示しています。
{ "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" ] } }
{
"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 プラグインの設定パラメーターを示しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNI 仕様のバージョン。値 |
|
|
CNO 設定に以前に指定した |
|
|
設定する CNI プラグインの名前: |
|
| IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。これは、プラグインが連鎖している場合を除き必要です。 |
|
|
オプション: 仮想ネットワークの操作モードを指定します。この値は、 |
|
|
オプション: ネットワーク割り当てに関連付けるイーサネットインターフェイスを指定します。 |
|
| オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。 |
|
|
オプション: |
-
ipvlan
オブジェクトは、仮想インターフェイスがmaster
インターフェイスと通信することを許可しません。したがって、コンテナーはipvlan
インターフェイスを使用してホストに到達できません。コンテナーが、Precision Time Protocol (PTP
) をサポートするネットワークなど、ホストへの接続を提供するネットワークに参加していることを確認してください。 -
1 つの
master
インターフェイスを、macvlan
とipvlan
の両方を同時に使用するように設定することはできません。 -
インターフェイスに依存できない IP 割り当てスキームの場合、
ipvlan
プラグインは、このロジックを処理する以前のプラグインと連鎖させることができます。master
が省略された場合、前の結果にはスレーブにするipvlan
プラグインのインターフェイス名が 1 つ含まれていなければなりません。ipam
が省略された場合、ipvlan
インターフェイスの設定には前の結果が使用されます。
17.3.2.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" } ] } }
{
"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) プラグインの設定パラメーターについて説明しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNI 仕様のバージョン。値 |
|
|
CNO 設定に以前に指定した |
|
|
設定する CNI プラグインの名前: |
|
| IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。 |
|
|
オプション: 仮想ネットワークのトラフィックの可視性を設定します。 |
|
| オプション: 新しく作成された macvlan インターフェイスに関連付けるホストネットワークインターフェイス。値が指定されていない場合は、デフォルトのルートインターフェイスが使用されます。 |
|
| オプション: 指定された値への最大転送単位 (MTU)。デフォルト値はカーネルによって自動的に設定されます。 |
|
|
オプション: |
プラグイン設定の master
キーを指定する場合は、競合の可能性を回避するために、プライマリーネットワークプラグインに関連付けられているものとは異なる物理ネットワークインターフェイスを使用してください。
17.3.2.5.1. MACVLAN CNI プラグイン設定の例
次の例では、macvlan-net
という名前のセカンダリーネットワークを設定します。
{ "cniVersion": "0.3.1", "name": "macvlan-net", "type": "macvlan", "master": "eth1", "linkInContainer": false, "mode": "bridge", "ipam": { "type": "dhcp" } }
{
"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 プラグインの設定パラメーターを説明しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNI 仕様のバージョン。値 |
|
|
CNO 設定に以前に指定した |
|
|
設定する CNI プラグインの名前: |
|
| オプション: インターフェイスの指定された MAC アドレスを要求します。 |
|
| オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。 |
|
| オプション: タップデバイスに関連付ける SELinux コンテキスト。 注記
OpenShift Container Platform には、値 |
|
|
オプション: マルチキューを有効にするには |
|
| オプション: タップデバイスを所有するユーザー。 |
|
| オプション: タップデバイスを所有するグループ。 |
|
| オプション: タップデバイスを既存のブリッジのポートとして設定します。 |
17.3.2.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" }
{
"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
) がインストールされている。
手順
次の詳細を含む、
setsebool-container-use-devices.yaml
などの名前の新しい YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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
次のコマンドを実行して、新しい
MachineConfig
オブジェクトを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f setsebool-container-use-devices.yaml
$ oc apply -f setsebool-container-use-devices.yaml
注記MachineConfig
オブジェクトに変更を適用すると、変更が適用された後、影響を受けるすべてのノードが正常に再起動します。この更新が適用されるまでに、時間がかかる場合があります。次のコマンドを実行して、変更が適用されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get machineconfigpools
$ oc get machineconfigpools
予想される出力
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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 プラグインの設定パラメーターを示しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
設定する CNI プラグインの名前: |
|
|
オプション: 既存ルートをフラッシュするには |
|
|
オプション: デフォルトルート、つまりゲートウェイルートをフラッシュするには |
|
| オプション: コンテナー namespace から削除するルートのリストを指定します。 |
|
|
オプション: コンテナー namespace に追加するルートのリストを指定します。各ルートは、 |
|
|
オプション: check コマンドをスキップするには、これを |
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
の新しいルートを追加することで、ルーティングルールが変更されます。
{ "cniVersion": "0.3.0", "name": "mymacvlan", "plugins": [ { "type": "macvlan", "master": "eth1", "mode": "bridge", "ipam": { "type": "host-local", "subnet": "192.168.1.0/24" } }, { "type": "route-override", "flushroutes": true, "delroutes": [ { "dst": "192.168.0.0/24" } ], "addroutes": [ { "dst": "192.168.0.0/24", "gw": "10.1.254.254" } ] } ] }
{
"cniVersion": "0.3.0",
"name": "mymacvlan",
"plugins": [
{
"type": "macvlan",
"master": "eth1",
"mode": "bridge",
"ipam": {
"type": "host-local",
"subnet": "192.168.1.0/24"
}
},
{
"type": "route-override",
"flushroutes": true,
"delroutes": [
{
"dst": "192.168.0.0/24"
}
],
"addroutes": [
{
"dst": "192.168.0.0/24",
"gw": "10.1.254.254"
}
]
}
]
}
関連情報
- ノード上で SELinux ブール値を有効にする方法の詳細は、SELinux ブール値の設定 を参照してください。
17.3.3. Pod をセカンダリーネットワークにアタッチする
クラスターユーザーとして、Pod をセカンダリーネットワークにアタッチできます。
17.3.3.1. セカンダリーネットワークに Pod を追加する
セカンダリーネットワークに Pod を追加できます。Pod は、デフォルトネットワークで通常のクラスター関連のネットワークトラフィックを継続的に送信します。
Pod が作成されると、セカンダリーネットワークが Pod にアタッチされます。ただし、Pod がすでに存在する場合は、セカンダリーネットワークをその Pod にアタッチすることはできません。
Pod はセカンダリーネットワークと同じ namespace に存在する必要があります。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - クラスターにログインする。
手順
アノテーションを
Pod
オブジェクトに追加します。以下のアノテーション形式のいずれかのみを使用できます。カスタマイズせずにセカンダリーネットワークをアタッチするには、次の形式でアノテーションを追加します。
<network>
が、Pod に関連付けるセカンダリーネットワークの名前に置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]
metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]
1 - 1
- 複数のセカンダリーネットワークを指定するには、各ネットワークをコンマで区切ります。コンマの間にはスペースを入れないでください。同じセカンダリーネットワークを複数回指定した場合、Pod は複数のネットワークインターフェイスをそのネットワークにアタッチします。
カスタマイズしてセカンダリーネットワークをアタッチするには、次の形式でアノテーションを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>", "namespace": "<namespace>", "default-route": ["<default-route>"] } ]
metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>",
1 "namespace": "<namespace>",
2 "default-route": ["<default-route>"]
3 } ]
Pod を作成するには、以下のコマンドを入力します。
<name>
を Pod の名前に置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc create -f <name>.yaml
$ oc create -f <name>.yaml
オプション: アノテーションが
Pod
CR に存在することを確認するには、<name>
を Pod の名前に置き換えて、以下のコマンドを入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get pod <name> -o yaml
$ oc get pod <name> -o yaml
次の例では、
example-pod
Pod がnet1
セカンダリーネットワークにアタッチされています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get pod example-pod -o yaml
$ 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 をセカンダリーネットワークに追加するには、以下の手順を実行します。
Pod
リソース定義を編集します。既存のPod
リソースを編集する場合は、以下のコマンドを実行してデフォルトエディターでその定義を編集します。<name>
を、編集するPod
リソースの名前に置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc edit pod <name>
$ oc edit pod <name>
Pod
リソース定義で、k8s.v1.cni.cncf.io/networks
パラメーターを Pod のmetadata
マッピングに追加します。k8s.v1.cni.cncf.io/networks
は、追加のプロパティーを指定するだけでなく、NetworkAttachmentDefinition
カスタムリソース (CR) 名を参照するオブジェクトリストの JSON 文字列を受け入れます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow metadata: annotations: k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]'
metadata: annotations: k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]'
1 - 1
<network>
を、以下の例にあるように JSON オブジェクトに置き換えます。一重引用符が必要です。
以下の例では、アノテーションで
default-route
パラメーターを使用して、デフォルトルートを持つネットワーク割り当てを指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 kind: Pod metadata: name: example-pod annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "net1" }, { "name": "net2", "default-route": ["192.0.2.1"] }]' spec: containers: - name: example-pod command: ["/bin/bash", "-c", "sleep 2000000000000"] image: centos/tools
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
デフォルトのルートにより、他のルートに指定されていないトラフィックがゲートウェイにルーティングされます。
OpenShift Container Platform のデフォルトのネットワークインターフェイス以外のインターフェイスへのデフォルトのルートを設定すると、Pod 間のトラフィックに予想されるトラフィックが別のインターフェイスでルーティングされる可能性があります。
Pod のルーティングプロパティーを確認する場合、oc
コマンドを Pod 内で ip
コマンドを実行するために使用できます。
oc exec -it <pod_name> -- ip route
$ oc exec -it <pod_name> -- ip route
また、Pod の k8s.v1.cni.cncf.io/network-status
を参照して、JSON 形式の一覧のオブジェクトで default-route
キーの有無を確認し、デフォルトルートが割り当てられているセカンダリーネットワークを確認することができます。
Pod に静的 IP アドレスまたは MAC アドレスを設定するには、JSON 形式のアノテーションを使用できます。これには、この機能をとくに許可するネットワークを作成する必要があります。これは、CNO の rawCNIConfig で指定できます。
以下のコマンドを実行して CNO CR を編集します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io cluster
以下の YAML は、CNO の設定パラメーターを説明しています。
Cluster Network Operator YAML の設定
name: <name> namespace: <namespace> rawCNIConfig: '{ ... }' type: Raw
name: <name>
namespace: <namespace>
rawCNIConfig: '{
...
}'
type: Raw
以下のオブジェクトは、macvlan CNI プラグインを使用して静的 MAC アドレスと IP アドレスを使用するための設定パラメーターを説明しています。
静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト
{ "cniVersion": "0.3.1", "name": "<name>", "plugins": [{ "type": "macvlan", "capabilities": { "ips": true }, "master": "eth0", "mode": "bridge", "ipam": { "type": "static" } }, { "capabilities": { "mac": true }, "type": "tuning" }] }
{
"cniVersion": "0.3.1",
"name": "<name>",
"plugins": [{
"type": "macvlan",
"capabilities": { "ips": true },
"master": "eth0",
"mode": "bridge",
"ipam": {
"type": "static"
}
}, {
"capabilities": { "mac": true },
"type": "tuning"
}]
}
- 1
- 作成するセカンダリーネットワークアタッチメントの名前を指定します。名前は指定された
namespace
内で一意である必要があります。 - 2
- CNI プラグイン設定の配列を指定します。1 つ目のオブジェクトは、macvlan プラグイン設定を指定し、2 つ目のオブジェクトはチューニングプラグイン設定を指定します。
- 3
- CNI プラグインのランタイム設定機能の静的 IP 機能を有効にするために要求が実行されるように指定します。
- 4
- macvlan プラグインが使用するインターフェイスを指定します。
- 5
- CNI プラグインの静的 MAC アドレス機能を有効にするために要求が実行されるように指定します。
上記のネットワーク割り当ては、特定の Pod に割り当てられる静的 IP アドレスと MAC アドレスを指定するキーと共に、JSON 形式のアノテーションで参照できます。
以下を使用して Pod を編集します。
oc edit pod <name>
$ oc edit pod <name>
静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト
apiVersion: v1 kind: Pod metadata: name: example-pod annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "<name>", "ips": [ "192.0.2.205/24" ], "mac": "CA:FE:C0:FF:EE:00" } ]'
apiVersion: v1
kind: Pod
metadata:
name: example-pod
annotations:
k8s.v1.cni.cncf.io/networks: '[
{
"name": "<name>",
"ips": [ "192.0.2.205/24" ],
"mac": "CA:FE:C0:FF:EE:00"
}
]'
静的 IP アドレスおよび MAC アドレスを同時に使用することはできません。これらは個別に使用することも、一緒に使用することもできます。
セカンダリーネットワークを持つ Pod の IP アドレスと MAC プロパティーを検証するには、oc
コマンドを使用して Pod 内で ip コマンドを実行します。
oc exec -it <pod_name> -- ip a
$ 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 Copied! Toggle word wrap Toggle overflow apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy
-
CLI を使用してマルチネットワークポリシーと対話する場合は、
multi-networkpolicy
リソース名を使用する必要があります。たとえば、oc get multi-networkpolicy <name>
コマンドを使用してマルチネットワークポリシーオブジェクトを表示できます。ここで、<name>
はマルチネットワークポリシーの名前になります。 macvlan または SR-IOV 追加ネットワークを定義するネットワーク割り当て定義の名前でアノテーションを指定する必要があります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: annotations: k8s.v1.cni.cncf.io/policy-for: <network_name>
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
権限を持つユーザーとしてクラスターにログインする。
手順
以下の YAML で
multinetwork-enable-patch.yaml
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: useMultiNetworkPolicy: true
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: useMultiNetworkPolicy: true
マルチネットワークポリシーを有効にするようにクラスターを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml
$ oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow network.operator.openshift.io/cluster patched
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 に次のルールのセットをデプロイします。
マルチネットワークポリシーのカスタムルール
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 -p icmpv6 --icmpv6-type neighbor-advertisement -j ACCEPT # accept RA/RS -p icmpv6 --icmpv6-type router-solicitation -j ACCEPT -p icmpv6 --icmpv6-type router-advertisement -j ACCEPT
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
-p icmpv6 --icmpv6-type neighbor-advertisement -j ACCEPT
# accept RA/RS
-p icmpv6 --icmpv6-type router-solicitation -j ACCEPT
-p icmpv6 --icmpv6-type router-advertisement -j ACCEPT
- 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 で作業していること。
手順
ポリシールールを作成します。
<policy_name>.yaml
ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow touch <policy_name>.yaml
$ touch <policy_name>.yaml
ここでは、以下のようになります。
<policy_name>
- マルチネットワークポリシーのファイル名を指定します。
作成したばかりのファイルで、以下の例のようなマルチネットワークポリシーを定義します。
すべての namespace のすべての Pod から Ingress を拒否します。
これは基本的なポリシーであり、他のネットワークポリシーの設定によって許可されたクロス Pod トラフィック以外のすべてのクロス Pod ネットワーキングをブロックします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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: []
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 Copied! Toggle word wrap Toggle overflow 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: {}
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 Copied! Toggle word wrap Toggle overflow 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
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=bookstore
とrole=api
の両方のラベルを持つすべての Pod に、app=bookstore
というラベルを持つ Pod のみがアクセスできるようになります。この例では、アプリケーションは、ラベルapp=bookstore
およびrole=api
でマークされた REST API サーバーである可能性があります。この例では、次のユースケースに対応します。
- サービスへのトラフィックを、それを使用する必要がある他のマイクロサービスのみに制限します。
データベースへの接続を制限して、それを使用するアプリケーションのみを許可します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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>
- ネットワーク割り当て定義の名前を指定します。
マルチネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f <policy_name>.yaml -n <namespace>
$ oc apply -f <policy_name>.yaml -n <namespace>
ここでは、以下のようになります。
<policy_name>
- マルチネットワークポリシーのファイル名を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created
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 で作業している。
手順
オプション: namespace のマルチネットワークポリシーオブジェクトをリスト表示するには、以下のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get multi-networkpolicy
$ oc get multi-networkpolicy
ここでは、以下のようになります。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
マルチネットワークポリシーオブジェクトを編集します。
マルチネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -n <namespace> -f <policy_file>.yaml
$ oc apply -n <namespace> -f <policy_file>.yaml
ここでは、以下のようになります。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
<policy_file>
- ネットワークポリシーを含むファイルの名前を指定します。
マルチネットワークポリシーオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc edit multi-networkpolicy <policy_name> -n <namespace>
$ oc edit multi-networkpolicy <policy_name> -n <namespace>
ここでは、以下のようになります。
<policy_name>
- ネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
マルチネットワークポリシーオブジェクトが更新されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe multi-networkpolicy <policy_name> -n <namespace>
$ 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 Copied! Toggle word wrap Toggle overflow oc get multi-networkpolicy
$ oc get multi-networkpolicy
オプション: 特定のマルチネットワークポリシーを検査するには、以下のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe multi-networkpolicy <policy_name> -n <namespace>
$ 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 Copied! Toggle word wrap Toggle overflow oc delete multi-networkpolicy <policy_name> -n <namespace>
$ oc delete multi-networkpolicy <policy_name> -n <namespace>
ここでは、以下のようになります。
<policy_name>
- マルチネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted
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 で作業していること。
手順
すべての namespace におけるすべての Pod からの Ingress を拒否する
deny-by-default
ポリシーを定義する次の YAML を作成します。YAML をdeny-by-default.yaml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: deny-by-default namespace: my-project annotations: k8s.v1.cni.cncf.io/policy-for: <namespace_name>/<network_name> spec: podSelector: {} policyTypes: - Ingress ingress: []
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 へのすべての着信トラフィックがドロップされます。
次のコマンドを入力して、ポリシーを適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f deny-by-default.yaml
$ oc apply -f deny-by-default.yaml
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created
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 で作業していること。
手順
パブリックインターネットからのトラフィックが直接、またはロードバランサーを使用して Pod にアクセスできるようにするポリシーを作成します。YAML を
web-allow-external.yaml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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: - {}
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: - {}
次のコマンドを入力して、ポリシーを適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f web-allow-external.yaml
$ oc apply -f web-allow-external.yaml
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow multinetworkpolicy.k8s.cni.cncf.io/web-allow-external created
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 で作業していること。
手順
すべての namespace のすべての Pod から特定のアプリケーションへのトラフィックを許可するポリシーを作成します。YAML を
web-allow-all-namespaces.yaml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 policyTypes: - Ingress ingress: - from: - namespaceSelector: {}
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 注記デフォルトでは、
namespaceSelector
の指定を省略した場合、namespace は選択されません。つまり、ポリシーは、ネットワークポリシーがデプロイされている namespace からのトラフィックのみを許可します。次のコマンドを入力して、ポリシーを適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f web-allow-all-namespaces.yaml
$ oc apply -f web-allow-all-namespaces.yaml
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow multinetworkpolicy.k8s.cni.cncf.io/web-allow-all-namespaces created
multinetworkpolicy.k8s.cni.cncf.io/web-allow-all-namespaces created
検証
次のコマンドを入力して、
default
namespace で Web サービスを開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
次のコマンドを実行して、
alpine
イメージをsecondary
namespace にデプロイし、シェルを開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.default
予想される出力
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <!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>
<!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 で作業していること。
手順
ラベルが
purpose=production
の特定の namespace 内にあるすべての Pod からのトラフィックを許可するポリシーを作成します。YAML をweb-allow-prod.yaml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: purpose: production
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 次のコマンドを入力して、ポリシーを適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f web-allow-prod.yaml
$ oc apply -f web-allow-prod.yaml
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow multinetworkpolicy.k8s.cni.cncf.io/web-allow-prod created
multinetworkpolicy.k8s.cni.cncf.io/web-allow-prod created
検証
次のコマンドを入力して、
default
namespace で Web サービスを開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
次のコマンドを実行して、
prod
namespace を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc create namespace prod
$ oc create namespace prod
次のコマンドを実行して、
prod
namespace にラベルを付けます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc label namespace/prod purpose=production
$ oc label namespace/prod purpose=production
次のコマンドを実行して、
dev
namespace を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc create namespace dev
$ oc create namespace dev
次のコマンドを実行して、
dev
namespace にラベルを付けます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc label namespace/dev purpose=testing
$ oc label namespace/dev purpose=testing
次のコマンドを実行して、
alpine
イメージをdev
namespace にデプロイし、シェルを開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
シェルで次のコマンドを実行し、リクエストがブロックされていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.default
予想される出力
Copy to Clipboard Copied! Toggle word wrap Toggle overflow wget: download timed out
wget: download timed out
次のコマンドを実行して、
alpine
イメージをprod
namespace にデプロイし、シェルを開始します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.default
予想される出力
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <!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>
<!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 Copied! Toggle word wrap Toggle overflow oc delete pod <name> -n <namespace>
$ oc delete pod <name> -n <namespace>
-
<name>
は Pod の名前です。 -
<namespace>
は Pod が含まれる namespace です。
-
17.3.6. セカンダリーネットワークの編集
クラスター管理者は、既存のセカンダリーネットワークの設定を変更できます。
17.3.6.1. セカンダリーネットワークアタッチメントの定義を変更する
クラスター管理者は、既存のセカンダリーネットワークに変更を加えることができます。セカンダリーネットワークにアタッチされている既存の Pod は更新されません。
前提条件
- クラスターのセカンダリーネットワークを設定した。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
クラスターのセカンダリーネットワークを編集するには、次の手順を実行します。
以下のコマンドを実行し、デフォルトのテキストエディターで Cluster Network Operator (CNO) CR を編集します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io cluster
-
additionalNetworks
コレクションで、セカンダリーネットワークを変更して更新します。 - 変更を保存し、テキストエディターを終了して、変更をコミットします。
オプション: 以下のコマンドを実行して、CNO が
NetworkAttachmentDefinition
オブジェクトを更新していることを確認します。<network-name>
は、表示するセカンダリーネットワークの名前に置き換えます。CNO がNetworkAttachmentDefinition
オブジェクトを更新して変更内容が反映されるまでに遅延が生じる可能性があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get network-attachment-definitions <network-name> -o yaml
$ oc get network-attachment-definitions <network-name> -o yaml
たとえば、以下のコンソールの出力は
net1
という名前のNetworkAttachmentDefinition
オブジェクトを表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'
$ 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 アドレスの割り当ての設定を説明しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
IPAM のアドレスタイプ。値 |
|
| 仮想インターフェイスに割り当てる IP アドレスを指定するオブジェクトの配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。 |
|
| Pod 内で設定するルートを指定するオブジェクトの配列です。 |
|
| オプション: DNS の設定を指定するオブジェクトの配列です。 |
addresses
の配列には、以下のフィールドのあるオブジェクトが必要です。
フィールド | 型 | 説明 |
---|---|---|
|
|
指定する IP アドレスおよびネットワーク接頭辞。たとえば、 |
|
| Egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。 |
フィールド | 型 | 説明 |
---|---|---|
|
|
CIDR 形式の IP アドレス範囲 ( |
|
| ネットワークトラフィックがルーティングされるゲートウェイ。 |
フィールド | 型 | 説明 |
---|---|---|
|
| DNS クエリーの送信先となる 1 つ以上の IP アドレスの配列。 |
|
|
ホスト名に追加するデフォルトのドメイン。たとえば、ドメインが |
|
|
DNS ルックアップのクエリー時に非修飾ホスト名に追加されるドメイン名の配列 (例: |
静的 IP アドレス割り当ての設定例
{ "ipam": { "type": "static", "addresses": [ { "address": "191.168.1.7/24" } ] } }
{
"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 ネットワーク割り当ての定義例
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" } } # ...
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 アドレス割り当ての設定パラメーターを示しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
IPAM のアドレスタイプ。値 |
以下の JSON の例は、DHCP を使用した動的 IP アドレスの割り当ての設定を説明しています。
動的 IP アドレス (DHCP) 割り当ての設定例
{ "ipam": { "type": "dhcp" } }
{
"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 アドレス割り当ての設定オブジェクトを説明しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
IPAM のアドレスタイプ。値 |
|
| IP アドレスと範囲を CIDR 表記。IP アドレスは、この範囲内のアドレスから割り当てられます。 |
|
| オプション: CIDR 表記の IP アドレスと範囲 (0 個以上) のリスト。除外されたアドレス範囲内の IP アドレスは割り当てられません。 |
|
| オプション: 同じ範囲の IP アドレスを共有する場合でも、Pod の各グループまたはドメインが独自の IP アドレスセットを取得するようにします。このフィールドを設定することは、特にマルチテナント環境でネットワークを分離して整理しておく場合に重要です。 |
17.3.7.1.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" ] } }
{
"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
{ "ipam": { "type": "whereabouts", "range": "192.0.2.192/29", "network_name": "example_net_common", } }
{
"ipam": {
"type": "whereabouts",
"range": "192.0.2.192/29",
"network_name": "example_net_common",
}
}
- 1
- オプション: 設定されている場合、
NetworkAttachmentDefinition 2
のnetwork_name
と一致する必要があります。
NetworkAttachmentDefinition 2
{ "ipam": { "type": "whereabouts", "range": "192.0.2.192/24", "network_name": "example_net_common", } }
{
"ipam": {
"type": "whereabouts",
"range": "192.0.2.192/24",
"network_name": "example_net_common",
}
}
- 1
- オプション: 設定されている場合、
NetworkAttachmentDefinition 1
のnetwork_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
デーモンセットをデプロイするには、次の手順を使用します。
手順
以下のコマンドを実行して、
Network.operator.openshift.io
カスタムリソース (CR) を編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc edit network.operator.openshift.io cluster
$ oc edit network.operator.openshift.io cluster
この例で展開されている YAML の
additionalNetworks
セクションを、カスタムリソース (CR) のspec
定義内に含めます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 # ...
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 # ...
- ファイルを保存し、テキストエディターを編集します。
次のコマンドを実行して、
whereabouts-reconciler
デーモンセットが正常にデプロイされたことを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get all -n openshift-multus | grep whereabouts-reconciler
$ oc get all -n openshift-multus | grep whereabouts-reconciler
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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 が起動して実行されている。
手順
次のコマンドを実行して、IP リコンサイラー用の特定の cron 式を使用し、
openshift-multus
namespace にwhereabouts-config
という名前のConfigMap
オブジェクトを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc create configmap whereabouts-config -n openshift-multus --from-literal=reconciler_cron_expression="*/15 * * * *"
$ oc create configmap whereabouts-config -n openshift-multus --from-literal=reconciler_cron_expression="*/15 * * * *"
この cron 式は、IP リコンサイラーを 15 分ごとに実行するよう指定します。この式は固有の要件に基づいて調整してください。
注記whereabouts-reconciler
デーモンセットは、5 つのアスタリスクを含む cron 式パターンのみを使用できます。秒を表すために使用される 6 番目のアスタリスクは、現在サポートされていません。次のコマンドを実行して、
openshift-multus
namespace 内のwhereabouts-reconciler
デーモンセットおよび Pod に関連するリソースに関する情報を取得します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get all -n openshift-multus | grep whereabouts-reconciler
$ oc get all -n openshift-multus | grep whereabouts-reconciler
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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
次のコマンドを実行して、設定した間隔で
whereabouts-reconciler
Pod が IP リコンサイラーを実行していることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc -n openshift-multus logs whereabouts-reconciler-2p7hw
$ oc -n openshift-multus logs whereabouts-reconciler-2p7hw
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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 アドレスの割り当て
手順
-
type
をwhereabouts
に設定します。 以下の例のように、
ipRanges
を使用して IP アドレスを割り当てます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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"} ] } }
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"} ] } }
- ネットワークを Pod にアタッチします。詳細は、「セカンダリーネットワークへの Pod の追加」を参照してください。
- すべての IP アドレスが割り当てられていることを確認します。
以下のコマンドを実行して、IP アドレスがメタデータとして割り当てられることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc exec -it mypod -- ip a
$ 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 の作成

前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - SR-IOV Network Operator がインストールされている。
手順
次のコマンドを使用して、Pod をデプロイする専用のコンテナー namespace を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc new-project test-namespace
$ oc new-project test-namespace
SR-IOV ノードポリシーを作成します。
SriovNetworkNodePolicy
オブジェクトを作成してから、YAML をsriov-node-network-policy.yaml
ファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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" deviceID: "101b" rootDevices: ["00:05.0"] numVfs: 10 priority: 99 resourceName: sriovnic nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true"
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) 向けに特別に調整されています。以下のコマンドを実行して YAML を適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f sriov-node-network-policy.yaml
$ oc apply -f sriov-node-network-policy.yaml
注記ノードの再起動が必要なため、YAML の適用には時間がかかる場合があります。
SR-IOV ネットワークを作成します。
次の CR の例のように、追加のセカンダリー SR-IOV ネットワーク割り当て用の
SriovNetwork
カスタムリソース (CR) を作成します。YAML をsriov-network-attachment.yaml
ファイルとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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"
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"
以下のコマンドを実行して YAML を適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f sriov-network-attachment.yaml
$ oc apply -f sriov-network-attachment.yaml
VLAN セカンダリーネットワークを作成します。
以下の YAML の例を使用して、
vlan100-additional-network-configuration.yaml
という名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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", "mtu": 1500, "vlanId": 100, "linkInContainer": true, "ipam": {"type": "whereabouts", "ipRanges": [{"range": "1.1.1.0/24"}]} } ] }
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"}]} } ] }
以下のコマンドを実行して、YAML ファイルを適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f vlan100-additional-network-configuration.yaml
$ oc apply -f vlan100-additional-network-configuration.yaml
前に指定したネットワークを使用して、Pod 定義を作成します。
次の YAML の例を使用して、
pod-a.yaml
という名前のファイルを作成します。注記以下のマニフェストには 2 つのリソースが含まれています。
- セキュリティーラベルのある namespace
- 適切なネットワークアノテーションを含む Pod 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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" }, { "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"
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
として使用される名前。
以下のコマンドを実行して、YAML ファイルを適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f pod-a.yaml
$ oc apply -f pod-a.yaml
次のコマンドを実行して、
test-namespace
内のnginx-pod
に関する詳細情報を取得します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe pods nginx-pod -n test-namespace
$ oc describe pods nginx-pod -n test-namespace
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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 クラスターにログインしている。
手順
次のコマンドを入力して、Pod のデプロイ先となる専用のコンテナー namespace を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc new-project test-namespace
$ oc new-project test-namespace
次の YAML の例を使用して、
bridge-nad.yaml
という名前のブリッジNetworkAttachmentDefinition
カスタムリソース定義 (CRD) ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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"}] } }'
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"}] } }'
次のコマンドを実行して、
NetworkAttachmentDefinition
CRD を OpenShift Container Platform クラスターに適用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f bridge-nad.yaml
$ oc apply -f bridge-nad.yaml
次のコマンドを入力して、
NetworkAttachmentDefinition
CRD が正常に作成されたことを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get network-attachment-definitions
$ oc get network-attachment-definitions
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NAME AGE bridge-network 15s
NAME AGE bridge-network 15s
以下の YAML の例を使用して、IPVLAN セカンダリーネットワーク設定用に
ipvlan-additional-network-configuration.yaml
という名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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", "mode": "l3", "linkInContainer": true, "ipam": {"type": "whereabouts", "ipRanges": [{"range": "10.0.0.0/24"}]} }'
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"}]} }'
以下のコマンドを実行して、YAML ファイルを適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f ipvlan-additional-network-configuration.yaml
$ oc apply -f ipvlan-additional-network-configuration.yaml
次のコマンドを実行して、
NetworkAttachmentDefinition
CRD が正常に作成されたことを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get network-attachment-definitions
$ oc get network-attachment-definitions
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NAME AGE bridge-network 87s ipvlan-net 9s
NAME AGE bridge-network 87s ipvlan-net 9s
以下の YAML の例を使用して、Pod 定義用に
pod-a.yaml
という名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 kind: Pod metadata: name: pod-a namespace: test-namespace annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "bridge-network", "interface": "net1" }, { "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]
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
として使用する名前を指定します。
以下のコマンドを実行して、YAML ファイルを適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f pod-a.yaml
$ oc apply -f pod-a.yaml
以下のコマンドを使用して、Pod が実行されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get pod -n test-namespace
$ oc get pod -n test-namespace
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NAME READY STATUS RESTARTS AGE pod-a 1/1 Running 0 2m36s
NAME READY STATUS RESTARTS AGE pod-a 1/1 Running 0 2m36s
次のコマンドを実行して、
test-namespace
内のpod-a
リソースに関するネットワークインターフェイス情報を表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc exec -n test-namespace pod-a -- ip a
$ oc exec -n test-namespace pod-a -- ip a
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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
権限を持つユーザーとしてログインしている。
手順
クラスターからセカンダリーネットワークを削除するには、次の手順を実行します。
以下のコマンドを実行して、デフォルトのテキストエディターで Cluster Network Operator (CNO) を編集します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io cluster
削除するセカンダリーネットワークの
additionalNetworks
コレクションから CNO が作成した設定を削除して、CR を変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: additionalNetworks: []
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: additionalNetworks: []
1 - 1
additionalNetworks
コレクションのセカンダリーネットワークアタッチメントのみの設定マッピングを削除する場合、空のコレクションを指定する必要があります。
クラスターのネットワークからネットワークアタッチメント定義を削除するには、次のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete net-attach-def <name_of_NAD>
$ oc delete net-attach-def <name_of_NAD>
1 - 1
<name_of_NAD>
は、ネットワークアタッチメント定義の名前に置き換えます。
- 変更を保存し、テキストエディターを終了して、変更をコミットします。
オプション: 次のコマンドを実行して、セカンダリーネットワーク CR が削除されたことを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get network-attachment-definition --all-namespaces
$ oc get network-attachment-definition --all-namespaces