20.6. OpenShift SDN ネットワークプロバイダーへのロールバック


クラスター管理者は、オフライン 移行方法または 制限付きライブ 移行方法のいずれかを使用して、OVN-Kubernetes ネットワークプラグインから OpenShift SDN ネットワークプラグインにロールバックできます。これは、OVN-Kubernetes ネットワークプラグインへの移行が正常に完了した後にのみ実行できます。

注記
  • オフライン移行方法を使用して OVN-Kubernetes ネットワークプラグインから OpenShift SDN ネットワークプラグインに移行した場合は、オフライン移行ロールバック方法を使用する必要があります。
  • 制限付きライブマイグレーション方式を使用して OVN-Kubernetes ネットワークプラグインから OpenShift SDN ネットワークプラグインに移行した場合は、制限付きライブマイグレーションロールバック方式を使用する必要があります。
注記

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.6.1. オフライン移行方法を使用した OpenShift SDN ネットワークプラグインへのロールバック

クラスター管理者は、オフライン移行方法を使用して、OpenShift SDN Container Network Interface (CNI) ネットワークプラグインにロールバックできます。移行中は、クラスター内のすべてのノードを手動で再起動する必要があります。オフライン移行方法では、ダウンタイムが発生し、その間はクラスターにアクセスできなくなります。

重要

ロールバックを開始する前に、OpenShift SDN から OVN-Kubernetes ネットワークプラグインへの移行プロセスが成功するまで待つ必要があります。

OpenShift SDN へのロールバックが必要な場合は、以下の表がプロセスを説明します。

表20.12 OpenShift SDN へのロールバックの実行
ユーザーが開始する手順移行アクティビティー

MCO を一時停止し、移行が中断されないようにします。

MCO が停止します。

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

CNO
cluster という名前の Network.config.openshift.io CR のステータスを更新します。

networkType フィールドを更新します。

CNO

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

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

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

クラスター
ノードがリブートすると、クラスターは OpenShift-SDN ネットワーク上の Pod に IP アドレスを割り当てます。

クラスターのすべてのノードが再起動した後に MCO を有効にします。

MCO
OpenShift SDN に必要な systemd 設定の更新をロールアウトします。デフォルトでは、MCO はプールごとに一度に 1 台のマシンを更新するため、移行にかかる合計時間はクラスターのサイズに応じて増加します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールが割り当てられたユーザーを使用してクラスターにアクセスできる。
  • インフラストラクチャーにインストールされたクラスターが OVN-Kubernetes ネットワークプラグインで設定されている。
  • etcd データベースの最新のバックアップが利用可能である。
  • ノードごとに手動の再起動をトリガーできる。
  • クラスターは既知の正常な状態にあり、エラーがない。

手順

  1. Machine Config Operator (MCO) によって管理されるすべてのマシン設定プールを停止します。

    • CLI で次のコマンドを入力して、master 設定プールを停止します。

      $ oc patch MachineConfigPool master --type='merge' --patch \
        '{ "spec": { "paused": true } }'
    • CLI で次のコマンドを入力して、worker マシン設定プールを停止します。

      $ oc patch MachineConfigPool worker --type='merge' --patch \
        '{ "spec":{ "paused": true } }'
  2. 移行の準備をするには、CLI で次のコマンドを入力して、移行フィールドを null に設定します。

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": null } }'
  3. CLI で次のコマンドを入力して、Network.config.openshift.io オブジェクトの移行ステータスが空であることを確認します。空のコマンド出力は、オブジェクトが移行操作中ではないことを示しています。

    $ oc get Network.config cluster -o jsonpath='{.status.migration}'
  4. CLI で次のコマンドを入力して、Network.operator.openshift.io オブジェクトにパッチを適用し、ネットワークプラグインを OpenShift SDN に戻します。

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": { "networkType": "OpenShiftSDN" } } }'
    重要

    Network.operator.openshift.io オブジェクトでパッチ操作が終了する前に Network.config.openshift.io オブジェクトにパッチを適用した場合、Cluster Network Operator (CNO) は degradation 状態になり、CNO が degradation 状態から回復するまでわずかな遅延が発生します。

  5. CLI で次のコマンドを入力して、Network.config.openshift.io cluster オブジェクトのネットワークプラグインの移行ステータスが OpenShiftSDN であることを確認します。

    $ oc get Network.config cluster -o jsonpath='{.status.migration.networkType}'
  6. CLI で次のコマンドを入力して、Network.config.openshift.io オブジェクトにパッチを適用し、ネットワークプラグインを OpenShift SDN に戻します。

    $ oc patch Network.config.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "networkType": "OpenShiftSDN" } }'
  7. オプション: いくつかの OVN-Kubernetes 機能の OpenShift SDN 同等機能への自動移行を無効化します。

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

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

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

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

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

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

    • 最大伝送単位 (MTU)
    • VXLAN ポート

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

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "openshiftSDNConfig":{
              "mtu":<mtu>,
              "vxlanPort":<port>
        }}}}'
    mtu
    VXLAN オーバーレイネットワークの MTU。この値は通常は自動的に設定されますが、クラスターにあるノードすべてが同じ MTU を使用しない場合、これを最小のノード MTU 値よりも 50 小さく設定する必要があります。
    port
    VXLAN オーバーレイネットワークの UDP ポート。値が指定されない場合は、デフォルトは 4789 になります。ポートは OVN-Kubernetes で使用される Geneve ポートと同じにすることはできません。Geneve ポートのデフォルト値は 6081 です。

    patch コマンドの例

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

  9. クラスター内の各ノードを再起動します。次のいずれかの方法で、クラスター内のノードを再起動できます。

    • 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
  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. クラスター内のノードが再起動し、multus Pod がロールアウトされたら、次のコマンドを実行してすべてのマシン設定プールを起動します。

    • マスター設定プールを開始します。

      $ oc patch MachineConfigPool master --type='merge' --patch \
        '{ "spec": { "paused": false } }'
    • ワーカー設定プールを開始します。

      $ oc patch MachineConfigPool worker --type='merge' --patch \
        '{ "spec": { "paused": false } }'

    MCO が各設定プールのマシンを更新すると、各ノードを再起動します。

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

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

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

      $ 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. マシン設定が正しいことを確認するには、CLI で以下のコマンドを入力します。

      $ oc get machineconfig <config_name> -o yaml

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

  13. 移行が正常に完了したことを確認します。

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

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

      $ oc get nodes
    3. ノードが NotReady 状態のままになっている場合、マシン設定デーモン Pod のログを調べ、エラーを解決します。

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

        $ 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 ログを表示するには、CLI で次のコマンドを入力します。

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

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

      3. 直前のコマンドの出力で示されるログ内のエラーを解決します。
    4. Pod がエラー状態ではないことを確認するには、CLI で次のコマンドを入力します。

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

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

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

    1. Cluster Network Operator 設定オブジェクトから移行設定を削除するには、CLI で次のコマンドを入力します。

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "migration": null } }'
    2. OVN-Kubernetes 設定を削除するには、CLI で次のコマンドを入力します。

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

      $ oc delete namespace openshift-ovn-kubernetes

20.6.2. 制限付きのライブマイグレーションの方法を使用した OpenShift SDN ネットワークプラグインへのロールバック

クラスター管理者は、クラスターを OpenShift SDN Container Network Interface (CNI) ネットワークプラグインにロールバックできます。この方法による移行中は、ノードは自動的に再起動され、クラスターへのサービスは中断されません。

重要

ロールバックを開始する前に、OpenShift SDN から OVN-Kubernetes ネットワークプラグインへの移行プロセスが成功するまで待つ必要があります。

OpenShift SDN へのロールバックが必要な場合は、以下の表がプロセスを説明します。

表20.13 OpenShift SDN へのロールバックの実行
ユーザーが開始する手順移行アクティビティー

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

Cluster Network Operator (CNO)

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

  • network.operator カスタムリソース (CR) の移行関連フィールドを設定し、Machine Config Operator (MCO) によってルーティング可能な MTU がすべてのノードに適用されるまで待機します。
  • network.operator CR にパッチを適用して、OpenShiftSDN の移行モードを Live に設定し、移行モードで OpenShiftSDN ネットワークプラグインをデプロイします。
  • ハイブリッドオーバーレイを有効にして OVN-Kubernetes をデプロイします。
  • 両方の CNI プラグインがデプロイされるのを待機し、network.config CR のステータスの条件を更新します。
  • MCO をトリガーして、新しいマシン設定を各マシン設定プールに適用します。これには、ノードの遮断、ドレイン、および再起動が含まれます。
  • network.operator CR から移行関連のフィールドを削除し、OpenShift SDN リソースの削除や、必要な設定での OVN-Kubernetes の通常モードでの再デプロイなどのクリーンアップアクションを実行します。
  • OpenShiftSDN の再デプロイメントを待機し、移行の完了を示すために network.config CR のステータス条件を更新します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールが割り当てられたユーザーを使用してクラスターにアクセスできる。
  • インフラストラクチャーにインストールされたクラスターが OVN-Kubernetes ネットワークプラグインで設定されている。
  • etcd データベースの最新のバックアップが利用可能である。
  • ノードごとに手動の再起動をトリガーできる。
  • クラスターは既知の正常な状態にあり、エラーがない。

手順

  1. OpenShift SDN へのロールバックを開始するには、次のコマンドを入力します。

    $ oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OpenShiftSDN"}}'
  2. 移行の進行状況を確認するには、次のコマンドを入力します。

    $ watch -n1 'oc get network.config/cluster -o json | jq ".status.conditions[]|\"\\(.type) \\(.status) \\(.reason) \\(.message)\""  -r | column --table --table-columns NAME,STATUS,REASON,MESSAGE --table-columns-limit 4; echo; oc get mcp -o wide; echo; oc get node -o "custom-columns=NAME:metadata.name,STATE:metadata.annotations.machineconfiguration\\.openshift\\.io/state,DESIRED:metadata.annotations.machineconfiguration\\.openshift\\.io/desiredConfig,CURRENT:metadata.annotations.machineconfiguration\\.openshift\\.io/currentConfig,REASON:metadata.annotations.machineconfiguration\\.openshift\\.io/reason"'

    このコマンドは、次の情報を毎秒出力します。

    • network.config.openshift.io/cluster オブジェクトのステータスの条件。移行の進捗を報告します。
    • machine-config-Operator リソースに関するさまざまなノードのステータス。これには、アップグレード中かアップグレード済みか、および現在の設定と必要な設定が含まれます。
  3. 以下の手順は、移行に成功し、クラスターの状態が正常である場合にのみ実行します。

    1. 次のコマンドを入力して、network.config カスタムリソースから network.openshift.io/network-type-migration= アノテーションを削除します。

      $ oc annotate network.config cluster network.openshift.io/network-type-migration-
    2. 次のコマンドを入力して、OVN-Kubernetes ネットワークプロバイダーの namespace を削除します。

      $ oc delete namespace openshift-ovn-kubernetes
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.