7.5. ネットワーク関連の問題のトラブルシューティング
7.5.1. ネットワークインターフェイスの選択方法 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルでのインストールや、複数のネットワークインターフェイスコントローラー (NIC) でのインストールの場合に、OpenShift Container Platform が Kubernetes API サーバーとの通信に使用する NIC は、ノードの起動時に systemd で実行される nodeip-configuration.service サービスユニットによって決定されます。nodeip-configuration.service は、デフォルトルートに関連付けられたインターフェイスから IP を選択します。
nodeip-configuration.service サービスが正しい NIC を決定すると、このサービスは /etc/systemd/system/kubelet.service.d/20-nodenet.conf ファイルを作成します。20-nodenet.conf ファイルは、KUBELET_NODE_IP 環境変数を、サービスが選択した IP アドレスに設定します。
kubelet サービスの起動時に、20-nodenet.conf ファイルから環境変数の値を読み取り、IP アドレスを --node-ip kubelet コマンドライン引数に設定します。その結果、kubelet サービスは選択した IP アドレスをノード IP アドレスとして使用します。
インストール後にハードウェアまたはネットワークが再設定された場合、またはノード IP がデフォルトルートインターフェイスから取得されないネットワークレイアウトがある場合、再起動後に nodeip-configuration.service サービスが別の NIC を選択する可能性があります。oc get nodes -o wide コマンドの出力の INTERNAL-IP 列を確認して、別の NIC が選択されていることを確認できる場合があります。
別の NIC が選択されているためにネットワーク通信が中断または誤って設定されている場合、次のエラーが表示されることがあります: EtcdCertSignerControllerDegraded。NODEIP_HINT 変数を含むヒントファイルを作成して、デフォルトの IP 選択ロジックをオーバーライドできます。詳細は、オプション: デフォルトのノード IP 選択ロジックのオーバーライドを参照してください。
7.5.1.1. オプション: デフォルトのノード IP 選択ロジックのオーバーライド リンクのコピーリンクがクリップボードにコピーされました!
デフォルトの IP 選択ロジックをオーバーライドするには、NODEIP_HINT 変数を含むヒントファイルを作成して、デフォルトの IP 選択ロジックをオーバーライドします。ヒントファイルを作成すると、NODEIP_HINT 変数で指定された IP アドレスのサブネット内のインターフェイスから特定のノード IP アドレスを選択できます。
たとえば、ノードに 10.0.0.10/24 のアドレスを持つ eth0 と 192.0.2.5/24 のアドレスを持つ eth1 の 2 つのインターフェイスがあり、デフォルトルートが eth0 (10.0.0.10) を指している場合、ノードの IP アドレスは通常、10.0.0.10 IP アドレスを使用します。
ユーザーは、別のサブネット 192.0.2.0/24 が選択されるように、サブネット内の既知の IP (たとえば、192.0.2.1 などのサブネットゲートウェイ) を指すように NODEIP_HINT 変数を設定できます。その結果、eth1 の 192.0.2.5 IP アドレスがノードに使用されます。
次の手順は、デフォルトのノード IP 選択ロジックをオーバーライドする方法を示しています。
手順
/etc/default/nodeip-configurationファイルにヒントファイルを追加します。たとえば、以下のようになります。NODEIP_HINT=192.0.2.1重要-
192.0.2.5など、ノードの正確な IP アドレスをヒントとして使用しないでください。ノードの正確な IP アドレスを使用すると、ヒント IP アドレスを使用するノードが正しく設定できなくなります。 - ヒントファイル内の IP アドレスは、正しいサブネットを決定するためにのみ使用されます。ヒントファイルに表示されるため、トラフィックを受信しません。
-
次のコマンドを実行して、
base-64でエンコードされたコンテンツを生成します。$ echo -n 'NODEIP_HINT=192.0.2.1' | base64 -w0出力例
Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==クラスターをデプロイする前に、
masterロールとworkerロールの両方のマシン設定マニフェストを作成して、ヒントを有効にします。99-nodeip-hint-master.yaml
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: 99-nodeip-hint-master spec: config: ignition: version: 3.2.0 storage: files: - contents: source: data:text/plain;charset=utf-8;base64,<encoded_content>1 mode: 0644 overwrite: true path: /etc/default/nodeip-configuration- 1 1
<encoded_contents>を/etc/default/nodeip-configurationファイルの base64 でエンコードされたコンテンツに置き換えます (例:Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==)。コンマの後およびエンコードされたコンテンツの前にスペースを入れることはできないことに注意してください。99-nodeip-hint-worker.yaml
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 99-nodeip-hint-worker spec: config: ignition: version: 3.2.0 storage: files: - contents: source: data:text/plain;charset=utf-8;base64,<encoded_content>1 mode: 0644 overwrite: true path: /etc/default/nodeip-configuration<encoded_contents>を/etc/default/nodeip-configurationファイルの base64 でエンコードされたコンテンツに置き換えます (例:Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==)。コンマの後およびエンコードされたコンテンツの前にスペースを入れることはできないことに注意してください。
-
~/clusterconfigsなど、クラスター設定を保存するディレクトリーにマニフェストを保存します。 - クラスターのデプロイ
7.5.1.2. セカンダリー OVS ブリッジを使用するように OVN-Kubernetes を設定する リンクのコピーリンクがクリップボードにコピーされました!
追加または セカンダリー の Open vSwitch (OVS) ブリッジ br-ex1 を作成できます。このブリッジは、OVN-Kubernetes によって管理され、Multiple External Gateways (MEG) 実装が OpenShift Container Platform ノードの外部ゲートウェイを定義するために使用するものです。MEG は、AdminPolicyBasedExternalRoute カスタムリソース (CR) で定義できます。MEG 実装は、複数のゲートウェイ、等コストマルチパス (ECMP) ルート、および双方向フォワーディング検出 (BFD) 実装へのアクセスを Pod に提供します。
Multiple External Gateways (MEG) 機能の影響を受ける Pod のユースケースを考えてみてください。たとえば、ノード上の別のインターフェイス (br-ex1 など) に Egress トラフィックを送信するとします。MEG の影響を受けない Pod の Egress トラフィックは、デフォルトの OVS br-ex ブリッジにルーティングされます。
現在、MEG は、Egress IP、Egress ファイアウォール、Egress ルーターなどの他の Egress 機能との使用はサポートされていません。Egress IP などの Egress 機能で MEG を使用しようとすると、ルーティングとトラフィックフローの競合が発生する可能性があります。これは、OVN-Kubernetes がルーティングと送信元ネットワークアドレス変換 (SNAT) を処理する方法が原因で発生します。その結果、ルーティングに一貫性がなくなり、戻りパスが着信パスをパッチする必要がある一部の環境では接続が切断される可能性があります。
追加のブリッジは、マシン設定マニフェストファイルのインターフェイス定義で定義する必要があります。Machine Config Operator が、このマニフェストを使用して、ホスト上の /etc/ovnk/extra_bridge に新しいファイルを作成します。この新しいファイルには、追加の OVS ブリッジがノード用に設定するネットワークインターフェイスの名前が含まれています。
nmstate API を使用して、/etc/ovnk/extra_bridge ディレクトリーパスで定義されているセカンダリーインターフェイスの設定変更を行わないでください。configure-ovs.sh 設定スクリプトは OVS ブリッジインターフェイスを作成および管理するため、nmstate API によるこれらのインターフェイスへの中断的な変更は、ネットワーク設定の不安定性につながる可能性があります。
マニフェストファイルを作成して編集すると、Machine Config Operator は次の順序でタスクを完了します。
- 選択したマシン設定プールに基づいて、単一の順序でノードをドレインします。
-
各ノードに Ignition 設定ファイルを挿入し、各ノードが追加の
br-ex1ブリッジネットワーク設定を受信するようにします。 -
br-exの MAC アドレスが、br-exがネットワーク接続に使用するインターフェイスの MAC アドレスと一致していることを確認します。 -
新しいインターフェイス定義を参照する
configure-ovs.shシェルスクリプトを実行します。 -
br-exとbr-ex1をホストノードに追加します。 - ノードをスケジューリング対象に戻します。
すべてのノードが Ready 状態に戻り、OVN-Kubernetes Operator が br-ex と br-ex1 を検出して設定した後、Operator は各ノードに k8s.ovn.org/l3-gateway-config アノテーションを適用します。
追加の br-ex1 ブリッジが役立つ状況と、デフォルトの br-ex ブリッジが常に必要な状況の詳細は、「ローカルネットトポロジーの設定」を参照してください。
手順
オプション: 次の手順を実行して、追加のブリッジ
br-ex1が使用できるインターフェイス接続を作成します。この手順の例では、新しいボンディングとその依存インターフェイスを作成する方法を示しています。これらはすべて、マシン設定マニフェストファイルで定義されています。追加のブリッジは、MachineConfigオブジェクトを使用して追加のボンディングインターフェイスを形成します。重要追加のインターフェイスを定義するために、Kubernetes NMState Operator または
NodeNetworkConfigurationPolicy(NNCP) マニフェストファイルを使用しないでください。ボンディングインターフェイスを定義する際に、追加のインターフェイスまたはサブインターフェイスが既存のbr-exOVN Kubernetes ネットワークデプロイメントで使用されていないことを確認してください。インストール後の作業として、
br-exブリッジまたはその基盤となるインターフェイスの設定変更を行うことはできません。回避策として、ホストまたはスイッチに接続されたセカンダリーネットワークインターフェイスを使用してください。次のインターフェイス定義ファイルを作成します。以下のファイルは、ホストノードが定義ファイルにアクセスできるように、マシン設定マニフェストファイルに追加されます。
1 番目のインターフェイス定義ファイルの例 (
eno1.config)[connection] id=eno1 type=ethernet interface-name=eno1 master=bond1 slave-type=bond autoconnect=true autoconnect-priority=202 番目のインターフェイス定義ファイルの例 (
eno2.config)[connection] id=eno2 type=ethernet interface-name=eno2 master=bond1 slave-type=bond autoconnect=true autoconnect-priority=202 番目のボンディングインターフェイス定義ファイルの例 (
bond1.config)[connection] id=bond1 type=bond interface-name=bond1 autoconnect=true connection.autoconnect-slaves=1 autoconnect-priority=20 [bond] mode=802.3ad miimon=100 xmit_hash_policy="layer3+4" [ipv4] method=auto次のコマンドを実行して、定義ファイルを Base64 でエンコードされた文字列に変換します。
$ base64 <directory_path>/en01.config$ base64 <directory_path>/eno2.config$ base64 <directory_path>/bond1.config
環境変数を準備します。
<machine_role>を、workerなどのノードロールに置き換え、<interface_name>を追加のbr-exブリッジ名に置き換えます。$ export ROLE=<machine_role>マシン設定マニフェストファイルで各インターフェイス定義を定義します。
bond1、eno1、en02の定義を追加したマシン設定ファイルの例apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: ${worker} name: 12-${ROLE}-sec-bridge-cni spec: config: ignition: version: 3.2.0 storage: files: - contents: source: data:;base64,<base-64-encoded-contents-for-bond1.conf> path: /etc/NetworkManager/system-connections/bond1.nmconnection filesystem: root mode: 0600 - contents: source: data:;base64,<base-64-encoded-contents-for-eno1.conf> path: /etc/NetworkManager/system-connections/eno1.nmconnection filesystem: root mode: 0600 - contents: source: data:;base64,<base-64-encoded-contents-for-eno2.conf> path: /etc/NetworkManager/system-connections/eno2.nmconnection filesystem: root mode: 0600 # ...ターミナルで次のコマンドを入力して、ネットワークプラグインを設定するためのマシン設定マニフェストファイルを作成します。
$ oc create -f <machine_config_file_name>OVN-Kubernetes ネットワークプラグインを使用して
extra_bridgeファイルを作成し、ノード上に Open vSwitch (OVS) ブリッジbr-ex1を作成します。このファイルは、ホストの/etc/ovnk/extra_bridgeパスに保存します。ファイルには、ノードのプライマリー IP アドレスを保持するbr-exをサポートするデフォルトのインターフェイスではなく、追加のブリッジをサポートするインターフェイスの名前を記述する必要があります。追加のインターフェイスを参照する
extra_bridgeファイル/etc/ovnk/extra_bridgeの設定例bond1クラスターで再起動されるノードで
br-ex1をホストする既存の静的インターフェイスを定義したマシン設定マニフェストファイルを作成します。br-ex1をホストするインターフェイスとしてbond1を定義したマシン設定ファイルの例apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: ${worker} name: 12-worker-extra-bridge spec: config: ignition: version: 3.2.0 storage: files: - path: /etc/ovnk/extra_bridge mode: 0420 overwrite: true contents: source: data:text/plain;charset=utf-8,bond1 filesystem: root選択したノードにマシン設定を適用します。
$ oc create -f <machine_config_file_name>オプション:
/var/lib/ovnk/iface_default_hintリソースを作成するマシン設定ファイルを作成することにより、ノードのbr-ex選択ロジックをオーバーライドできます。注記このリソースには、
br-exがクラスター用に選択するインターフェイスの名前がリストされます。br-exは、デフォルトで、ブート順序とマシンネットワーク内の IP アドレスサブネットに基づいて、ノードのプライマリーインターフェイスを選択します。マシンネットワークの設定によっては、ホストノードのデフォルトのインターフェイスまたはボンディングを引き続きbr-exが選択する必要があります。ホストノードに、デフォルトのインターフェイスをオーバーライドするためのマシン設定ファイルを作成します。
重要このマシン設定ファイルは、
br-ex選択ロジックを変更する目的でのみ作成します。このファイルを使用してクラスター内の既存のノードの IP アドレスを変更することはサポートされていません。デフォルトのインターフェイスをオーバーライドするマシン設定ファイルの例
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: ${worker} name: 12-worker-br-ex-override spec: config: ignition: version: 3.2.0 storage: files: - path: /var/lib/ovnk/iface_default_hint mode: 0420 overwrite: true contents: source: data:text/plain;charset=utf-8,bond01 filesystem: root- 1
- マシン設定ファイルをノードに適用する前に、ノードに
bond0が存在することを確認します。
-
クラスター内のすべての新しいノードに設定を適用する前に、ホストノードを再起動して、
br-exが目的のインターフェイスを選択し、br-ex1で定義した新しいインターフェイスと競合しないことを検証します。 クラスター内のすべての新しいノードにマシン設定ファイルを適用します。
$ oc create -f <machine_config_file_name>
検証
クラスター内の
exgw-ip-addressesラベルを持つノードの IP アドレスを特定し、ノードがデフォルトのブリッジではなく追加のブリッジを使用していることを確認します。$ oc get nodes -o json | grep --color exgw-ip-addresses出力例
"k8s.ovn.org/l3-gateway-config": \"exgw-ip-address\":\"172.xx.xx.yy/24\",\"next-hops\":[\"xx.xx.xx.xx\"],ホストノードのネットワークインターフェイス名を確認して、ターゲットノードに追加のブリッジが存在することを確認します。
$ oc debug node/<node_name> -- chroot /host sh -c "ip a | grep mtu | grep br-ex"出力例
Starting pod/worker-1-debug ... To use host binaries, run `chroot /host` # ... 5: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 6: br-ex1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000オプション:
/var/lib/ovnk/iface_default_hintを使用する場合は、br-exの MAC アドレスが、選択したプライマリーインターフェイスの MAC アドレスと一致していることを確認します。$ oc debug node/<node_name> -- chroot /host sh -c "ip a | grep -A1 -E 'br-ex|bond0'br-exのプライマリーインターフェイスがbond0であることを示す出力例Starting pod/worker-1-debug ... To use host binaries, run `chroot /host` # ... sh-5.1# ip a | grep -A1 -E 'br-ex|bond0' 2: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ovs-system state UP group default qlen 1000 link/ether fa:16:3e:47:99:98 brd ff:ff:ff:ff:ff:ff -- 5: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:47:99:98 brd ff:ff:ff:ff:ff:ff inet 10.xx.xx.xx/21 brd 10.xx.xx.255 scope global dynamic noprefixroute br-ex