※本記事は OpenShift Virtualization アドベントカレンダーの 9日目の記事です。
こんにちは、OpenShift のプリセールスを担当している山川です。OpenShift Virtualization が日本で普及することを切実に願い続けています。 OpenShift Virtualization の導入を検討いただく際、最初に突き当たる壁の一つがネットワークの設計です。
GUI も有用なのですが、今回は慣れると設定が楽で、かつより柔軟な設定が可能な Yaml を利用して設定してみたいと思います。
OpenShift をインストールしたてのクラスターには、Pod Network、Service Network、Machine Networkといった OpenShift 内部にデプロイされたアプリケーションを外部のネットワークへ簡単に公開することをサポートするネットワークが存在しています。 この方法を用いる場合、OpenShift 内部で IP アドレス変換が発生します。
ただし、VMware 等のハイパーバイザーを利用してきたユーザーを移行しようとすると、ほとんどのワークロードにおいて基盤側での強制的な IP アドレス変換は好まれません。
そこで、本ブログでは、OpenShift 内部と外部をタグ VLAN により L2 ネットワークで接続する方法を見ていきたいと思います。
OpenShift と VLAN ネットワークの接続
最初に結論を申し上げると、Secondary network interface を用いることで、OpenShift Virtualization 上にデプロイされた VM を外部の L2 ネットワークと通信させることが可能となります。 最初から存在するのが下記の図の青で描かれたネットワークです。また、今回注目したいのが緑で描かれた Secondary network です。 Secondary network はデフォルトネットワークとは異なる IP アドレスレンジを用意いただくことが必要です。
Secondary network interface の種類
OpenShift 4.20 の公式ドキュメントによると、Secondary network interface には「OVN-Kubernetes セカンダリーネットワークへの仮想マシンの接続」「仮想マシンの SR-IOV ネットワークへの接続」「Linux ブリッジネットワークへの仮想マシンの接続」の 3 つの方法が解説されており、さらに「OVN-Kubernetes セカンダリーネットワークへの仮想マシンの接続」には layer 2 トポロジーと localnet トポロジーが記載されています。
第10章 ネットワーク | Virtualization | OpenShift Container Platform | 4.20 | Red Hat Documentation
4 つの方式の特徴を見てみましょう。
OVN-Kubernetes layer 2 Network
Geneve (Generic Network Virtualization Encapsulation) プロトコルを使用して、OpenShift のノード間にオーバーレイネットワークを作成します。追加の物理ネットワークを設定することなく、OpenShift 内で同一サブネットによる接続が可能になります。OpenShift 外部のクライアントやアプリケーションとの通信では利用しません。また、後述の 3 つとは異なり、必ず OpenShift をインストールする時に設定されるデフォルトの物理 NIC を経由します。
OVN-Kubernetes localnet Network
OVN-Kubernetes 管理下の元、OpenShift のノード間だけではなく、外部の L2 ネットワークとの通信も可能にします。利用する場合、内部で利用される Open vSwitch (OVS) を利用するための追加設定が必要です。
SR-IOV Network
高帯域幅または低レイテンシーを必要とする仮想ネットワークアプライアンスや GPU アプリケーション向けに Single Root I/O Virtualization (SR-IOV) を用いて外部の L2 ネットワークとの通信を可能にします。利用するには、SR-IOV が利用可能なハードウェアを用意する必要があります。
Linux Bridge Network
Linux カーネル標準のブリッジ機能を使用して、OpenShift 上のアプリケーションを OpenShift 外部の L2 ネットワークと通信する際に利用します。
通常の用途であれば、OpenShift 外部の L2 ネットワークと直接通信する際には OVN-Kubernetes localnet Network、Linux Bridge Network、SR-IOV Network のいずれかを利用可能です。 仮想ネットワークアプライアンス等、ネットワークのパフォーマンスを意識する必要がある場合は SR-IOV Network の利用も検討しますが、今回は 用途が限定的な SR-IOV Network は対象外とします。
OVN-Kubernetes localnet / Linux Bridge どちらを使う？
OpenShift 4.20の公式ドキュメントには、「OVN-Kubernetes の localnet トポロジーが推奨される」、と明記されています。OVN-Kubernetes は、OpenShift のデフォルトのネットワークでも使われており今後の拡張も楽しみな技術です。 ただし、サポートされる機能には差があるので、実装されている機能を比較してみましょう。
OpenShift 4.20 のドキュメントには、2 つの方式の比較表が存在しています。
第10章 ネットワーク | Virtualization | OpenShift Container Platform | 4.20 | Red Hat Documentation
OVN-Kubernetes localnet と Linux Bridge Network の比較表を見ると、大きな違いは MultiNetworkPolicy の利用可否 (表のネットワークポリシーの利用可否に該当)、仮想アプライアンス等を利用する際に Tagged Packet を VM まで通すかどうか (表のレイヤー 2 トランクアクセスの利用可否に該当) です。 MultiNetworkPolicy を使いたい場合は、OVN-Kubernetes localnet が必須、L2 トランクアクセスが必要な場合は Linux Bridge CNI を利用しましょう。
また、VMware の vSwitch でも設定が存在するプロミスキャスモードや偽装転送 (OpenShift だと Mac spoof filtering が該当) のオン/オフ設定があるかどうかについてよくご質問いただきますが、Linux Bridge CNI ではオン/オフ設定が可能です。 OVN-Kubernetes localnet に関しては、OpenShift 4.20 時点だと設定が固定値となっています。
OVN-Kubernetes を推したいところではあるのですが、サポートされる機能に差分があるため、特徴を理解した上で仮想化基盤のネットワーク要件に基づいて決めていくことを推奨します。
OpenShift Secondary network の設定方法
OpenShift Secondary network の設定には、NodeNetworkConfigulationPolicy (NNCP) と NetworkAttachmentDefinition (NAD) を用います。 NNCP は、Kubernetes NMState Operator を使用して、OpenShift クラスター内の物理ノード（ホスト）のネットワーク設定を宣言的に管理するための仕組みです。 OpenShift Virtualization ユーザーは NMState がほぼ必須となると言っても過言ではないため、早急に Kubernetes NMState Operator をインストールしてください。
5.3. インストール後のネットワーク設定 | Virtualization | OpenShift Container Platform | 4.20 | Red Hat Documentation
NodeNetworkConfigulationPolicy (NNCP)
NNCP を用いることで、物理 NIC の設定、物理 NIC 冗長化（OpenShift だと Bond の作成）、VLAN インターフェースの作成、Bridge の構成などが可能です。 Yaml ファイル (一部 GUI も可能) を書くだけで、全ノード（または特定の役割のノード）に対して一貫したネットワーク設定を自動適用できます。
なお、OpenShift ユーザーは、各ノードの Red Hat Enterprise Linux CoreOS に SSH でログインして nmcli / nmtui を用いてネットワーク設定をするのではなく、必ず NNCP を使いましょう。
NetworkAttachmentDefinition (NAD)
NAD は、Multus CNI (マルチネットワークを可能にするプラグイン) を利用して、VM に追加のネットワークインターフェースを定義するためのカスタムリソース (CRD) です。 「どのインターフェース (NNCP で作ったもの) を使って、どの IP 管理方式 (DHCP や Static など) で VM をネットワークで繋ぐか」という定義を保持します。 また、Open vSwitch (OVS) / Linux Bridge へ任意の設定をするためにも利用します。 VMware に慣れたユーザーには、よく Port Group の役割に近いリソースと説明しています。
それでは、NNCP や NAD を駆使して、Secondary network を設定しましょう。 今回は、OVS bridge や Linux Bridge で タグ VLAN ID を付与するための設定を入れます。 VMware だと 仮想スイッチタギング (VST：Virtual Switch Tagging) に相当します。
OVN-Kubernetes localnet Network の設定
インストールした OpenShift Virtualization に、OVN-Kubernetes localnet Network を設定します。
まずは、冗長化したいインタフェースの bond を作成するための yaml ファイルを用意し、oc apply -f
なお、NIC の冗長化が不要な場合は本手順をスキップ可能です。 本ブログでは、以後、下記のような設定例を掲載しますが、環境に合わせて適宜チューニングください。
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: bond1 # 任意
spec:
nodeSelector:
node-role.kubernetes.io/worker: '' # 全ての Worker Node に設定
desiredState:
interfaces:
- name: bond1
type: bond # type を bond と指定
state: up
ipv4:
enabled: false # インタフェースに IPv4 アドレスを指定しない
dhcp: false # インタフェースに外部の DHCP サーバーから IPv4 の取得を拒否
link-aggregation:
mode: 802.3ad # 802.3ad (LACP) mode の設定例
options:
miimon: '100' # リンク監視 (故障検知) の間隔を指定
port:
- ens2f0 # 冗長化したい物理 NIC の1 つ目を指定
- ens3f0 # 冗長化したい物理 NIC の2 つ目を指定
続いて、Open vSwitch (OVS) を作成するためのyamlファイルを用意し、oc apply -f
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: br-data
spec:
nodeSelector:
node-role.kubernetes.io/worker: '' # 全ての Worker Node に設定。設定する Worker Node を指定する場合は値を指定。
desiredState:
interfaces:
- name: br-data
type: ovs-bridge # type を ovs-bridge と指定
state: up
bridge:
allow-extra-patch-ports: true # kubernetes-nmstate pod がリスタートをした際のネットワーク切断を回避するための必須設定項目
options:
stp: false # ovs bridge 上で STP (ループ検知プロトコル) を無効
port:
- name: bond1 # ovs bridge (br-data) に紐付ける物理ポートやbond (ここでは bond1) を指定
ovn:
bridge-mappings: # ovs bridge と 後述の NAD を紐づけるために必須
- localnet: trunk-net # 後述の localnet の NAD と紐づけるために必須
bridge: br-data # localnet のNAD と紐付けるために自身の bridge 名を指定
state: present
最後に、NAD を作成するための yaml ファイルを用意し、oc apply -f
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
name: vlan20-net
namespace: default # 展開する必要があるnamespace。defaultにすると全namesapeから利用可能
spec:
config: |-
{
"cniVersion": "0.4.0",
"name": "vlan20-net",
"topology": "localnet", # localnet を指定
"netAttachDefName": "default/vlan20-net", # 自身の metadata.namespace と metadata.name の内容と一致
"physicalNetworkName": "trunk-net", # 前述の NNCP の bridge-mappings の値と一致
"type": "ovn-k8s-cni-overlay", # 固定
"disableContainerInterface": true, # 固定
"vlanID": 20 # ovs bridge で付与するタグ LAN ID を指定
}
これで、全ての設定が完了しました。 あとは、VirtualMachine カスタムリソースで作成した NAD を指定ください。
Linux Bridge Network の設定
インストールした OpenShift Virtualization に、Linux Bridge Network を設定します。
まずは、冗長化したいインタフェースの bond を作成するための yaml ファイルを用意し、oc apply -f
なお、NIC の冗長化が不要な場合は本手順をスキップ可能です。
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: bond2 # 任意
spec:
nodeSelector:
node-role.kubernetes.io/worker: '' # 全ての Worker Node に設定
desiredState:
interfaces:
- name: bond2
type: bond # type を bond と指定
state: up
ipv4:
enabled: false # インタフェースに IPv4 アドレスを指定しない
dhcp: false # インタフェースに外部の DHCP サーバーから IPv4 の取得を拒否
link-aggregation:
mode: 802.3ad # 802.3ad (LACP) mode の設定例
options:
miimon: '100' # リンク監視 (故障検知) の間隔を指定
port:
- ens4f0 # 冗長化したい物理 NIC の1 つ目を指定
- ens5f0 # 冗長化したい物理 NIC の2 つ目を指定
続いて、Linux Bridge を作成するための yaml ファイルを用意し、oc apply -f
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: br-data2
spec:
nodeSelector:
node-role.kubernetes.io/worker: '' # 全ての Worker Node に設定。設定する Worker Node を指定する場合は値を指定。
desiredState:
interfaces:
- name: br-data2
type: linux-bridge # type を linux-bridge と指定
state: up
bridge:
options:
stp:
enabled: false # linux bridge 上で STP (ループ検知プロトコル) を無効
port:
- name: bond2 # linux bridge (br-data2) に紐付ける物理ポートやbond (ここでは bond2) を指定
なお、Linux Bridge の場合は bridge-mappings は不要です。
最後に、NAD を作成するための yaml ファイルを用意し、oc apply -f
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
name: vlan30-net
namespace: default
spec:
config: |-
{
"cniVersion": "0.4.0",
"name": "vlan30-net",
"type": "bridge", # bridge を指定
"bridge": "br-data2", # 前述の NNCP の bridge 名の値と一致
"promiscMode": false, # Promiscuous Mode の設定。デフォルトは false。
"macspoofchk": false, # Mac spoof filtering の設定。デフォルトは false。
"disableContainerInterface": true, # 固定
"vlan": 30 # linux bridge で付与するタグ LAN ID を指定
}
これで、全ての設定が完了しました。 あとは、VirtualMachine カスタムリソースで作成した NAD を指定ください。
NNCP や NAD の削除方法
NAD は oc delete
まとめ
NNCP や NAD を使いこなすことで OpenShift Virtualization のネットワークを効率的に設定、管理可能です。 ぜひ色々な設定を入れて楽しんでみてください。
