4.3.2.3. 複数のノードの以前のクラスター状態への復元


保存された etcd のバックアップを使用して、クラスターの以前の状態を復元したり、大多数のコントロールプレーンホストが失われたクラスターを復元したりできます。

高可用性 (HA) クラスターの場合、3 ノードの HA クラスターでは、クラスターの分割を回避するために、2 つのホストで etcd をシャットダウンする必要があります。4 ノードおよび 5 ノードの HA クラスターでは、3 つのホストをシャットダウンする必要があります。クォーラムにはノードの単純過半数が必要です。3 ノードの HA クラスターのクォーラムに必要なノードの最小数は 2 です。4 ノードおよび 5 ノードの HA クラスターでは、クォーラムに必要なノードの最小数は 3 です。リカバリーホスト上のバックアップから新しいクラスターを起動すると、他の etcd メンバーがクォーラムを形成してサービスを継続できる可能性があります。

注記

クラスターがコントロールプレーンマシンセットを使用している場合は、「コントロールプレーンマシンセットのトラブルシューティング」の「劣化した etcd Operator のリカバリー」で etcd のリカバリー手順を参照してください。シングルノード上の OpenShift Container Platform は、「シングルノードで以前のクラスター状態に復元する」を参照してください。

重要

クラスターを復元する際に、同じ z-stream リリースから取得した etcd バックアップを使用する必要があります。たとえば、OpenShift Container Platform 4.20.2 クラスターは、4.20.2 から取得した etcd バックアップを使用する必要があります。

前提条件

  • インストール時に使用したものと同様、証明書ベースの kubeconfig ファイルを介して、cluster-admin ロールを持つユーザーとしてクラスターにアクセスします。
  • リカバリーホストとして使用する正常なコントロールプレーンホストがあること。
  • コントロールプレーンホストへの SSH アクセス権がある。
  • etcd スナップショットと静的 Pod のリソースの両方を含むバックアップディレクトリー (同じバックアップから取られるもの)。ディレクトリー内のファイル名は、snapshot_<datetimestamp>.db および static_kuberesources_<datetimestamp>.tar.gz の形式にする必要があります。
  • ノードはアクセス可能またはブート可能である。
重要

非リカバリーコントロールプレーンノードの場合は、SSH 接続を確立したり、静的 Pod を停止したりする必要はありません。他のリカバリー以外のコントロールプレーンマシンを 1 つずつ削除し、再作成します。

手順

  1. リカバリーホストとして使用するコントロールプレーンホストを選択します。これは、復元操作の実行対象とするホストです。
  2. リカバリーホストを含む、各コントロールプレーンノードへの SSH 接続を確立します。

    kube-apiserver は復元プロセスの開始後にアクセスできなくなるため、コントロールプレーンノードにはアクセスできません。このため、別のターミナルで各コントロールプレーンホストに SSH 接続を確立することが推奨されます。

    重要

    この手順を完了しないと、復元手順を完了するためにコントロールプレーンホストにアクセスすることができなくなり、この状態からクラスターを回復できなくなります。

  3. SSH を使用して各コントロールプレーンノードに接続し、次のコマンドを実行して etcd を無効にします。

    $ sudo -E /usr/local/bin/disable-etcd.sh
  4. etcd バックアップディレクトリーをリカバリーコントロールプレーンホストにコピーします。

    この手順では、etcd スナップショットおよび静的 Pod のリソースを含む backup ディレクトリーを、リカバリーコントロールプレーンホストの /home/core/ ディレクトリーにコピーしていることを前提としています。

  5. SSH を使用してリカバリーホストに接続し、次のコマンドを実行して以前のバックアップからクラスターを復元します。

    $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd-backup-directory>
  6. SSH セッションを終了します。
  7. API が応答したら、次のコマンドを実行して etcd Operator のクォーラムガードをオフにします。

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
  8. 次のコマンドを実行して、コントロールプレーンの回復の進行状況を監視します。

    $ oc adm wait-for-stable-cluster
    注記

    コントロールプレーンが回復するまでに最大 15 分かかります。

  9. 回復したら、次のコマンドを実行してクォーラムガードを有効にします。

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

トラブルシューティング

etcd 静的 Pod のロールアウトが進行していない場合は、次のコマンドを実行して、cluster-etcd-operator から強制的に再デプロイを実行できます。

$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$(date --rfc-3339=ns )"'"}}' --type=merge
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る