3.5. カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成
configure-ovs.sh シェルスクリプトを使用してベアメタルプラットフォームで br-ex ブリッジを設定する代わりに、NMState 設定ファイルを含む MachineConfig オブジェクトを作成できます。ホスト nmstate-configuration.service および nmstate.service は、クラスターで実行される各ノードに NMState 設定ファイルを適用します。
カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトを作成する場合は、次のユースケースを検討してください。
-
Open vSwitch (OVS) または OVN-Kubernetes
br-exブリッジネットワークの変更など、ブリッジにインストール後の変更を加えたい場合。configure-ovs.shシェルスクリプトは、ブリッジへのインストール後の変更をサポートしていません。 - ホストまたはサーバーの IP アドレスで使用可能なインターフェイスとは異なるインターフェイスにブリッジをデプロイします。
-
configure-ovs.shシェルスクリプトでは不可能な、ブリッジの高度な設定を実行したいと考えています。これらの設定にスクリプトを使用すると、ブリッジが複数のネットワークインターフェイスに接続できず、インターフェイス間のデータ転送が促進されない可能性があります。
単一のネットワークインターフェイスコントローラー (NIC) とデフォルトのネットワーク設定を備えた環境が必要な場合は、configure-ovs.sh シェルスクリプトを使用します。
Red Hat Enterprise Linux CoreOS (RHCOS) をインストールしてシステムを再起動すると、Machine Config Operator がクラスター内の各ノードに Ignition 設定ファイルを挿入し、各ノードが br-ex ブリッジネットワーク設定を受け取るようになります。設定の競合を防ぐために、configure-ovs.sh シェルスクリプトは、br-ex ブリッジを設定しない信号を受け取ります。
次のインターフェイス名のリストが予約されており、NMstate 設定では名前を使用できません。
-
br-ext -
br-int -
br-local -
br-nexthop -
br0 -
ext-vxlan -
ext -
genev_sys_* -
int -
k8s-* -
ovn-k8s-* -
patch-br-* -
tun0 -
vxlan_sys_*
前提条件
-
オプション: NMState 設定を検証できるように、
nmstateAPI をインストールしました。
手順
カスタマイズされた
br-exブリッジネットワークの base64 情報をデコードした NMState 設定ファイルを作成します。カスタマイズされた
br-exブリッジネットワークの NMState 設定の例interfaces: - name: enp2s0 type: ethernet state: up ipv4: enabled: false ipv6: enabled: false - name: br-ex type: ovs-bridge state: up ipv4: enabled: false dhcp: false ipv6: enabled: false dhcp: false bridge: options: mcast-snooping-enable: true port: - name: enp2s0 - name: br-ex - name: br-ex type: ovs-interface state: up copy-mac-from: enp2s0 ipv4: enabled: true dhcp: true auto-route-metric: 48 ipv6: enabled: true dhcp: true auto-route-metric: 48 # ...ここでは、以下のようになります。
interfaces.name- インターフェイスの名前。
interfaces.type- イーサネットのタイプ。
interfaces.state- 作成後のインターフェイスの要求された状態。
ipv4.enabled- この例では、IPv4 と IPv6 を無効にします。
port.name- ブリッジが接続されるノードの NIC。
auto-route-metric-
br-exのデフォルトルートの優先順位が常に最も高い(最も低いメトリック)ようにするには、パラメーターを48に設定します。この設定により、NetworkManagerサービスが自動的に設定するその他のインターフェイスとのルーティングの競合が回避されます。
catコマンドを使用して、NMState 設定の内容を base64 でエンコードします。$ cat <nmstate_configuration>.yml | base64ここでは、以下のようになります。
<nmstate_configuration>-
<nmstate_configuration>を NMState リソース YAML ファイルの名前に置き換えます。
MachineConfigマニフェストファイルを作成し、次の例に類似したカスタマイズされたbr-exブリッジネットワーク設定を定義します。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 10-br-ex-worker spec: config: ignition: version: 3.2.0 storage: files: - contents: source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> mode: 0644 overwrite: true path: /etc/nmstate/openshift/worker-0.yml - contents: source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> mode: 0644 overwrite: true path: /etc/nmstate/openshift/worker-1.yml # ...ここでは、以下のようになります。
metadata.name- ポリシーの名前。
contents.source- エンコードされた base64 情報を指定されたパスに書き込みます。
pathクラスター内の各ノードに対して、ノードへのホスト名パスと、マシンタイプに応じた base-64 でエンコードされた Ignition 設定ファイルデータを指定します。
workerロールは、クラスター内のノードのデフォルトロールです。各ノードまたはMachineConfigマニフェストファイルのすべてのノードに短いホスト名パスを指定する場合は、$(hostname -s)などの設定ファイルに .yml 拡張を使用する必要があります。.ymlクラスターのすべてのノードに適用する
/etc/nmstate/openshift/cluster.yml設定ファイルに指定された単一のグローバル設定がある場合は、/etc/nmstate/openshift/<node_hostname>.ymlなどの各ノードの短いホスト名パスを指定する必要はありません。以下に例を示します。# ... - contents: source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> mode: 0644 overwrite: true path: /etc/nmstate/openshift/cluster.yml # ...
次のコマンドを入力して、
MachineConfigオブジェクトからクラスターに更新を適用します。$ oc apply -f <machine_config>.yml
次のステップ
-
コンピュートノードをスケーリングして、クラスターに存在する各コンピュートノードにカスタマイズされた
br-exブリッジを含むマニフェストオブジェクトを適用します。詳細については、関連情報 セクションの「クラスターの展開」を参照して ください。
3.5.1. 各マシンセットをコンピュートノードにスケーリング リンクのコピーリンクがクリップボードにコピーされました!
カスタマイズされた br-ex ブリッジ設定を OpenShift Container Platform クラスター内のすべてのコンピュートノードに適用するには、MachineConfig カスタムリソース (CR) を編集し、そのロールを変更する必要があります。さらに、ホスト名、認証情報など、ベアメタルマシンの情報を定義する BareMetalHost CR を作成する必要があります。
これらのリソースを設定した後、マシンセットをスケーリングして、マシンセットが各コンピュートノードにリソース設定を適用し、ノードを再起動できるようにする必要があります。
前提条件
-
カスタマイズされた
br-exブリッジ設定を含むMachineConfigマニフェストオブジェクトを作成しました。
手順
次のコマンドを入力して
MachineConfigCR を編集します。$ oc edit mc <machineconfig_custom_resource_name>- 各コンピュートノード設定を CR に追加して、CR がクラスター内の定義済みコンピュートノードごとにロールを管理できるようにします。
-
最小限の静的 IP 設定を持つ
extraworker-secretという名前のSecretオブジェクトを作成します。 次のコマンドを入力して、クラスター内の各ノードに
extraworker-secretシークレットを適用します。このステップでは、各コンピュートノードに Ignition 設定ファイルへのアクセスを提供します。$ oc apply -f ./extraworker-secret.yamlBareMetalHostリソースを作成し、preprovisioningNetworkDataNameパラメーターでネットワークシークレットを指定します。ネットワークシークレットが添付された
BareMetalHostリソースの例apiVersion: metal3.io/v1alpha1 kind: BareMetalHost spec: # ... preprovisioningNetworkDataName: ostest-extraworker-0-network-config-secret # ...クラスターの
openshift-machine-apinamespace 内でBareMetalHostオブジェクトを管理するために、次のコマンドを入力して namespace に変更します。$ oc project openshift-machine-apiマシンセットを取得します。
$ oc get machinesets次のコマンドを入力して、各マシンセットをスケールします。このコマンドはマシンセットごとに実行する必要があります。
$ oc scale machineset <machineset_name> --replicas=<n>1 - 1
<machineset_name>はマシンセットの名前です。<n>はコンピュートノードの数です。