20.5. OpenShift SDN ネットワークプラグインからの移行


クラスター管理者は、オフライン の移行方法または制限付きライブマイグレーション方法を使用して、OpenShift SDN ネットワークプラグインから OVN-Kubernetes ネットワークプラグインに移行できます。

警告

OpenShift SDN ネットワークプラグインを使用している場合、クラスターを OpenShift Container Platform 4.17 にアップグレードすることはできません。OpenShift Container Platform 4.17 にアップグレードする前に、OVN-Kubernetes プラグインに移行する必要があります。

OVN-Kubernetes の詳細は、OVN-Kubernetes ネットワークプラグインについて を参照してください。

警告

スクリプトや Red Hat Ansible Automation Platform などの別のツールを使用して、OpenShift SDN から OVN-Kubernetes への移行を自動化しないでください。これにより、OpenShift Container Platform クラスターが停止したりクラッシュしたりする可能性があります。

20.5.1. OVN-Kubernetes ネットワークプラグインへのオフライン移行の概要

オフライン移行方法は手動のプロセスであり、ダウンタイムが発生し、その間はクラスターにアクセスできなくなります。この方法は主に、セルフマネージド OpenShift Container Platform デプロイメントに使用されます。

重要

OpenShift Container Platform クラスターを移行して OVN-Kubernetes ネットワークプラグインを使用する前に、最新のバグ修正がすべてクラスターに適用されるように、クラスターを最新の z-stream リリースに更新してください。

ロールバック手順は提供されていますが、オフライン移行は一方向のプロセスとなる想定です。

注記

OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。

次のセクションでは、オフライン移行方法についてさらに詳しく説明します。

20.5.1.1. オフライン移行方法を使用する場合にサポートされるプラットフォーム

次の表は、オフライン移行タイプでサポートされているプラットフォームに関する情報を示しています。

表20.4 オフライン移行方法でサポートされているプラットフォーム
プラットフォームオフライン移行

ベアメタルハードウェア

Amazon Web Services (AWS)

Google Cloud Platform (GCP)

IBM Cloud®

Microsoft Azure

Red Hat OpenStack Platform (RHOSP)

VMware vSphere

Nutanix

注記

リストされている各プラットフォームは、installer-provisioned infrastructure および user-provisioned infrastructure への OpenShift Container Platform クラスターのインストールをサポートしています。

20.5.1.2. OVN-Kubernetes ネットワークプラグインへのオフライン移行のベストプラクティス

オフライン移行方式を使用して OVN-Kubernetes ネットワークプラグインに移行する場合のベストプラクティスのリストについては、Best practices for OpenShift SDN to OVN Kubernetes CNI Offline migration を参照してください。

20.5.1.3. OVN-Kubernetes ネットワークプラグインへのオフライン移行に関する考慮事項

OpenShift Container Platform クラスターに 150 を超えるノードがある場合は、OVN-Kubernetes ネットワークプラグインへの移行について相談するサポートケースを開きます。

ノードに割り当てられたサブネット、および個々の Pod に割り当てられた IP アドレスは、移行時に保持されません。

OVN-Kubernetes ネットワークプラグインは、OpenShift SDN ネットワークプラグインに存在する多くの機能を実装していますが、設定は同じではありません。

  • クラスターが次の OpenShift SDN ネットワークプラグイン機能のいずれかを使用する場合、OVN-Kubernetes ネットワークプラグインで同じ機能を手動で設定する必要があります。

    • namespace の分離
    • Egress ルーター Pod
  • OVN-Kubernetes に移行する前に、IP アドレス範囲が 100. 64.0.0/16、169.254.169.0/29、100.88.0. 0/16、fd98::/64、fd69::/125、および fd97:: /64 が使用されていないことを確認してください。OVN-Kubernetes はこれらの範囲を内部で使用します。これらの範囲については、クラスターまたはインフラストラクチャーの他の CIDR 定義に含めないでください。

以下のセクションでは、OVN-Kubernetes と OpenShift SDN ネットワークプラグインの前述の機能の設定の違いを強調しています。

プライマリーネットワークインターフェイス

OpenShift SDN プラグインを使用すると、NodeNetworkConfigurationPolicy (NNCP) カスタムリソース (CR) をノード上のプライマリーインターフェイスに適用できます。OVN-Kubernetes ネットワークプラグインにはこの機能はありません。

プライマリーインターフェイスに NNCP が適用されている場合は、OVN-Kubernetes ネットワークプラグインに移行する前に NNCP を削除する必要があります。NNCP を削除しても、プライマリーインターフェイスから設定は削除されませんが、Kubernetes-NMState はこの設定を管理できません。代わりに、configure-ovs.sh シェルスクリプトがプライマリーインターフェイスと、このインターフェイスに接続されている設定を管理します。

namespace の分離

OVN-Kubernetes はネットワークポリシーの分離モードのみをサポートします。

重要

マルチテナントモードまたはサブネット分離モードのいずれかで設定されている OpenShift SDN を使用するクラスターの場合でも、OVN-Kubernetes ネットワークプラグインに移行できます。移行操作後、マルチテナント分離モードは削除されるため、Pod とサービスに対して同じプロジェクトレベルの分離を実現するには、ネットワークポリシーを手動で設定する必要があることに注意してください。

Egress IP アドレス

OpenShift SDN は、2 つの異なる Egress IP モードをサポートしています。

  • 自動的に割り当てる 方法では、Egress IP アドレス範囲はノードに割り当てられます。
  • 手動で割り当てる 方法では、1 つ以上の Egress IP アドレスの一覧がノードに割り当てられます。

移行プロセスでは、自動割り当てモードを使用する Egress IP 設定の移行がサポートされています。

OVN-Kubernetes と OpenShift SDN との間に Egress IP アドレスを設定する際の相違点は、以下の表で説明されています。

表20.5 Egress IP アドレス設定の違い
OVN-KubernetesOpenShift SDN
  • EgressIPs オブジェクトを作成します。
  • アノテーションを Node オブジェクトに追加します。
  • NetNamespace オブジェクトにパッチを適用します。
  • HostSubnet オブジェクトにパッチを適用します。

OVN-Kubernetes で Egress IP アドレスを使用する方法の詳細は、「Egress IP アドレスの設定」を参照してください。

Egress ネットワークポリシー

OVN-Kubernetes と OpenShift SDN との間に Egress ファイアウォールとしても知られる Egress ネットワークポリシーの設定に関する相違点は、以下の表に記載されています。

表20.6 Egress ネットワークポリシー設定の相違点
OVN-KubernetesOpenShift SDN
  • EgressFirewall オブジェクトを namespace に作成します。
  • EgressNetworkPolicy オブジェクトを namespace に作成します。
注記

EgressFirewall オブジェクトの名前は default にしか設定できないため、移行後は、OpenShift SDN での名前に関係なく、移行されたすべての EgressNetworkPolicy オブジェクトに default という名前が付けられます。

その後、OpenShift SDN にロールバックすると、以前の名前が失われるため、すべての EgressNetworkPolicy オブジェクトに default という名前が付けられます。

OVN-Kubernetes で Egress ファイアウォールを使用する方法の詳細は、「プロジェクトの Egress ファイアウォールの設定」を参照してください。

Egress ルーター Pod

OVN-Kubernetes は、リダイレクトモードで Egress ルーター Pod をサポートします。OVN-Kubernetes は、HTTP プロキシーモードまたは DNS プロキシーモードでは Egress ルーター Pod をサポートしません。

Cluster Network Operator で Egress ルーターをデプロイする場合、ノードセレクターを指定して、Egress ルーター Pod のホストに使用するノードを制御することはできません。

マルチキャスト

OVN-Kubernetes と OpenShift SDN でマルチキャストトラフィックを有効にする方法の相違点は、以下の表で説明されています。

表20.7 マルチキャスト設定の相違点
OVN-KubernetesOpenShift SDN
  • アノテーションを Namespace オブジェクトに追加します。
  • アノテーションを NetNamespace オブジェクトに追加します。

OVN-Kubernetes でのマルチキャストの使用に関する詳細は、「プロジェクトのマルチキャストの有効化」を参照してください。

ネットワークポリシー

OVN-Kubernetes は、networking.k8s.io/v1 API グループで Kubernetes NetworkPolicy API を完全にサポートします。OpenShift SDN から移行する際に、ネットワークポリシーで変更を加える必要はありません。

20.5.1.4. オフライン移行プロセスの仕組み

以下の表は、プロセスのユーザーが開始する手順と、移行が応答として実行するアクション間を区分して移行プロセスを要約しています。

表20.8 OpenShift SDN から OVN-Kubernetes へのオフライン移行
ユーザーが開始する手順移行アクティビティー

cluster という名前の Network.operator.openshift.io カスタムリソース (CR) の migration フィールドを OVNKubernetes に設定します。migration フィールドを値に設定する前に null であることを確認します。

Cluster Network Operator (CNO)
cluster という名前の Network.config.openshift.io CR のステータスを更新します。
Machine Config Operator (MCO)
OVN-Kubernetes に必要な systemd 設定の更新をロールアウトします。デフォルトでは、MCO はプールごとに一度に 1 台のマシンを更新するため、クラスターのサイズに応じて移行にかかる合計時間が長くなります。

Network.config.openshift.io CR の networkType フィールドを更新します。

CNO

以下のアクションを実行します。

  • OpenShift SDN コントロールプレーン Pod を破棄します。
  • OVN-Kubernetes コントロールプレーン Pod をデプロイします。
  • 新しいネットワークプラグインを反映するために、Multus デーモンセットと config map オブジェクトを更新します。

クラスターの各ノードを再起動します。

クラスター
ノードの再起動時に、クラスターは OVN-Kubernetes クラスターネットワークの Pod に IP アドレスを割り当てます。

20.5.1.5. オフライン移行方法を使用して OVN-Kubernetes ネットワークプラグインに移行する

クラスター管理者は、クラスターのネットワークプラグインを OVN-Kubernetes に変更できます。移行時に、クラスター内のすべてのノードを再起動する必要があります。

重要

移行の実行中はクラスターを利用できず、ワークロードが中断される可能性があります。サービスの中断が許容可能な場合にのみ移行を実行します。

前提条件

  • ネットワークポリシー分離モードの OpenShift SDN CNI ネットワークプラグインで設定されたクラスターがある。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • etcd データベースの最新のバックアップがある。
  • 各ノードを手動で再起動できる。
  • クラスターがエラーのない既知の良好な状態にあることを確認している。
  • すべてのクラウドプラットフォーム上のすべてのノードに対してポート 6081 上の User Datagram Protocol (UDP) パケットを許可するセキュリティーグループルールを作成している。
  • Webhook のすべてのタイムアウトを 3 秒に設定しているか、Webhook を削除している。

手順

  1. クラスターネットワークの設定のバックアップを作成するには、以下のコマンドを入力します。

    $ oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
  2. 次のコマンドを実行して、OVN_SDN_MIGRATION_TIMEOUT 環境変数が設定され、0s になっていることを確認します。

    #!/bin/bash
    
    if [ -n "$OVN_SDN_MIGRATION_TIMEOUT" ] && [ "$OVN_SDN_MIGRATION_TIMEOUT" = "0s" ]; then
        unset OVN_SDN_MIGRATION_TIMEOUT
    fi
    
    #loops the timeout command of the script to repeatedly check the cluster Operators until all are available.
    
    co_timeout=${OVN_SDN_MIGRATION_TIMEOUT:-1200s}
    timeout "$co_timeout" bash <<EOT
    until
      oc wait co --all --for='condition=AVAILABLE=True' --timeout=10s && \
      oc wait co --all --for='condition=PROGRESSING=False' --timeout=10s && \
      oc wait co --all --for='condition=DEGRADED=False' --timeout=10s;
    do
      sleep 10
      echo "Some ClusterOperators Degraded=False,Progressing=True,or Available=False";
    done
    EOT
  3. 次のコマンドを実行して、Cluster Network Operator (CNO) 設定オブジェクトから設定を削除します。

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
    --patch '{"spec":{"migration":null}}'
  4. 以下の手順を実行して、OpenShift SDN ネットワークプラグインのプライマリーネットワークインターフェイスを定義する NodeNetworkConfigurationPolicy (NNCP) カスタムリソース (CR) を削除します。

    1. 次のコマンドを入力して、既存の NNCP CR がプライマリーインターフェイスをクラスターにボンディングしていることを確認します。

      $ oc get nncp

      出力例

      NAME          STATUS      REASON
      bondmaster0   Available   SuccessfullyConfigured

      Network Manager は、ボンディングされたプライマリーインターフェイスの接続プロファイルを /etc/NetworkManager/system-connections システムパスに保存します。

    2. クラスターから NNCP を削除します。

      $ oc delete nncp <nncp_manifest_filename>
  5. すべてのノードを移行用に準備するには、次のコマンドを実行して、CNO 設定オブジェクトの migration フィールドを設定します。

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'
    注記

    この手順では、OVN-Kubernetes はすぐにデプロイしません。その代わりに、migration フィールドを指定すると、新規マシン設定が OVN-Kubernetes デプロイメントの準備に向けてクラスター内のすべてのノードに適用されるように Machine Config Operator (MCO) がトリガーされます。

    1. 次のコマンドを実行して、再起動が完了したことを確認します。

      $ oc get mcp
    2. 次のコマンドを実行して、すべてのクラスター Operator が利用可能であることを確認します。

      $ oc get co
    3. あるいは、いくつかの OpenShift SDN 機能の OVN-Kubernetes 同等機能への自動移行を無効にすることができます。

      • Egress IP
      • Egress ファイアウォール
      • マルチキャスト

      前述の OpenShift SDN 機能の設定の自動移行を無効にするには、次のキーを指定します。

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{
          "spec": {
            "migration": {
              "networkType": "OVNKubernetes",
              "features": {
                "egressIP": <bool>,
                "egressFirewall": <bool>,
                "multicast": <bool>
              }
            }
          }
        }'

      ここでは、以下のようになります。

      bool: 機能の移行を有効にするかどうかを指定します。デフォルトは true です。

  6. オプション: ネットワークインフラストラクチャーの要件を満たすように OVN-Kubernetes の以下の設定をカスタマイズできます。

    • 最大伝送単位 (MTU)。このオプションの手順で MTU をカスタマイズする前に、以下を考慮してください。

      • デフォルトの MTU を使用しており、移行中にデフォルトの MTU を維持したい場合は、この手順を無視できます。
      • カスタム MTU を使用しており、移行中にカスタム MTU を維持する必要がある場合は、この手順でカスタム MTU 値を宣言する必要があります。
      • 移行中に MTU 値を変更する場合、この手順は機能しません。代わりに、まず「クラスター MTU の変更」に記載された指示に従う必要があります。その後、この手順を実行してカスタム MTU 値を宣言すると、カスタム MTU 値を維持できます。

        注記

        OpenShift-SDN と OVN-Kubernetes のオーバーレイオーバーヘッドは異なります。MTU 値は、「MTU 値の選択」ページにあるガイドラインに従って選択する必要があります。

    • Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークポート
    • OVN-Kubernetes IPv4 内部サブネット
    • OVN-Kubernetes IPv6 内部サブネット

    以前の設定のいずれかをカスタマイズするには、以下のコマンドを入力してカスタマイズします。デフォルト値を変更する必要がない場合は、パッチのキーを省略します。

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":<mtu>,
              "genevePort":<port>,
              "v4InternalSubnet":"<ipv4_subnet>",
              "v6InternalSubnet":"<ipv6_subnet>"
        }}}}'

    ここでは、以下のようになります。

    mtu
    Geneve オーバーレイネットワークの MTU。この値は通常は自動的に設定されますが、クラスターにあるノードすべてが同じ MTU を使用しない場合、これを最小のノード MTU 値よりも 100 小さく設定する必要があります。
    port
    Geneve オーバーレイネットワークの UDP ポート。値が指定されない場合、デフォルトは 6081 になります。ポートは、OpenShift SDN で使用される VXLAN ポートと同じにすることはできません。VXLAN ポートのデフォルト値は 4789 です。
    ipv4_subnet
    OVN-Kubernetes による内部使用のための IPv4 アドレス範囲。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。デフォルト値は 100.64.0.0/16 です。
    ipv6_subnet
    OVN-Kubernetes による内部使用のための IPv6 アドレス範囲。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。デフォルト値は fd98::/48 です。

    mtu フィールドを更新するパッチコマンドの例

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":1200
        }}}}'

  7. MCO がそれぞれのマシン設定プールのマシンを更新すると、各ノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。

    $ oc get mcp

    正常に更新されたノードには、UPDATED=trueUPDATING=falseDEGRADED=false のステータスがあります。

    注記

    デフォルトで、MCO はプールごとに一度に 1 つのマシンを更新するため、移行にかかる合計時間がクラスターのサイズと共に増加します。

  8. ホスト上の新規マシン設定のステータスを確認します。

    1. マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。

      $ oc describe node | egrep "hostname|machineconfig"

      出力例

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done

      以下のステートメントが true であることを確認します。

      • machineconfiguration.openshift.io/state フィールドの値は Done です。
      • machineconfiguration.openshift.io/currentConfig フィールドの値は、machineconfiguration.openshift.io/desiredConfig フィールドの値と等しくなります。
    2. マシン設定が正しいことを確認するには、以下のコマンドを入力します。

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart

      ここで、<config_name>machineconfiguration.openshift.io/currentConfig フィールドのマシン設定の名前になります。

      マシン設定には、systemd 設定に以下の更新を含めることができます。

      ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes
    3. ノードが NotReady 状態のままになっている場合、マシン設定デーモン Pod のログを調べ、エラーを解決します。

      1. Pod をリスト表示するには、以下のコマンドを入力します。

        $ oc get pod -n openshift-machine-config-operator

        出力例

        NAME                                         READY   STATUS    RESTARTS   AGE
        machine-config-controller-75f756f89d-sjp8b   1/1     Running   0          37m
        machine-config-daemon-5cf4b                  2/2     Running   0          43h
        machine-config-daemon-7wzcd                  2/2     Running   0          43h
        machine-config-daemon-fc946                  2/2     Running   0          43h
        machine-config-daemon-g2v28                  2/2     Running   0          43h
        machine-config-daemon-gcl4f                  2/2     Running   0          43h
        machine-config-daemon-l5tnv                  2/2     Running   0          43h
        machine-config-operator-79d9c55d5-hth92      1/1     Running   0          37m
        machine-config-server-bsc8h                  1/1     Running   0          43h
        machine-config-server-hklrm                  1/1     Running   0          43h
        machine-config-server-k9rtx                  1/1     Running   0          43h

        設定デーモン Pod の名前は以下の形式になります。machine-config-daemon-<seq><seq> 値は、ランダムな 5 文字の英数字シーケンスになります。

      2. 以下のコマンドを入力して、直前の出力に表示される最初のマシン設定デーモン Pod の Pod ログを表示します。

        $ oc logs <pod> -n openshift-machine-config-operator

        ここで、pod はマシン設定デーモン Pod の名前になります。

      3. 直前のコマンドの出力で示されるログ内のエラーを解決します。
  9. 移行を開始するには、次のいずれかのコマンドを使用して OVN-Kubernetes ネットワークプラグインを設定します。

    • クラスターネットワークの IP アドレスブロックを変更せずにネットワークプロバイダーを指定するには、以下のコマンドを入力します。

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'
    • 別のクラスターネットワーク IP アドレスブロックを指定するには、以下のコマンドを入力します。

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{
          "spec": {
            "clusterNetwork": [
              {
                "cidr": "<cidr>",
                "hostPrefix": <prefix>
              }
            ],
            "networkType": "OVNKubernetes"
          }
        }'

      ここで、cidr は CIDR ブロックであり、prefix はクラスター内の各ノードに割り当てられる CIDR ブロックのスライスです。OVN-Kubernetes ネットワークプロバイダーはこのブロックを内部で使用するため、100.64.0.0/16 CIDR ブロックと重複する CIDR ブロックは使用できません。

      重要

      移行時に、サービスネットワークのアドレスブロックを変更することはできません。

  10. Multus デーモンセットのロールアウトが完了したことを確認してから、後続の手順を続行します。

    $ oc -n openshift-multus rollout status daemonset/multus

    Multus Pod の名前の形式は multus-<xxxxx> です。ここで、<xxxxx> は文字のランダムなシーケンスになります。Pod が再起動するまでにしばらく時間がかかる可能性があります。

    出力例

    Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated...
    ...
    Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available...
    daemon set "multus" successfully rolled out

  11. ネットワークプラグインの変更を完了するには、クラスター内の各ノードを再起動します。次のいずれかの方法で、クラスター内のノードを再起動できます。

    重要

    次のスクリプトは、クラスター内のすべてのノードを同時に再起動します。これにより、クラスターが不安定になる可能性があります。もう 1 つのオプションとして、ノードを一度に 1 つずつ手動でリブートすることもできます。ノードを 1 つずつ再起動すると、多数のノードを持つクラスターではかなりのダウンタイムが発生します。

    ノードを再起動するまで、クラスター Operator は正しく動作しません。

    • oc rsh コマンドでは、次のような bash スクリプトを使用できます。

      #!/bin/bash
      readarray -t POD_NODES <<< "$(oc get pod -n openshift-machine-config-operator -o wide| grep daemon|awk '{print $1" "$7}')"
      
      for i in "${POD_NODES[@]}"
      do
        read -r POD NODE <<< "$i"
        until oc rsh -n openshift-machine-config-operator "$POD" chroot /rootfs shutdown -r +1
          do
            echo "cannot reboot node $NODE, retry" && sleep 3
          done
      done
    • ssh コマンドでは、次のような bash スクリプトを使用できます。このスクリプトは、パスワードの入力を求めないように sudo が設定されていることを前提としています。

      #!/bin/bash
      
      for ip in $(oc get nodes  -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}')
      do
         echo "reboot node $ip"
         ssh -o StrictHostKeyChecking=no core@$ip sudo shutdown -r -t 3
      done
  12. 移行が正常に完了したことを確認します。

    1. ネットワークプラグインが OVN-Kubernetes であることを確認するには、次のコマンドを入力します。status.networkType の値は OVNKubernetes である必要があります。

      $ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
    2. クラスターノードが Ready 状態にあることを確認するには、以下のコマンドを実行します。

      $ oc get nodes
    3. Pod がエラー状態ではないことを確認するには、以下のコマンドを入力します。

      $ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'

      ノードの Pod がエラー状態にある場合は、そのノードを再起動します。

    4. すべてのクラスター Operator が異常な状態にないことを確認するには、以下のコマンドを入力します。

      $ oc get co

      すべてのクラスター Operator のステータスは、AVAILABLE="True"PROGRESSING="False"DEGRADED="False" になります。クラスター Operator が利用できないか、そのパフォーマンスが低下する場合には、クラスター Operator のログで詳細を確認します。

  13. 以下の手順は、移行に成功し、クラスターの状態が正常である場合にのみ実行します。

    1. CNO 設定オブジェクトから移行設定を削除するには、以下のコマンドを入力します。

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "migration": null } }'
    2. OpenShift SDN ネットワークプロバイダーのカスタム設定を削除するには、以下のコマンドを入力します。

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'
    3. OpenShift SDN ネットワークプロバイダー namespace を削除するには、以下のコマンドを入力します。

      $ oc delete namespace openshift-sdn

20.5.2. OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションの概要

限定的なライブマイグレーション方式は、OpenShift SDN ネットワークプラグインとそのネットワーク設定、接続、および関連リソースを、サービスを中断することなく OVN-Kubernetes ネットワークプラグインに移行するプロセスです。OpenShift Container Platform で利用できます。

重要

OpenShift Container Platform クラスターを移行して OVN-Kubernetes ネットワークプラグインを使用する前に、最新のバグ修正がすべてクラスターに適用されるように、クラスターを最新の z-stream リリースに更新してください。

Hosted Control Plane デプロイメントタイプでは使用できません。この移行方式は、継続的なサービス可用性を必要とするデプロイメントタイプにとって有用で、以下のような利点があります。

  • 継続的なサービスの可用性
  • ダウンタイムの最小化
  • 自動ノード再起動
  • OpenShift SDN ネットワークプラグインから OVN-Kubernetes ネットワークプラグインへのシームレスな移行

ロールバック手順は提供されていますが、限定的なライブマイグレーションは一方向のプロセスとなる想定です。

注記

OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。

次のセクションでは、限定的なライブマイグレーションの方法についてさらに詳しく説明します。

20.5.2.1. 限定的なライブマイグレーション方式を使用する場合にサポートされるプラットフォーム

次の表は、制限付きライブマイグレーションタイプでサポートされているプラットフォームに関する情報を示しています。

表20.9 限定ライブマイグレーション方式でサポートされるプラットフォーム
プラットフォーム限定的なライブマイグレーション

ベアメタルハードウェア

Amazon Web Services (AWS)

Google Cloud Platform (GCP)

IBM Cloud®

Microsoft Azure

Red Hat OpenStack Platform (RHOSP)

VMware vSphere

Nutanix

注記

リストされている各プラットフォームは、installer-provisioned infrastructure および user-provisioned infrastructure への OpenShift Container Platform クラスターのインストールをサポートしています。

20.5.2.2. OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションのベストプラクティス

限定的なライブマイグレーション方式を使用して OVN-Kubernetes ネットワークプラグインに移行する場合のベストプラクティスのリストについては、Limited Live Migration from OpenShift SDN to OVN-Kubernetes を参照してください。

20.5.2.3. OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションに関する考慮事項

OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションメソッドを使用する前に、クラスター管理者は次の情報を考慮する必要があります。

  • OpenShift SDN マルチテナントモードが有効になっているクラスターでは、制限付きライブマイグレーション手順はサポートされません。
  • Egress ルーター Pod は、制限されたライブマイグレーションプロセスをブロックします。制限付きライブマイグレーションのプロセスを開始する前に、それらを削除する必要があります。
  • 移行時に、クラスターが OVN-Kubernetes と OpenShift SDN の両方で実行されている場合、マルチキャストおよび egress IP アドレスは両方の CNI について一時的に無効になります。Egress ファイアウォールは引き続き機能します。
  • 移行は一方向のプロセスとして行われます。ただし、OpenShift-SDN にロールバックするユーザーの場合、OpenShift-SDN から OVN-Kubernetes への移行が成功している必要があります。以下の同じ手順に従って、OVN-Kubernetes ネットワークプラグインから OpenShift SDN ネットワークプラグインに移行できます。
  • 制限付きライブマイグレーションは、HyperShift クラスターではサポートされていません。
  • OpenShift SDN は IPsec をサポートしません。移行後、クラスター管理者は IPsec を有効にできます。
  • OpenShift SDN は IPv6 をサポートしていません。移行後、クラスター管理者はデュアルスタックを有効にできます。
  • OpenShift SDN プラグインを使用すると、NodeNetworkConfigurationPolicy (NNCP) カスタムリソース (CR) をノード上のプライマリーインターフェイスに適用できます。OVN-Kubernetes ネットワークプラグインにはこの機能はありません。
  • クラスター MTU は、Pod インターフェイスの MTU 値です。クラスターネットワークオーバーレイのオーバーヘッドを考慮して、常にハードウェア MTU よりも小さくなります。オーバーヘッドは、OVN-Kubernetes の場合は 100 バイト、OpenShift SDN の場合は 50 バイトです。

    制限付きライブマイグレーション中は、OVN-Kubernetes と OpenShift SDN の両方が並行して実行されます。OVN-Kubernetes は一部のノードのクラスターネットワークを管理し、OpenShift SDN は他のノードのクラスターネットワークを管理します。CNI 間のトラフィックが機能し続けるように、Cluster Network Operator はルーティング可能な MTU を更新し、両方の CNI が同じオーバーレイ MTU を共有するようにします。その結果、移行が完了すると、クラスター MTU は 50 バイト少なくなります。

  • OVN-Kubernetes の一部のパラメーターは、インストール後に変更できません。次のパラメーターを設定できるのは、制限付きライブマイグレーションを開始する前のみです。

    • InternalTransitSwitchSubnet
    • internalJoinSubnet
  • OVN-Kubernetes は、100.64.0.0/16 および 100.88.0.0/16 の IP アドレス範囲を予約します。これらのサブネットは、他の内部ネットワークまたは外部ネットワークと重複することはできません。これらの IP アドレスが OpenShift SDN またはこのクラスターと通信する可能性のある外部ネットワークによって使用されている場合は、制限付きライブマイグレーションを開始する前に、別の IP アドレス範囲を使用するようにパッチを適用する必要があります。詳細は、「OVN-Kubernetes アドレス範囲のパッチ適用」を参照してください。
  • ほとんどの場合、制限付きライブマイグレーションは、Multus CNI プラグインによって作成された Pod のセカンダリーインターフェイスとは無関係です。ただし、これらのセカンダリーインターフェイスがホストのデフォルトのネットワークインターフェイスコントローラー (NIC) 上に設定されている場合 (たとえば、MACVLAN、IPVLAN、SR-IOV、またはブリッジインターフェイスを使用し、デフォルトの NIC を制御ノードとして使用する場合)、OVN-Kubernetes で誤動作が発生する可能性があります。限られたライブマイグレーションに進む前に、このような設定を削除する必要があります。
  • ホスト内に複数の NIC があり、デフォルトルートが Kubernetes NodeIP を持つインターフェイス上にない場合は、代わりにオフライン移行を使用する必要があります。
  • 制限付きライブマイグレーションを開始する前に、Cluster Network Operator (CNO) によって管理されていない openshift-sdn namespace 内のすべての DaemonSet オブジェクトを削除する必要があります。これらの管理されていないデーモンセットが適切に処理されない場合は、移行ステータスが不完全なままになる可能性があります。
  • Operator を実行している場合、または Pod 中断バジェットを使用してアプリケーションを設定している場合は、更新プロセス中に中断が発生する可能性があります。PodDisruptionBudget で minAvailable が 1 に設定されている場合、削除 プロセスをブロックする可能性がある保留中のマシン設定を適用するためにノードがドレインされます。複数のノードが再起動された場合に、すべての Pod が 1 つのノードでのみ実行される可能性があり、PodDisruptionBudget フィールドはノードのドレインを防ぐことができます。

20.5.2.4. 限定的なライブマイグレーションプロセスの仕組み

次の表は、限定的なライブマイグレーションプロセスをまとめたものです。プロセス内のユーザーが開始する手順と、それに対して移行スクリプトが実行するアクションに分かれています。

表20.10 OpenShiftSDN から OVNKubernetes への限定的なライブマイグレーション
ユーザーが開始する手順移行アクティビティー

networkTypeOpenShiftSDN から OVNKubernetes に変更して、クラスターレベルのネットワーク設定にパッチを適用します。

Cluster Network Operator (CNO)
  • network.operator カスタムリソース (CR) の移行関連フィールドを設定し、ルーティング可能な MTU がすべてのノードに適用されるまで待機します。
  • network.operator CR にパッチを適用して、OVN-Kubernetes の移行モードを Live に設定し、OpenShift SDN ネットワークプラグインを移行モードでデプロイします。
  • ハイブリッドオーバーレイを有効にして OVN-Kubernetes をデプロイし、競合状態が発生しないようにします。
  • OVN-Kubernetes のデプロイメントを待機し、network.config CR のステータスの条件を更新します。
  • Machine Config Operator (MCO) をトリガーして、ノードの遮断、ドレイン、再起動を含む新しいマシン設定を各マシン設定プールに適用します。
  • OVN-Kubernetes は適切なゾーンにノードを追加し、OVN-Kubernetes をデフォルトの CNI プラグインとして使用して Pod を再作成します。
  • network.operator CR から移行関連のフィールドを削除し、OpenShift SDN リソースの削除や、必要な設定での OVN-Kubernetes の通常モードでの再デプロイなどのクリーンアップアクションを実行します。
  • OVN-Kubernetes の再デプロイメントを待機し、移行の完了を示すために network.config CR のステータス条件を更新します。移行がブロックされている場合は、「限定的なライブマイグレーションのメトリクスの確認」で問題のトラブルシューティング方法を参照してください。

20.5.2.5. 制限付きライブマイグレーション方式を使用して OVN-Kubernetes ネットワークプラグインに移行する

制限付きライブマイグレーション方式を使用して OVN-Kubernetes ネットワークプラグインに移行するには、複数のステップから成るプロセスが必要であり、ユーザーは Egress IP リソース、Egress ファイアウォールリソース、およびマルチキャスト対応の namespace の動作を確認する必要があります。管理者は、限定的なライブマイグレーションプロセスを開始する前に、デプロイメント内のネットワークポリシーを確認し、Egress ルーターリソースを削除する必要があります。以下の手順を連続して実行する必要があります。

20.5.2.5.1. 限定的なライブマイグレーションを開始する前にクラスターリソースを確認する

制限付きライブマイグレーションを使用して OVN-Kubernetes に移行する前に、OpenShift SDN デプロイメントで Egress IP リソース、Egress ファイアウォールリソース、およびマルチキャスト対応の namespace を確認する必要があります。また、デプロイメント内のネットワークポリシーも確認する必要があります。移行前にクラスターにこれらのリソースがあることがわかった場合は、移行後にそれらの動作をチェックして、意図したとおりに動作していることを確認する必要があります。

次の手順では、Egress IP リソース、Egress ファイアウォールリソース、マルチキャスト対応の namespace、ネットワークポリシー、および NNCP を確認する方法を示します。これらのリソースを確認した後は、何もする必要はありません。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. OpenShift Container Platform クラスター管理者として、Egress ファイアウォールリソースを確認します。これは、oc CLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。

    1. oc CLI ツールを使用して Egress ファイアウォールリソースを確認するには、以下を行います。

      1. Egress ファイアウォールリソースを確認するには、次のコマンドを入力します。

        $ oc get egressnetworkpolicies.network.openshift.io -A

        出力例

        NAMESPACE    NAME                      AGE
        <namespace>  <example_egressfirewall>  5d

      2. -o yaml フラグを使用して、Egress ファイアウォールリソースの意図された動作を確認できます。以下に例を示します。

        $ oc get egressnetworkpolicy <example_egressfirewall> -n <namespace> -o yaml

        出力例

        apiVersion: network.openshift.io/v1
        kind: EgressNetworkPolicy
        metadata:
          name: <example_egress_policy>
          namespace: <namespace>
        spec:
          egress:
          - type: Allow
            to:
              cidrSelector: 0.0.0.0/0
          - type: Deny
            to:
              cidrSelector: 10.0.0.0/8

    2. OpenShift Container Platform Web コンソールを使用して Egress ファイアウォールリソースを確認するには、以下を行います。

      1. OpenShift Container Platform Web コンソールで、Observe Metrics をクリックします。
      2. Expression ボックスに sdn_controller_num_egress_firewalls と入力し、Run queries をクリックします。Egress ファイアウォールリソースがある場合は、それらが Expression ボックスに返されます。
  2. クラスターの Egress IP リソースを確認します。これは、oc CLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。

    1. oc CLI ツールを使用して Egress IP を確認するには、以下を行います。

      1. Egress IP リソースを持つ namespace をリスト表示するには、次のコマンドを入力します。

        $ oc get netnamespace -A | awk '$3 != ""'

        出力例

        NAME        NETID      EGRESS IPS
        namespace1  14173093   ["10.0.158.173"]
        namespace2  14173020   ["10.0.158.173"]

    2. OpenShift Container Platform Web コンソールを使用して Egress IP を確認するには、以下を行います。

      1. OpenShift Container Platform Web コンソールで、Observe Metrics をクリックします。
      2. Expression ボックスに sdn_controller_num_egress_ips と入力し、Run queries をクリックします。Egress ファイアウォールリソースがある場合は、それらが Expression ボックスに返されます。
  3. クラスターでマルチキャスト対応の namespace を確認します。これは、oc CLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。

    1. oc CLI ツールを使用してマルチキャスト対応の namespace を確認するには、次を行います。

      1. マルチキャストが有効になっている namespace を見つけるには、次のコマンドを入力します。

        $ oc get netnamespace -o json | jq -r '.items[] | select(.metadata.annotations."netnamespace.network.openshift.io/multicast-enabled" == "true") | .metadata.name'

        出力例

        namespace1
        namespace3

    2. OpenShift Container Platform Web コンソールを使用してマルチキャスト対応の namespace を確認するには、以下を行います。

      1. OpenShift Container Platform Web コンソールで、Observe Metrics をクリックします。
      2. Expression ボックスに sdn_controller_num_multicast_enabled_namespaces と入力し、Run queries をクリックします。マルチキャスト対応の namespace がある場合は、それらが Expression ボックスに返されます。
  4. クラスターのネットワークポリシーを確認します。これは oc CLI を使用して実行できます。

    1. oc CLI ツールを使用してネットワークポリシーを確認するには、次のコマンドを実行します。

      $ oc get networkpolicy -n <namespace>

      出力例

      NAME              POD-SELECTOR   AGE
      allow-multicast   app=my-app     11m

20.5.2.5.2. 制限付きライブマイグレーションを開始する前に Egress ルーター Pod を削除する

制限付きライブマイグレーションを開始する前に、Egress ルーター Pod を確認して削除する必要があります。制限付きライブマイグレーションを実行するときにクラスター上に Egress ルーター Pod がある場合、ネットワーク Operator は移行をブロックし、次のエラーを返します。

The cluster configuration is invalid (network type limited live migration is not supported for pods with `pod.network.openshift.io/assign-macvlan` annotation.

Please remove all egress router pods). Use `oc edit network.config.openshift.io cluster` to fix.

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. クラスター上の Egress ルーター Pod を見つけるには、次のコマンドを入力します。

    $ oc get pods --all-namespaces -o json | jq '.items[] | select(.metadata.annotations."pod.network.openshift.io/assign-macvlan" == "true") | {name: .metadata.name, namespace: .metadata.namespace}'

    出力例

    {
      "name": "egress-multi",
      "namespace": "egress-router-project"
    }

  2. あるいは、OpenShift Container Platform Web コンソールでメトリクスをクエリーすることもできます。

    1. OpenShift Container Platform Web コンソールで、Observe Metrics をクリックします。
    2. Expression ボックスに、network_attachment_definition_instances{networks="egress-router"} と入力します。次に、Add をクリックします。
  3. Egress ルーター Pod を削除するには、次のコマンドを実行します。

    $ oc delete pod <egress_pod_name> -n <egress_router_project>
20.5.2.5.3. NodeNetworkConfigurationPolicy (NNCP) カスタムリソース (CR) の削除

OpenShift SDN プラグインを使用すると、NodeNetworkConfigurationPolicy (NNCP) カスタムリソース (CR) をノード上のプライマリーインターフェイスに適用できます。OVN-Kubernetes ネットワークプラグインにはこの機能はありません。

プライマリーインターフェイスに NNCP が適用されている場合は、OVN-Kubernetes ネットワークプラグインに移行する前に NNCP を削除する必要があります。NNCP を削除しても、プライマリーインターフェイスから設定は削除されませんが、Kubernetes-NMState はこの設定を管理できません。代わりに、configure-ovs.sh シェルスクリプトがプライマリーインターフェイスとそれに接続された設定を管理します。

前提条件

  • NNCP CR を作成し、ネットワークのプライマリーインターフェイスに適用している。

手順

  1. 次のコマンドを実行して、Cluster Network Operator (CNO) 設定オブジェクトから設定を削除します。

    $ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{"spec":{"migration":null}}'
  2. 以下の手順を実行して、OpenShift SDN ネットワークプラグインのプライマリーネットワークインターフェイスを定義する NodeNetworkConfigurationPolicy (NNCP) カスタムリソース (CR) を削除します。

    1. 次のコマンドを入力して、既存の NNCP CR がプライマリーインターフェイスをクラスターにボンディングしていることを確認します。

      $ oc get nncp

      出力例

      NAME          STATUS      REASON
      bondmaster0   Available   SuccessfullyConfigured

      Network Manager は、ボンディングされたプライマリーインターフェイスの接続プロファイルを /etc/NetworkManager/system-connections システムパスに保存します。

    2. クラスターから NNCP を削除します。

      $ oc delete nncp <nncp_manifest_filename>
20.5.2.5.4. 限定的なライブマイグレーションプロセスの開始

Egress IP リソース、Egress ファイアウォールリソース、およびマルチキャスト対応 namespace の動作を確認し、Egress ルーターリソースを削除したら、制限付きライブマイグレーションプロセスを開始できます。

前提条件

  • クラスターは、ネットワークポリシー分離モードで OpenShift SDN CNI ネットワークプラグインを使用して設定されています。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • etcd データベースの最新のバックアップを作成している。
  • クラスターは既知の正常な状態にあり、エラーがない。
  • OVN-Kubernetes に移行する前に、すべてのクラウドプラットフォーム上のすべてのノードに対してポート 6081 上の UDP パケットを許可するセキュリティーグループルールを設定する必要があります。
  • 100.64.0.0/16 および 100.88.0.0/16 アドレス範囲が以前 OpenShift-SDN によって使用されていた場合は、パッチが適用されています。この手順の最初のステップでは、これらのアドレス範囲が使用中かどうかを確認します。使用中の場合は、「OVN-Kubernetes アドレス範囲のパッチ適用」を参照してください。
  • Egress IP リソース、Egress ファイアウォールリソース、およびマルチキャスト対応の namespace を確認しました。
  • 制限付きライブマイグレーションを開始する前に、Egress ルーター Pod をすべて削除しておきます。Egress ルーター Pod の詳細は、「リダイレクトモードでの Egress ルーター Pod のデプロイ」を参照してください。
  • このドキュメントの「OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションに関する考慮事項」セクションを確認している。

手順

  1. クラスターレベルのネットワーク設定にパッチを適用し、OpenShift SDN から OVN-Kubernetes への移行を開始するには、次のコマンドを入力します。

    $ oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OVNKubernetes"}}'

    このコマンドを実行すると、移行プロセスが開始します。このプロセス中に、Machine Config Operator はクラスター内のノードを 2 回再起動します。移行には、クラスターのアップグレードの約 2 倍の時間がかかります。

    重要

    この oc patch コマンドは、OpenShift SDN で使用されている重複する CIDR をチェックします。重複する CIDR が検出された場合は、制限付きライブマイグレーションプロセスを開始する前に、CIDR をパッチする必要があります。詳細は、「OVN-Kubernetes アドレス範囲のパッチ適用」を参照してください。

  2. オプション: 移行プロセスが完了したことを確認し、network.config のステータスを確認するには、次のコマンドを実行します。

    $ oc get network.config.openshift.io cluster -o jsonpath='{.status.networkType}'
    $ oc get network.config cluster -o=jsonpath='{.status.conditions}' | jq .

    問題のトラブルシューティングのために、限定的なライブマイグレーションのメトリクスを確認できます。詳細は、「限定的なライブマイグレーションのメトリクスの確認」を参照してください。

20.5.2.5.5. OVN-Kubernetes アドレス範囲のパッチ適用

OVN-Kubernetes は次の IP アドレス範囲を予約します。

  • 100.64.0.0/16.この IP アドレス範囲は、デフォルトで OVN-Kubernetes の internalJoinSubnet パラメーターに使用されます。
  • 100.88.0.0/16.この IP アドレス範囲は、デフォルトで OVN-Kubernetes の internalTransSwitchSubnet パラメーターに使用されます。

これらの IP アドレスが OpenShift SDN またはこのクラスターと通信する可能性のある外部ネットワークによって使用されている場合は、制限付きライブマイグレーションを開始する前に、別の IP アドレス範囲を使用するようにパッチを適用する必要があります。

移行が最初にブロックした場合は、次の手順を使用して、OpenShift SDN で使用している CIDR 範囲にパッチを適用できます。

注記

これはオプションの手順であり、「限定的なライブマイグレーションプロセスの開始」の oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OVNKubernetes"}}' コマンドを使用した後に移行がブロックされた場合にのみ使用する必要があります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. 100.64.0.0/16 IP アドレス範囲がすでに使用されている場合は、次のコマンドを実行して別の範囲にパッチを適用します。次の例では 100.63.0.0/16 を使用します。

    $ oc patch network.operator.openshift.io cluster --type='merge' -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipv4":{"internalJoinSubnet": "100.63.0.0/16"}}}}}'
  2. 100.88.0.0/16 IP アドレス範囲がすでに使用されている場合は、次のコマンドを入力して別の範囲にパッチを適用します。次の例では、100.99.0.0/16 を使用します。

    $ oc patch network.operator.openshift.io cluster --type='merge' -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipv4":{"internalTransitSwitchSubnet": "100.99.0.0/16"}}}}}'

IP アドレス範囲 100.64.0.0/16 および 100.88.0.0/16 にパッチを適用した後、制限付きライブマイグレーションを開始できます。

20.5.2.5.6. 限定的なライブマイグレーションを開始した後のクラスターリソースの確認

次の手順では、デプロイで OVN-Kubernetes を使用しているときに、Egress IP リソース、Egress ファイアウォールリソース、マルチキャスト対応の namespace、およびネットワークポリシーを確認する方法を示します。OpenShift SDN 上にこれらのリソースがあった場合は、移行後にそれらを確認して、適切に動作していることを確認する必要があります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • 制限付きライブマイグレーションを使用して、OpenShift SDN から OVN-Kubernetes に正常に移行しました。

手順

  1. OpenShift Container Platform クラスター管理者として、Egress ファイアウォールリソースを確認します。これは、oc CLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。

    1. oc CLI ツールを使用して Egress ファイアウォールリソースを確認するには、以下を行います。

      1. Egress ファイアウォールリソースを確認するには、次のコマンドを入力します。

        $ oc get egressfirewalls.k8s.ovn.org -A

        出力例

        NAMESPACE    NAME                      AGE
        <namespace>  <example_egressfirewall>   5d

      2. -o yaml フラグを使用して、Egress ファイアウォールリソースの意図された動作を確認できます。以下に例を示します。

        $ oc get egressfirewall <example_egressfirewall> -n <namespace> -o yaml

        出力例

        apiVersion: k8s.ovn.org/v1
        kind: EgressFirewall
        metadata:
          name: <example_egress_policy>
          namespace: <namespace>
        spec:
          egress:
          - type: Allow
            to:
              cidrSelector: 192.168.0.0/16
          - type: Deny
            to:
              cidrSelector: 0.0.0.0/0

        移行後にこのリソースの動作が変更されている可能性があるため、このリソースの動作が意図したとおりであることを確認してください。Egress ファイアウォールの詳細は、「プロジェクトの Egress ファイアウォールの設定」を参照してください。

    2. OpenShift Container Platform Web コンソールを使用して Egress ファイアウォールリソースを確認するには、以下を行います。

      1. OpenShift Container Platform Web コンソールで、Observe Metrics をクリックします。
      2. Expression ボックスに ovnkube_controller_num_egress_firewall_rules と入力し、Run queries をクリックします。Egress ファイアウォールリソースがある場合は、それらが Expression ボックスに返されます。
  2. クラスターの Egress IP リソースを確認します。これは、oc CLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。

    1. oc CLI ツールを使用して Egress IP を確認するには、以下を行います。

      1. Egress IP リソースを含む namespace をリスト表示するには、次のコマンドを実行します。

        $ oc get egressip

        出力例

        NAME                EGRESSIPS    ASSIGNED NODE                              ASSIGNED EGRESSIPS
        egress-sample       192.0.2.10   ip-10-0-42-79.us-east-2.compute.internal   192.0.2.10
        egressip-sample-2   192.0.2.14   ip-10-0-42-79.us-east-2.compute.internal   192.0.2.14

      2. Egress IP に関する詳細情報を提供するには、次のコマンドを実行します。

        $ oc get egressip <egressip_name> -o yaml

        出力例

        apiVersion: k8s.ovn.org/v1
        kind: EgressIP
        metadata:
          annotations:
            kubectl.kubernetes.io/last-applied-configuration: |
              {"apiVersion":"k8s.ovn.org/v1","kind":"EgressIP","metadata":{"annotations":{},"name":"egressip-sample"},"spec":{"egressIPs":["192.0.2.12","192.0.2.13"],"namespaceSelector":{"matchLabels":{"name":"my-namespace"}}}}
          creationTimestamp: "2024-06-27T15:48:36Z"
          generation: 7
          name: egressip-sample
          resourceVersion: "125511578"
          uid: b65833c8-781f-4cc9-bc96-d970259a7631
        spec:
          egressIPs:
          - 192.0.2.12
          - 192.0.2.13
          namespaceSelector:
            matchLabels:
              name: my-namespace

        すべての Egress IP に対してこれを繰り返します。移行後に各リソースの動作が変更されている可能性があるため、各リソースの動作が意図したとおりであることを確認します。Egress IP の詳細は、「Egress IP アドレスの設定」を参照してください。

    2. OpenShift Container Platform Web コンソールを使用して Egress IP を確認するには、以下を行います。

      1. OpenShift Container Platform Web コンソールで、Observe Metrics をクリックします。
      2. Expression ボックスに ovnkube_clustermanager_num_egress_ips と入力し、Run queries をクリックします。Egress ファイアウォールリソースがある場合は、それらが Expression ボックスに返されます。
  3. クラスターでマルチキャスト対応の namespace を確認します。これを実行できるのは oc CLI を使用する場合のみです。

    1. マルチキャストが有効になっている namespace を見つけるには、次のコマンドを入力します。

      $ oc get namespace -o json | jq -r '.items[] | select(.metadata.annotations."k8s.ovn.org/multicast-enabled" == "true") | .metadata.name'

      出力例

      namespace1
      namespace3

    2. マルチキャスト対応の各 namespace を説明するには、次のコマンドを実行します。

      $ oc describe namespace <namespace>

      出力例

      Name:         my-namespace
      Labels:       kubernetes.io/metadata.name=my-namespace
                    pod-security.kubernetes.io/audit=restricted
                    pod-security.kubernetes.io/audit-version=v1.24
                    pod-security.kubernetes.io/warn=restricted
                    pod-security.kubernetes.io/warn-version=v1.24
      Annotations:  k8s.ovn.org/multicast-enabled: true
                    openshift.io/sa.scc.mcs: s0:c25,c0
                    openshift.io/sa.scc.supplemental-groups: 1000600000/10000
                    openshift.io/sa.scc.uid-range: 1000600000/10000
      Status:       Active

      各 namespace でマルチキャスト機能が正しく設定され、期待どおりに動作していることを確認します。詳細は、"プロジェクトでのマルチキャストの有効化" を参照してください。

  4. クラスターのネットワークポリシーを確認します。これを実行できるのは oc CLI を使用する場合のみです。

    1. namespace 内のネットワークポリシーに関する情報を取得するには、次のコマンドを実行します。

      $ oc get networkpolicy -n <namespace>

      出力例

      NAME              POD-SELECTOR   AGE
      allow-multicast   app=my-app     11m

    2. ネットワークポリシーに関する詳細情報を提供するには、次のコマンドを入力します。

      $ oc describe networkpolicy allow-multicast -n <namespace>

      出力例

      Name:         allow-multicast
      Namespace:    my-namespace
      Created on:   2024-07-24 14:55:03 -0400 EDT
      Labels:       <none>
      Annotations:  <none>
      Spec:
        PodSelector:     app=my-app
        Allowing ingress traffic:
          To Port: <any> (traffic allowed to all ports)
          From:
            IPBlock:
              CIDR: 224.0.0.0/4
              Except:
        Allowing egress traffic:
          To Port: <any> (traffic allowed to all ports)
          To:
            IPBlock:
              CIDR: 224.0.0.0/4
              Except:
        Policy Types: Ingress, Egress

      ネットワークポリシーの動作が意図したとおりであることを確認します。ネットワークポリシーの最適化は SDN と OVN-K で異なるため、ユーザーはさまざまな CNI で最適なパフォーマンスを実現するためにポリシーの調整が必要になる場合があります。詳細は、「ネットワークポリシーについて」を参照してください。

20.5.2.6. 限定的なライブマイグレーションのメトリクスの確認

限定的なライブマイグレーションの進行状況を監視するためのメトリクスが利用可能です。メトリクスは、OpenShift Container Platform Web コンソール、または oc CLI を使用して表示できます。

前提条件

  • OVN-Kubernetes への限定的なライブマイグレーションを開始している。

手順

  1. OpenShift Container Platform Web コンソールで限定されたライブマイグレーションメトリクスを表示するには、次の手順を実行します。

    1. Observe Metrics をクリックします。
    2. Expression ボックスに openshift_network と入力し、openshift_network_operator_live_migration_procedure オプションをクリックします。
  2. oc CLI を使用してメトリクスを表示するには、以下を実行します。

    1. 以下のコマンドを入力して、openshift-monitoring namespace に prometheus-k8s サービスアカウントのトークンを生成します。

      $ oc create token prometheus-k8s -n openshift-monitoring

      出力例

      eyJhbGciOiJSUzI1NiIsImtpZCI6IlZiSUtwclcwbEJ2VW9We...

    2. 次のコマンドを入力して、openshift_network_operator_live_migration_condition メトリクスに関する情報を要求します。

      $ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -k -H "Authorization: <eyJhbGciOiJSUzI1NiIsImtpZCI6IlZiSUtwclcwbEJ2VW9We...>" "https://<openshift_API_endpoint>" --data-urlencode "query=openshift_network_operator_live_migration_condition" | jq

      出力例

       "status": "success",
        "data": {
          "resultType": "vector",
          "result": [
            {
              "metric": {
                "__name__": "openshift_network_operator_live_migration_condition",
                "container": "network-operator",
                "endpoint": "metrics",
                "instance": "10.0.83.62:9104",
                "job": "metrics",
                "namespace": "openshift-network-operator",
                "pod": "network-operator-6c87754bc6-c8qld",
                "prometheus": "openshift-monitoring/k8s",
                "service": "metrics",
                "type": "NetworkTypeMigrationInProgress"
              },
              "value": [
                1717653579.587,
                "1"
              ]
            },
      ...

「制限付きのライブマイグレーションメトリクスに関する情報」の表には、利用可能なメトリクスと、openshift_network_operator_live_migration_procedure 式から入力されたラベル値が表示されます。この情報を使用して、移行の進行状況を監視したり、移行のトラブルシューティングを行ったりします。

20.5.2.6.1. ライブマイグレーションのメトリックスに関する情報

次の表は、openshift_network_operator_live_migration_procedure 式から入力された利用可能なメトリクスとラベル値を示しています。この情報を使用して、移行の進行状況を監視したり、移行のトラブルシューティングを行ったりします。

表20.11 制限付きライブマイグレーションのメトリクス
メトリクスラベル値
openshift_network_operator_live_migration_blocked:
Prometheus ゲージベクトルメトリクス。CNI 制限ライブマイグレーションが開始されなかった可能性がある理由がラベル付けされた定数 1 値を含むメトリクス。このメトリクスは、ネットワーク カスタムリソースにアノテーションを付けて CNI 制限付きライブマイグレーションが開始されたときに使用できます。
制限付きライブマイグレーションがブロックされない限り、このメトリクスは公開されません。
ラベル値のリストには以下が含まれます。
  • UnsupportedCNI: サポート対象外のターゲット CNI への移行ができません。OpenShift SDN から移行する場合、有効な CNI は OVNKubernetes です。
  • UnsupportedHyperShiftCluster: HCP クラスター内では制限付きライブマイグレーションはサポートされていません。
  • UnsupportedSDNNetworkIsolationMode : OpenShift SDN は、サポートされていないネットワーク分離モード Multitenant で設定されています。制限付きライブマイグレーションを実行する前に、サポートされているネットワーク分離モードに移行します。
  • UnsupportedMACVLANInterface :Egress ルーターまたは Pod アノテーション pod.network.openshift.io/assign-macvlan を含む Pod を削除します。

    oc get pods -Ao=jsonpath='{range .items[?(@.metadata.annotations.pod\.network\.openshift\.io/assign-macvlan=="")]}{@.metadata.namespace}{"\t"}{@.metadata.name}{"\n"}' のコマンドで、問題のある Pod の namespace または Pod 名を見つけます。
openshift_network_operator_live_migration_condition:
CNI 制限付きライブマイグレーションの各条件タイプのステータスを表すメトリクス。CNI 制限付きライブマイグレーションの可観測性をサポートするために、network.config に対してステータス条件タイプのセットが定義されています。
1 は条件ステータスが true であることを表します。値 0 は、false を表します。-1 は、不明を表します。このメトリクスは、Network カスタムリソース (CR) にアノテーションを付けて CNI 制限付きライブマイグレーションが開始されたときに使用できます。
このメトリクスは、Network CR クラスターに関連するアノテーションを追加することによって制限付きライブマイグレーションがトリガーされた場合にのみ使用可能です。それ以外の場合は公開されません。ネットワーク CR クラスター内に次の条件タイプが存在しない場合は、メトリクスとそのラベルが消去されます。
ラベル値のリストには以下が含まれます。
  • NetworkTypeMigrationInProgress
  • NetworkTypeMigrationTargetCNIAvailable
  • NetworkTypeMigrationTargetCNIInUse
  • NetworkTypeMigrationOriginalCNIPurged
  • NetworkTypeMigrationMTUReady

20.5.3. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.