ここでは、IPアドレスの操作は役に立ちません。この場合の唯一の解決策は、必要なVLANにあるクラスターノード上の追加のインターフェイスの編成と、クラスター内で必要なプロジェクトからの追加のインターフェイスへのアクセスの編成です。そして、MultusCNIと呼ばれるプロジェクトがこれを支援することができます 。
Multus CNI
ご存知のように、デフォルトでは、KubernetesのPODには、それとのすべての対話が行われる1つのインターフェースがあります。Multusを使用すると、デフォルトのインターフェイスに加えて、PODで複数のインターフェイスを作成できます。実際、Multusはそれ自体がCNIプラグインであり、CNIプラグインが他のCNIプラグインへの呼び出しを制御します。このため、MultusはCNIメタプラグインと呼ばれます。Multusが行うことは、DemystifingMultusの記事の写真によく示されてい ます。
もちろん、追加のインターフェースの数は複数にすることができます。
OpenShiftでのMultusCNIの構成
それでは、ブースで専用VLANへのアクセスの問題を解決してみましょう。デフォルトでは、すべてのクラスターノードにOpenShift VLAN（IP：192.168.111 / 24）にある1つのインターフェイスが割り当てられます。multes-testプロジェクトからVLANRestrictedにある192.168.112 / 24ネットワークのリソースへのアクセスを整理したいと思います。VLAN制限付きとVLANOpenShiftは相互にルーティングされません。
まず、VLAN Restrictedからいくつかのノード（この場合、これらはNode1とNode2）にインターフェイスを追加し、これらのノードにnode-role.kubernetes.io/multus-node='yes 'ラベルを付けます 。制限付きVLANのリソースは、multus-nodeラベルの付いたノードから利用できます。multus-testプロジェクトを作成しましょう：
[ocp@shift-is01 macvlan]$ oc new-project multus-test
Multus CNIサポートはOpenShiftに長い間存在しており、個別に追加する必要はありません。Multus構成管理は、CRDnetworks.operator.openshift.ioのCRを介して行われ ます。新しいインターフェイスのCNIプラグイン構成を追加して、このリソースを編集する必要があります
。oceditnetworks.operator.openshift.ioクラスター
spec: additionalNetworks: - name : net1 namespace: multus-test type: Raw rawCNIConfig: |- { "cniVersion": "0.3.1", "type": "ipvlan", "mode": "l2", "master": "ens224", "ipam": { "type": "static" } }
この瞬間はデコードが必要です。この構成で何を定義しましたか？
- PODの場合、「net1」という名前のインターフェイスがmultus-testプロジェクトに追加されます
- このインターフェイスの構成は、CNIプラグイン「ipvlan」を介して決定されます。
- CNIプラグインipvlanはL2モードで構成されています。
- ens224ノードの物理インターフェイスは、net1のメインインターフェイスとして使用されます。
- 最後に、IPAM静的プラグインを使用してIPアドレス指定を管理します。
CNIプラグインの選択
追加のインターフェースについては、使用するCNIプラグインを選択する必要があります。可能なCNIプラグインのリストは、Webサイト www.cni.devにあります。この例では、ipvlanプラグインを使用して います。実際、これは、コンテナがホストの外部ネットワークインターフェイスを介して通信できるようにする最も単純なブリッジです。この場合、すべての発信接続は独自のIPアドレスを使用しますが、外部ネットワークインターフェイスのMACアドレスを持ちます。サイトhicu.beの写真は、 ipvlanプラグインをよく示しています。
生産的な環境では、macvlanプラグインが選択されることが多く 、発信接続には一意のMACアドレスがあるという点でipvlanとは異なります。ただし、この場合、ネットワーク機器が1つのポートから異なるMACアドレスを持つパケットを送信できるように、ネットワークインフラストラクチャを準備する必要があることがよくあります。
IPAMプラグインの選択
ネットワークインターフェイスの編成に加えて、新しいインターフェイスのIPアドレスを発行するためのルールを定義する必要があります。これは、IPアドレス管理（またはIPAM）機能を実装するCNIプラグインによっても処理されます。可能なIPAMプラグインのリストは、www.cni.devにもあります 。この例では、PODに固定アドレスを割り当てる最も単純な静的IPAMプラグインを使用しました。
そのようなPODが多数ある場合、静的IPAMは不便になります。ここでの適切な選択は、dhcpプラグイン（外部DHCPサーバーへの要求を介してPODのIPアドレスを割り当てる）を使用するか、居場所情報プラグインを使用すること です。
これらのIPAMプラグインのサポートは、デフォルトで OpenShift、個別にインストールする必要はありません。
制限されたVLANアクセス
Multus構成を定義すると、ネットワークアタッチメント定義と呼ばれるリソースがクラスターに表示されます。これは、現在のMultus構成を反映しています。
ネットワークアタッチメント定義
[ocp@shift-is01 macvlan]$ oc get network-attachment-definitions --all-namespaces NAMESPACE NAME AGE multus-test net1 3m4s [ocp@shift-is01 macvlan]$ oc get network-attachment-definitions.k8s.cni.cncf.io -n multus-test net1 -o yaml apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: creationTimestamp: "2020-11-02T16:44:46Z" generation: 1 managedFields: - apiVersion: k8s.cni.cncf.io/v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:ownerReferences: .: {} k:{"uid":"01a4f46a-fc3c-495f-b196-b39352421e2a"}: .: {} f:apiVersion: {} f:blockOwnerDeletion: {} f:controller: {} f:kind: {} f:name: {} f:uid: {} f:spec: .: {} f:config: {} manager: cluster-network-operator operation: Update time: "2020-11-02T16:44:46Z" name: net1 namespace: multus-test ownerReferences: - apiVersion: operator.openshift.io/v1 blockOwnerDeletion: true controller: true kind: Network name: cluster uid: 01a4f46a-fc3c-495f-b196-b39352421e2a resourceVersion: "25898949" selfLink: /apis/k8s.cni.cncf.io/v1/namespaces/multus-test/network-attachment-definitions/net1 uid: 7a7d718b-82c5-46fe-8f72-8fd4299508ec spec: config: |- { "cniVersion": "0.3.1", "type": "ipvlan", "mode": "l2", "master": "ens224", "ipam": { "type": "static" } }
制限されたVLANにアクセスできる追加のインターフェイスを持つテストPODを作成しましょう：
pod-ipvlan-static.yaml
[ocp@shift-is01 ipvlan]$ cat ./pod-ipvlan-static.yaml apiVersion: v1 kind: Pod metadata: namespace: multus-test name: test-multus-pod labels: app: test-multus-pod annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "net1", "ips": ["192.168.112.250/24"] } ]' spec: nodeSelector: node-role.kubernetes.io/multus-node: yes containers: - name: test-multus-pod image: centos/tools command: ["/bin/bash", "-c", "sleep 9000000"]
作成されたPODに移動して、そのネットワーク構成を表示し、制限されたVLAN（192.168.112.0/24ネットワーク上）のアドレスの可用性を確認しましょう。
ocp@shift-is01 ipvlan]$ oc rsh test-multus-pod sh-4.2# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if2142: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default link/ether 0a:58:0a:fe:04:a0 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.254.4.160/24 brd 10.254.4.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::bc4b:abff:fe0b:91f8/64 scope link valid_lft forever preferred_lft forever 4: net1@if826: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default link/ether 00:50:56:96:f3:02 brd ff:ff:ff:ff:ff:ff inet 192.168.112.250/24 brd 192.168.112.255 scope global net1 valid_lft forever preferred_lft forever inet6 fe80::50:5600:196:f302/64 scope link valid_lft forever preferred_lft forever sh-4.2# ping 192.168.112.1 -c 3 PING 192.168.112.1 (192.168.112.1) 56(84) bytes of data. 64 bytes from 192.168.112.1: icmp_seq=1 ttl=64 time=0.179 ms 64 bytes from 192.168.112.1: icmp_seq=2 ttl=64 time=0.230 ms 64 bytes from 192.168.112.1: icmp_seq=3 ttl=64 time=0.223 ms --- 192.168.112.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2041ms rtt min/avg/max/mdev = 0.179/0.210/0.230/0.028 ms
「ipa」コマンドの出力からわかるように、PODは追加のnet1 @ if826ネットワークインターフェイスとマニフェストで指定したIPアドレスを受け取りました。追加のインターフェースは制限付きVLANのイーサネットアダプターを介して機能するため、このPODから、必要なネットワークセグメントにアクセスできました。
著者：JetInfosystemsのDevOpsソリューション部門の責任者であるSergeyArtemovが
テレグラムチャネル@DevSecOpsTalksに参加してください ！