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 が選択されているためにネットワーク通信が中断または誤って設定されている場合、次のエラーが表示されることがあります: EtcdCertSignerControllerDegradedNODEIP_HINT 変数を含むヒントファイルを作成して、デフォルトの IP 選択ロジックをオーバーライドできます。詳細は、オプション: デフォルトのノード IP 選択ロジックのオーバーライドを参照してください。

7.5.1.1. オプション: デフォルトのノード IP 選択ロジックのオーバーライド

デフォルトの IP 選択ロジックをオーバーライドするには、NODEIP_HINT 変数を含むヒントファイルを作成して、デフォルトの IP 選択ロジックをオーバーライドします。ヒントファイルを作成すると、NODEIP_HINT 変数で指定された IP アドレスのサブネット内のインターフェイスから特定のノード IP アドレスを選択できます。

たとえば、ノードに 10.0.0.10/24 のアドレスを持つ eth0192.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 変数を設定できます。その結果、eth1192.0.2.5 IP アドレスがノードに使用されます。

次の手順は、デフォルトのノード IP 選択ロジックをオーバーライドする方法を示しています。

手順

  1. /etc/default/nodeip-configuration ファイルにヒントファイルを追加します。たとえば、以下のようになります。

    NODEIP_HINT=192.0.2.1
    重要
    • 192.0.2.5 など、ノードの正確な IP アドレスをヒントとして使用しないでください。ノードの正確な IP アドレスを使用すると、ヒント IP アドレスを使用するノードが正しく設定できなくなります。
    • ヒントファイル内の IP アドレスは、正しいサブネットを決定するためにのみ使用されます。ヒントファイルに表示されるため、トラフィックを受信しません。
  2. 次のコマンドを実行して、base-64 でエンコードされたコンテンツを生成します。

    $ echo -n 'NODEIP_HINT=192.0.2.1' | base64 -w0

    出力例

    Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==

  3. クラスターをデプロイする前に、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==)。コンマの後およびエンコードされたコンテンツの前にスペースを入れることはできないことに注意してください。
  4. ~/clusterconfigs など、クラスター設定を保存するディレクトリーにマニフェストを保存します。
  5. クラスターのデプロイ

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 は次の順序でタスクを完了します。

  1. 選択したマシン設定プールに基づいて、単一の順序でノードをドレインします。
  2. 各ノードに Ignition 設定ファイルを挿入し、各ノードが追加の br-ex1 ブリッジネットワーク設定を受信するようにします。
  3. br-ex の MAC アドレスが、br-ex がネットワーク接続に使用するインターフェイスの MAC アドレスと一致していることを確認します。
  4. 新しいインターフェイス定義を参照する configure-ovs.sh シェルスクリプトを実行します。
  5. br-exbr-ex1 をホストノードに追加します。
  6. ノードをスケジューリング対象に戻します。
注記

すべてのノードが Ready 状態に戻り、OVN-Kubernetes Operator が br-exbr-ex1 を検出して設定した後、Operator は各ノードに k8s.ovn.org/l3-gateway-config アノテーションを適用します。

追加の br-ex1 ブリッジが役立つ状況と、デフォルトの br-ex ブリッジが常に必要な状況の詳細は、「ローカルネットトポロジーの設定」を参照してください。

手順

  1. オプション: 次の手順を実行して、追加のブリッジ br-ex1 が使用できるインターフェイス接続を作成します。この手順の例では、新しいボンディングとその依存インターフェイスを作成する方法を示しています。これらはすべて、マシン設定マニフェストファイルで定義されています。追加のブリッジは、MachineConfig オブジェクトを使用して追加のボンディングインターフェイスを形成します。

    重要

    追加のインターフェイスを定義するために、Kubernetes NMState Operator または NodeNetworkConfigurationPolicy (NNCP) マニフェストファイルを使用しないでください。ボンディング インターフェイスを定義する際に、追加のインターフェイスまたはサブインターフェイスが既存の br-ex OVN Kubernetes ネットワークデプロイメントで使用されていないことを確認してください。

    インストール後の作業として、br-ex ブリッジまたはその基盤となるインターフェイスの設定変更を行うことはできません。回避策として、ホストまたはスイッチに接続されたセカンダリーネットワークインターフェイスを使用してください。

    1. 次のインターフェイス定義ファイルを作成します。以下のファイルは、ホストノードが定義ファイルにアクセスできるように、マシン設定マニフェストファイルに追加されます。

      1 番目のインターフェイス定義ファイルの例 (eno1.config)

      [connection]
      id=eno1
      type=ethernet
      interface-name=eno1
      master=bond1
      slave-type=bond
      autoconnect=true
      autoconnect-priority=20

      2 番目のインターフェイス定義ファイルの例 (eno2.config)

      [connection]
      id=eno2
      type=ethernet
      interface-name=eno2
      master=bond1
      slave-type=bond
      autoconnect=true
      autoconnect-priority=20

      2 番目のボンディングインターフェイス定義ファイルの例 (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

    2. 次のコマンドを実行して、定義ファイルを Base64 でエンコードされた文字列に変換します。

      $ base64 <directory_path>/en01.config
      $ base64 <directory_path>/eno2.config
      $ base64 <directory_path>/bond1.config
  2. 環境変数を準備します。<machine_role> を、worker などのノードロールに置き換え、<interface_name> を追加の br-ex ブリッジ名に置き換えます。

    $ export ROLE=<machine_role>
  3. マシン設定マニフェストファイルで各インターフェイス定義を定義します。

    bond1eno1en02 の定義を追加したマシン設定ファイルの例

    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
    # ...

  4. ターミナルで次のコマンドを入力して、ネットワークプラグインを設定するためのマシン設定マニフェストファイルを作成します。

    $ oc create -f <machine_config_file_name>
  5. OVN-Kubernetes ネットワークプラグインを使用して extra_bridge ファイルを作成し、ノード上に Open vSwitch (OVS) ブリッジ br-ex1 を作成します。このファイルは、ホストの /etc/ovnk/extra_bridge パスに保存します。ファイルには、ノードのプライマリー IP アドレスを保持する br-ex をサポートするデフォルトのインターフェイスではなく、追加のブリッジをサポートするインターフェイスの名前を記述する必要があります。

    追加のインターフェイスを参照する extra_bridge ファイル /etc/ovnk/extra_bridge の設定例

    bond1

  6. クラスターで再起動されるノードで 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

  7. 選択したノードにマシン設定を適用します。

    $ oc create -f <machine_config_file_name>
  8. オプション: /var/lib/ovnk/iface_default_hint リソースを作成するマシン設定ファイルを作成することにより、ノードの br-ex 選択ロジックをオーバーライドできます。

    注記

    このリソースには、br-ex がクラスター用に選択するインターフェイスの名前がリストされます。br-ex は、デフォルトで、ブート順序とマシンネットワーク内の IP アドレスサブネットに基づいて、ノードのプライマリーインターフェイスを選択します。マシンネットワークの設定によっては、ホストノードのデフォルトのインターフェイスまたはボンディングを引き続き br-ex が選択する必要があります。

    1. ホストノードに、デフォルトのインターフェイスをオーバーライドするためのマシン設定ファイルを作成します。

      重要

      このマシン設定ファイルは、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,bond0 
      1
      
                filesystem: root

      1
      マシン設定ファイルをノードに適用する前に、ノードに bond0 が存在することを確認します。
    2. クラスター内のすべての新しいノードに設定を適用する前に、ホストノードを再起動して、br-ex が目的のインターフェイスを選択し、br-ex1 で定義した新しいインターフェイスと競合しないことを検証します。
    3. クラスター内のすべての新しいノードにマシン設定ファイルを適用します。

      $ oc create -f <machine_config_file_name>

検証

  1. クラスター内の 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\"],

  2. ホストノードのネットワークインターフェイス名を確認して、ターゲットノードに追加のブリッジが存在することを確認します。

    $ 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

  3. オプション: /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

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る