Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

etcd

OpenShift Container Platform 4.19

etcd による冗長性の確保

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、OpenShift Container Platform でのクラスター設定と回復力を確保するための信頼性の高いアプローチを提供する etcd の使用方法を説明しています。

第1章 etcd の概要
リンクのコピー

etcd (発音はエトシーディー) は、メモリーに完全に収まるマシンのクラスター全体に少量のデータを保存する、一貫性のある分散型キー値ストアです。etcd は多くのプロジェクトのコアコンポーネントであり、コンテナーオーケストレーションの標準システムである Kubernetes のプライマリーデータストアでもあります。

etcd を使用すると、いくつかの利点があります。

  • クラウドネイティブアプリケーションの一貫した稼働時間をサポートし、個々のサーバーに障害が発生した場合でも稼働を継続する
  • Kubernetes のすべてのクラスター状態を保存して複製する
  • 設定データを配布して、ノードの設定に冗長性と回復力を提供する
重要

デフォルトの etcd 設定は、コンテナーオーケストレーションを最適化します。最良の結果を得るには、設計どおりに使用してください。

1.1. etcd の仕組み
リンクのコピー

クラスターの設定と管理に対する信頼性の高いアプローチを確保するために、etcd は etcd Operator を使用します。Operator は、OpenShift Container Platform のような Kubernetes コンテナープラットフォームでの etcd の使用を簡素化します。

さらに、etcd Operator を使用して、OpenShift Container Platform コントロールプレーンの etcd クラスターをデプロイおよび管理できます。etcd Operator は、次の方法でクラスターの状態を管理します。

  • Kubernetes API を使用してクラスターの状態を監視する
  • 現在の状態と必要な状態の違いを分析する
  • etcd クラスター管理 API、Kubernetes API、またはその両方を使用して相違点を修正する

etcd は、常に更新されるクラスターの状態を保持します。この状態は継続的に持続するため、高い頻度で多数の小さな変化が発生します。そのため、etcd クラスターメンバーを高速で低レイテンシーの I/O でバックアップすることが重要になります。etcd のベストプラクティスの詳細は、「推奨される etcd プラクティス」を参照してください。

1.2. etcd のパフォーマンスについて
リンクのコピー

etcd は、レプリケートされたノードのクラスターとして動作する一貫性のある分散キー値ストアとして、1 つのノードをリーダーとして、他のノードをフォロワーとして選択する Raft アルゴリズムに従います。リーダーはシステムの現在の状態を維持し、フォロワーが最新の状態であることを確認します。

リーダーノードはログのレプリケーションを実行します。クライアントからの受信書き込みトランザクションを処理し、Raft ログエントリーを書き込み、それをフォロワーにブロードキャストします。

kube-apiserver などの etcd クライアントが、値の書き込みなどのクォーラムを必要とするアクションを要求している etcd メンバーに接続すると、etcd メンバーがフォロワーである場合は、トランザクションをリーダーに送信する必要があることを示すメッセージを返します。

etcd クライアントが、値の書き込みなど、クォーラムを必要とするアクションをリーダーに要求すると、リーダーはクライアントの接続を開いたままにして、ローカルの Raft ログを書き込み、そのログをフォロワーにブロードキャストし、過半数のフォロワーからログが正常にコミットされたことを確認するまで待機します。リーダーは etcd クライアントに確認応答を送信し、セッションを閉じます。フォロワーから障害通知が届き、コンセンサスが得られない場合、リーダーはエラーメッセージをクライアントに返し、セッションを終了します。

OpenShift Container Platform の etcd タイマー条件

OpenShift Container Platform は、各プラットフォームに最適化された etcd タイマーを維持します。OpenShift Container Platform には、それぞれのプラットフォームプロバイダーに最適化された検証済みの値が定められています。platform=none または platform=metal 値を持つデフォルトの etcd timers パラメーターは次のとおりです。 

- name: ETCD_ELECTION_TIMEOUT
1 

  value: "1000"
  ...
- name: ETCD_HEARTBEAT_INTERVAL
2 

  value: "100"
Copy to Clipboard Toggle word wrap
1
このタイムアウトは、フォロワーノードがリーダーになろうとする前にハートビートを聞かずに待機する時間です。
2
リーダーがフォロワーに対して、自分がまだリーダーであることを通知する頻度。

これらのパラメーターは、コントロールプレーンまたは etcd のすべての情報を提供するわけではありません。etcd クラスターは、ディスクのレイテンシーの影響を受けます。etcd は提案をログに保持する必要があるため、他のプロセスからのディスクアクティビティーによって fsync 待ち時間が長くなる可能性があります。その結果、etcd がハートビートを逃し、要求のタイムアウトや一時的なリーダーの喪失が発生する可能性があります。リーダーの喪失と再選出の間、Kubernetes API は、サービスに影響を与えるイベントやクラスターの不安定性を引き起こす要求を処理できません。

ディスクレイテンシーが etcd に与える影響

etcd クラスターは、ディスクのレイテンシーの影響を受けます。コントロールプレーン環境において etcd が経験するディスクレイテンシーを把握するには、Flexible I/O Tester (fio) テストまたはスイートを実行して、OpenShift Container Platform における etcd のディスクパフォーマンスを確認します。

重要

特定の時点でのディスクレイテンシーを測定するには、fio テストのみを使用します。このテストでは、実稼働環境の etcd で発生する長期的なディスクの動作やその他のディスクワークロードは考慮されていません。

次の例に示すように、最終レポートでディスクが etcd に適切であると分類されていることを確認します。 

...
99th percentile of fsync is 5865472 ns
99th percentile of the fsync is within the suggested threshold: - 20 ms, the disk can be used to host etcd
Copy to Clipboard Toggle word wrap

高レイテンシーのディスクが使用されている場合、次の例に示すように、そのディスクは etcd には推奨されないというメッセージが表示されます。 

...
99th percentile of fsync is 15865472 ns
99th percentile of the fsync is greater than the suggested value which is 20 ms, faster disks are suggested to host etcd for better performance
Copy to Clipboard Toggle word wrap

クラスターのデプロイメントが、推奨されるレイテンシーを満たさない etcd 用ディスクを使用している多くのデータセンターにまたがっている場合、サービスに影響を及ぼず障害が発生する可能性があります。さらに、コントロールプレーンが許容できるネットワークレイテンシーも大幅に低下します。

ネットワークレイテンシーとジッターが etcd に与える影響

最大転送単位 (MTU) の検出と検証のセクションで説明されているツールを使用して、平均および最大のネットワークレイテンシーを取得します。

ハートビート間隔の値は、メンバー間の平均往復時間 (RTT) の最大値にほぼ等しく、通常は往復時間の約 1.5 倍になります。OpenShift Container Platform のデフォルトのハートビート間隔は 100 ミリ秒であるため、コントロールプレーンノード間の推奨 RTT は 33 ミリ秒未満で、最大値は 66 ミリ秒未満 (66 ミリ秒 x 1.5 = 99 ミリ秒) になります。ネットワークレイテンシーがこれより大きいと、サービスに影響を与えるイベントが発生し、クラスターが不安定になる可能性があります。

ネットワークレイテンシーは、銅線、光ファイバー、無線、衛星などの伝送ネットワークの技術、伝送ネットワーク内のネットワーク機器の数や品質、その他の要因によって決まります。

正確な計算を行うには、ネットワークジッターを含むネットワークレイテンシーを考慮してください。ネットワークジッター とは、ネットワークレイテンシーのばらつきや、受信パケットの遅延時間の変動のことを指します。効率的なネットワーク状況では、ジッターはゼロになるはずです。ネットワークジッターは etcd のネットワークレイテンシーの計算に影響します。これは、時間の経過に伴う実際のネットワークレイテンシーは RTT にジッターを加算または減算したものになるためです。

たとえば、最大レイテンシーが 80 ミリ秒でジッターが 30 ミリ秒のネットワークでは、レイテンシーが 110 ミリ秒になり、etcd はハートビートを逃すことになります。この状態により、要求がタイムアウトし、リーダーが一時的に失われます。リーダーの喪失と再選出の間、Kubernetes API は、サービスに影響を与えるイベントやクラスターの不安定性を引き起こす要求を処理できません。

コンセンサスレイテンシーが etcd に与える影響

この手順はアクティブなクラスター上でのみ実行できます。クラスターのデプロイメントを計画している間に、ディスクまたはネットワークテストを完了する必要があります。このテストは、デプロイメント後のクラスターの健全性を検証および監視します。

etcdctl CLI を使用すると、etcd が経験するコンセンサスに達するまでのレイテンシーを監視できます。etcd Pod の 1 つを識別し、エンドポイントのヘルス情報を取得する必要があります。

etcd ピアの往復時間がパフォーマンスに与える影響

etcd ピアの往復時間は、ネットワークの往復時間と同じではありません。この計算は、メンバー間でレプリケーションがどれだけ速く発生するかに関するエンドツーエンドのテストメトリクスです。

etcd ピアの往復時間は、etcd がすべての etcd メンバー間におけるクライアント要求のレプリケートを完了するまでのレイテンシーを示すメトリクスです。OpenShift Container Platform コンソールは、さまざまな etcd メトリクスを視覚化するためのダッシュボードを提供します。コンソールで、Observe → Dashboards をクリックします。ドロップダウンリストから、etcd を選択します。

etcd Dashboard ページのほぼ最後に、etcd ピアの往復時間をまとめたグラフがあります。

データベースサイズが etcd に与える影響

etcd データベースのサイズは、etcd デフラグプロセスの完了時間に直接影響します。OpenShift Container Platform は、少なくとも 45% の断片化を検出すると、一度に 1 つの etcd メンバーで etcd デフラグを自動的に実行します。デフラグ処理中は、etcd メンバーは要求を処理できません。小さな etcd データベースでは、デフラグ処理は 1 秒未満で実行されます。etcd データベースが大きい場合、ディスクレイテンシーが断片化時間に直接影響し、デフラグの実行中に操作がブロックされるため、追加のレイテンシーが発生します。

etcd データベースのサイズは、ネットワークパーティションによってコントロールプレーンノードが一定期間分離され、通信が再確立された後にコントロールプレーンを同期する必要がある場合に考慮すべき要素です。

etcd データベースのサイズはシステム内の Operator とアプリケーションに依存するため、そのサイズを制御するためのオプションは最小限しかありません。システムが動作するレイテンシー範囲を検討するときは、etcd データベースのサイズごとに同期またはデフラグの影響を考慮してください。

その影響の大きさは、デプロイメントごとに異なります。デフラグが完了するまでの時間は、etcd メンバーがデフラグ処理中に更新を受け入れることができないため、トランザクションレートの低下を引き起こします。同様に、変更率の高い大規模データベースの etcd 再同期にかかる時間は、システム上のトランザクションレートとトランザクションレイテンシーに影響します。計画が必要な影響の種類は、次の 2 つの例を検討してください。

データベースサイズに基づいた etcd デフラグの影響に関する最初の例は、1 GB の etcd データベースを 80 Mb/秒の低速 7200 RPM ディスクに書き込むのに約 1 分 40 秒かかることです。このようなシナリオでは、デフラグが完了するまでに、デフラグプロセスに少なくともこれだけの時間がかかります。

データベースサイズが etcd 同期に与える影響の 2 番目の例は、コントロールプレーンノードの 1 つが切断されている間に etcd データベースの 10% が変更された場合、同期では少なくとも 100 MB を転送する必要があるということです。1 Gbps リンクで 100 MB を転送するには 800 ミリ秒かかります。Kubernetes API を使用した定期的なトランザクションを実行するクラスターでは、etcd データベースのサイズが大きくなるほど、ネットワークの不安定性が増し、コントロールプレーンの不安定性も生じます。

OpenShift Container Platform では、etcd ダッシュボードに etcd データベースのサイズを報告するグラフがあります。または、etcdctl ツールを使用して CLI からデータベースサイズを取得することもできます。 

# oc get pods -n openshift-etcd -l app=etcd
Copy to Clipboard Toggle word wrap

出力例

NAME      READY   STATUS    RESTARTS   AGE
etcd-m0   4/4     Running   4          22h
etcd-m1   4/4     Running   4          22h
etcd-m2   4/4     Running   4          22h
Copy to Clipboard Toggle word wrap 

# oc exec -t etcd-m0 -- etcdctl endpoint status -w simple | cut -d, -f 1,3,4
Copy to Clipboard Toggle word wrap

出力例

https://198.18.111.12:2379, 3.5.6, 1.1 GB
https://198.18.111.13:2379, 3.5.6, 1.1 GB
https://198.18.111.14:2379, 3.5.6, 1.1 GB
Copy to Clipboard Toggle word wrap

Kubernetes API トランザクションレートが etcd に与える影響

ストレッチコントロールプレーンを使用している場合、Kebernetes API トランザクションレートは、特定のデプロイメントの特性によって異なります。これは、etcd ディスクのレイテンシー、etcd 往復時間、および API に書き込まれるオブジェクトのサイズの組み合わせによって異なります。その結果、ストレッチコントロールプレーンを使用する場合、クラスター管理者は自分たちの環境で維持可能なトランザクションレートを把握するために、環境のテストを行う必要があります。この目的には kube-burner ツールを使用できます。

環境に対する Kubernetes API トランザクションレートの決定

Kubernetes API のトランザクションレートは、測定せずに判断できません。コントロールプレーンの負荷テストに使用されるツールの 1 つは kube-burner です。バイナリーは、OpenShift Container Platform クラスターをテストするための OpenShift Container Platform ラッパーを提供します。これは、クラスターまたはノードの密度をテストするために使用されます。コントロールプレーンをテストするために、kube-burner ocp には、cluster-density、cluster-density-v2、cluster-density-ms の 3 つのワークロードプロファイルがあります。各ワークロードプロファイルは、コントロールをロードするように設計された一連のリソースを作成します。

第3章 etcd のパフォーマンスに関する考慮事項
リンクのコピー

OpenShift Container Platform で etcd の最適なパフォーマンスとスケーラビリティーを確保するには、次のプラクティスを完了してください。

3.1. etcd のノードスケーリング
リンクのコピー

一般に、クラスターには 3 つのコントロールプレーンノードが必要です。ただし、クラスターがベアメタルプラットフォームにインストールされている場合、クラスターは最大 5 つのコントロールプレーンノードを持つことができます。既存のベアメタルクラスターのコントロールプレーンノードが 5 個未満の場合、インストール後のタスクとしてクラスターをスケールアップできます。

たとえば、インストール後に 3 ノードから 4 ノードに拡張するには、ホストを追加してコントロールプレーンノードとしてインストールします。次に、etcd Operator は追加のコントロールプレーンノードを考慮してそれに応じてスケーリングします。

クラスターを 4 つまたは 5 つのコントロールプレーンノードにスケーリングできるのは、ベアメタルプラットフォームのみです。

Assisted Installer を使用してコントロールプレーンノードをスケーリングする方法の詳細は、「API を使用したホストの追加」および「正常なクラスター内のコントロールプレーンノードの置き換え」を参照してください。

次の表は、さまざまなサイズのクラスターの障害許容度を示しています。

Expand
表3.1 クラスターサイズによる障害許容度
クラスターサイズ過半数障害許容度

1 ノード

1

0

3 ノード

2

1

4 ノード

3

1

5 ノード

3

2

クォーラム損失からの回復の詳細は、「以前のクラスター状態への復元」を参照してください。

3.2. etcd を別のディスクに移動する
リンクのコピー

etcd を共有ディスクから別のディスクに移動して、パフォーマンスの問題を防止または解決できます。

Machine Config Operator (MCO) は、OpenShift Container Platform 4.19 コンテナーストレージのセカンダリーディスクをマウントします。

注記

このエンコードされたスクリプトは、次のデバイスタイプのデバイス名のみをサポートします。

SCSI または SATA
/dev/sd*
仮想デバイス
/dev/vd*
NVMe
/dev/nvme*[0-9]*n*

制限事項

  • 新しいディスクがクラスターに接続されると、etcd データベースがルートマウントの一部になります。プライマリーノードが再作成されるとき、ルートマウントはセカンダリーディスクまたは目的のディスクの一部ではありません。そのため、プライマリーノードは個別の /var/lib/etcd マウントを作成しません。

前提条件

  • クラスターの etcd データのバックアップを作成している。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限でクラスターにアクセスできる。
  • マシン設定をアップロードする前に、追加のディスクを追加する。
  • MachineConfigPool は metadata.labels[machineconfiguration.openshift.io/role] と一致する必要があります。これは、コントローラー、ワーカー、またはカスタムプールに適用されます。
注記

この手順では、/var/ などのルートファイルシステムの一部を、インストール済みノードの別のディスクまたはパーティションに移動しません。

重要

コントロールプレーンマシンセットを使用する場合は、この手順がサポートされません。

手順

  1. 新しいディスクをクラスターに接続し、デバッグシェルで lsblk コマンドを実行して、ディスクがノード内で検出されることを確認します。 

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap 
    # lsblk
    Copy to Clipboard Toggle word wrap

    lsblk コマンドで報告された新しいディスクのデバイス名をメモします。

  2. 次のスクリプトを作成し、名前を etcd-find-secondary-device.sh にします。 

    #!/bin/bash
set -uo pipefail

for device in <device_type_glob>; do
    1 
    
/usr/sbin/blkid "${device}" &> /dev/null
 if [ $? == 2  ]; then
    echo "secondary device found ${device}"
    echo "creating filesystem for etcd mount"
    mkfs.xfs -L var-lib-etcd -f "${device}" &> /dev/null
    udevadm settle
    touch /etc/var-lib-etcd-mount
    exit
 fi
done
echo "Couldn't find secondary block device!" >&2
exit 77
    Copy to Clipboard Toggle word wrap
    1
    <device_type_glob> は、ブロックデバイスタイプのシェル glob に置き換えます。SCSI または SATA ドライブの場合は /dev/sd* を使用し、仮想ドライブの場合は /dev/vd* を使用し、NVMe ドライブの場合は /dev/nvme*[0-9]*n* を使用します。

  3. etcd-find-secondary-device.sh スクリプトから base64 でエンコードされた文字列を作成し、その内容をメモします。 

    $ base64 -w0 etcd-find-secondary-device.sh
    Copy to Clipboard Toggle word wrap

  4. 次のような内容を含む etcd-mc.yml という名前の MachineConfig YAML ファイルを作成します。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 98-var-lib-etcd
spec:
  config:
    ignition:
      version: 3.5.0
    storage:
      files:
        - path: /etc/find-secondary-device
          mode: 0755
          contents:
            source: data:text/plain;charset=utf-8;base64,<encoded_etcd_find_secondary_device_script>
    1 
    
    systemd:
      units:
        - name: find-secondary-device.service
          enabled: true
          contents: |
            [Unit]
            Description=Find secondary device
            DefaultDependencies=false
            After=systemd-udev-settle.service
            Before=local-fs-pre.target
            ConditionPathExists=!/etc/var-lib-etcd-mount

            [Service]
            RemainAfterExit=yes
            ExecStart=/etc/find-secondary-device

            RestartForceExitStatus=77

            [Install]
            WantedBy=multi-user.target
        - name: var-lib-etcd.mount
          enabled: true
          contents: |
            [Unit]
            Before=local-fs.target

            [Mount]
            What=/dev/disk/by-label/var-lib-etcd
            Where=/var/lib/etcd
            Type=xfs
            TimeoutSec=120s

            [Install]
            RequiredBy=local-fs.target
        - name: sync-var-lib-etcd-to-etcd.service
          enabled: true
          contents: |
            [Unit]
            Description=Sync etcd data if new mount is empty
            DefaultDependencies=no
            After=var-lib-etcd.mount var.mount
            Before=crio.service

            [Service]
            Type=oneshot
            RemainAfterExit=yes
            ExecCondition=/usr/bin/test ! -d /var/lib/etcd/member
            ExecStart=/usr/sbin/setsebool -P rsync_full_access 1
            ExecStart=/bin/rsync -ar /sysroot/ostree/deploy/rhcos/var/lib/etcd/ /var/lib/etcd/
            ExecStart=/usr/sbin/semanage fcontext -a -t container_var_lib_t '/var/lib/etcd(/.*)?'
            ExecStart=/usr/sbin/setsebool -P rsync_full_access 0
            TimeoutSec=0

            [Install]
            WantedBy=multi-user.target graphical.target
        - name: restorecon-var-lib-etcd.service
          enabled: true
          contents: |
            [Unit]
            Description=Restore recursive SELinux security contexts
            DefaultDependencies=no
            After=var-lib-etcd.mount
            Before=crio.service

            [Service]
            Type=oneshot
            RemainAfterExit=yes
            ExecStart=/sbin/restorecon -R /var/lib/etcd/
            TimeoutSec=0

            [Install]
            WantedBy=multi-user.target graphical.target
    Copy to Clipboard Toggle word wrap
    1
    <encoded_etcd_find_secondary_device_script> を、メモしておいたエンコードされたスクリプトの内容に置き換えます。

  5. 作成した MachineConfig YAML ファイルを適用します。 

    $ oc create -f etcd-mc.yml
    Copy to Clipboard Toggle word wrap

検証手順

  • ノードのデバッグシェルで grep/var/lib/etcd/proc/mounts コマンドを実行して、ディスクがマウントされていることを確認します。 

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap 
    # grep -w "/var/lib/etcd" /proc/mounts
    Copy to Clipboard Toggle word wrap

    出力例

    /dev/sdb /var/lib/etcd xfs rw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0
    Copy to Clipboard Toggle word wrap

3.3. etcd データのデフラグ
リンクのコピー

大規模で密度の高いクラスターの場合に、キースペースが過剰に拡大し、スペースのクォータを超過すると、etcd は低下するパフォーマンスの影響を受ける可能性があります。etcd を定期的に維持および最適化して、データストアのスペースを解放します。Prometheus で etcd メトリックをモニターし、必要に応じてデフラグします。そうしないと、etcd はクラスター全体のアラームを発生させ、クラスターをメンテナンスモードにして、キーの読み取りと削除のみを受け入れる可能性があります。

これらの主要な指標をモニターします。

  • etcd_server_quota_backend_bytes、これは現在のクォータ制限です
  • etcd_mvcc_db_total_size_in_use_in_bytes、これはヒストリーコンパクション後の実際のデータベース使用状況を示します。
  • etcd_mvcc_db_total_size_in_bytes はデフラグ待ちの空き領域を含むデータベースサイズを表します。

etcd データをデフラグし、etcd 履歴の圧縮などのディスクの断片化を引き起こすイベント後にディスク領域を回収します。

履歴の圧縮は 5 分ごとに自動的に行われ、これによりバックエンドデータベースにギャップが生じます。この断片化された領域は etcd が使用できますが、ホストファイルシステムでは利用できません。ホストファイルシステムでこの領域を使用できるようにするには、etcd をデフラグする必要があります。

デフラグは自動的に行われますが、手動でトリガーすることもできます。

注記

etcd Operator はクラスター情報を使用してユーザーの最も効率的な操作を決定するため、ほとんどの場合、自動デフラグが適しています。

3.3.1. 自動デフラグ
リンクのコピー

etcd Operator はディスクを自動的にデフラグします。手動による介入は必要ありません。

以下のログのいずれかを表示して、デフラグプロセスが成功したことを確認します。

  • etcd ログ
  • cluster-etcd-operator Pod
  • Operator ステータスのエラーログ
警告

自動デフラグにより、Kubernetes コントローラーマネージャーなどのさまざまな OpenShift コアコンポーネントでリーダー選出の失敗が発生し、失敗したコンポーネントの再起動がトリガーされる可能性があります。再起動は無害であり、次に実行中のインスタンスへのフェイルオーバーをトリガーするか、再起動後にコンポーネントが再び作業を再開します。

最適化が成功した場合のログ出力の例

etcd member has been defragmented: <member_name>, memberID: <member_id>
Copy to Clipboard Toggle word wrap

最適化に失敗した場合のログ出力の例

failed defrag on member: <member_name>, memberID: <member_id>: <error_message>
Copy to Clipboard Toggle word wrap

3.3.2. 手動デフラグ
リンクのコピー

Prometheus アラートは、手動でのデフラグを使用する必要がある場合を示します。アラートは次の 2 つの場合に表示されます。

  • etcd が使用可能なスペースの 50% 以上を 10 分を超過して使用する場合
  • etcd が合計データベースサイズの 50% 未満を 10 分を超過してアクティブに使用している場合

また、PromQL 式を使用した最適化によって解放される etcd データベースのサイズ (MB 単位) を確認することで、最適化が必要かどうかを判断することもできます ((etcd_mvcc_db_total_size_in_bytes - etcd_mvcc_db_total_size_in_use_in_bytes)/1024/1024)。

警告

etcd のデフラグはプロセスを阻止するアクションです。etcd メンバーはデフラグが完了するまで応答しません。このため、各 Pod のデフラグアクションごとに少なくとも 1 分間待機し、クラスターが回復できるようにします。

以下の手順に従って、各 etcd メンバーで etcd データをデフラグします。

前提条件

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

手順

  1. リーダーを最後にデフラグする必要があるため、どの etcd メンバーがリーダーであるかを判別します。

    1. etcd Pod のリストを取得します。 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide
      Copy to Clipboard Toggle word wrap

      出力例

      etcd-ip-10-0-159-225.example.redhat.com                3/3     Running     0          175m   10.0.159.225   ip-10-0-159-225.example.redhat.com   <none>           <none>
etcd-ip-10-0-191-37.example.redhat.com                 3/3     Running     0          173m   10.0.191.37    ip-10-0-191-37.example.redhat.com    <none>           <none>
etcd-ip-10-0-199-170.example.redhat.com                3/3     Running     0          176m   10.0.199.170   ip-10-0-199-170.example.redhat.com   <none>           <none>
      Copy to Clipboard Toggle word wrap

    2. Pod を選択し、以下のコマンドを実行して、どの etcd メンバーがリーダーであるかを判別します。 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table
      Copy to Clipboard Toggle word wrap

      出力例

      Defaulting container name to etcdctl.
Use 'oc describe pod/etcd-ip-10-0-159-225.example.redhat.com -n openshift-etcd' to see all of the containers in this pod.
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      Copy to Clipboard Toggle word wrap

      この出力の IS LEADER 列に基づいて、https://10.0.199.170:2379 エンドポイントがリーダーになります。このエンドポイントを直前の手順の出力に一致させると、リーダーの Pod 名は etcd-ip-10-0-199-170.example.redhat.com になります。

  2. etcd メンバーのデフラグ。

    1. 実行中の etcd コンテナーに接続し、リーダーでは ない Pod の名前を渡します。 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
      Copy to Clipboard Toggle word wrap

    2. ETCDCTL_ENDPOINTS 環境変数の設定を解除します。 

      sh-4.4# unset ETCDCTL_ENDPOINTS
      Copy to Clipboard Toggle word wrap

    3. etcd メンバーのデフラグを実行します。 

      sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag
      Copy to Clipboard Toggle word wrap

      出力例

      Finished defragmenting etcd member[https://localhost:2379]
      Copy to Clipboard Toggle word wrap

      タイムアウトエラーが発生した場合は、コマンドが正常に実行されるまで --command-timeout の値を増やします。

    4. データベースサイズが縮小されていることを確認します。 

      sh-4.4# etcdctl endpoint status -w table --cluster
      Copy to Clipboard Toggle word wrap

      出力例

      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.5.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.5.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        |
      1 
      
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.5.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      Copy to Clipboard Toggle word wrap

      この例では、この etcd メンバーのデータベースサイズは、開始時のサイズの 104 MB ではなく 41 MB です。

    5. これらの手順を繰り返して他の etcd メンバーのそれぞれに接続し、デフラグします。常に最後にリーダーをデフラグします。

      etcd Pod が回復するように、デフラグアクションごとに 1 分以上待機します。etcd Pod が回復するまで、etcd メンバーは応答しません。

  3. 領域のクォータの超過により NOSPACE アラームがトリガーされる場合、それらをクリアします。

    1. NOSPACE アラームがあるかどうかを確認します。 

      sh-4.4# etcdctl alarm list
      Copy to Clipboard Toggle word wrap

      出力例

      memberID:12345678912345678912 alarm:NOSPACE
      Copy to Clipboard Toggle word wrap

    2. アラームをクリアします。 

      sh-4.4# etcdctl alarm disarm
      Copy to Clipboard Toggle word wrap

3.4. etcd のチューニングパラメーターの設定
リンクのコピー

コントロールプレーンのハードウェア速度を "Standard"、"Slower"、またはデフォルトの "" に設定できます。

デフォルト設定では、使用する速度をシステムが決定できます。システムは以前のバージョンから値を選択できるため、この値により、この機能が存在しないバージョンからのアップグレードが可能になります。

他の値のいずれかを選択すると、デフォルトが上書きされます。タイムアウトまたはハートビートの欠落が原因でリーダーの選出が多数発生し、システムが "" または "Standard" に設定されている場合は、ハードウェア速度を "Slower" に設定して、レイテンシーの増加に対するシステムの耐性を高めます。

3.4.1. ハードウェア速度許容値の変更
リンクのコピー

etcd のハードウェア速度許容値を変更するには、次の手順を実行します。

手順

  1. 次のコマンドを入力して、現在の値を確認します。 

    $ oc describe etcd/cluster | grep "Control Plane Hardware Speed"
    Copy to Clipboard Toggle word wrap

    出力例

    Control Plane Hardware Speed:  <VALUE>
    Copy to Clipboard Toggle word wrap

    注記

    出力が空の場合、フィールドは設定されていないため、デフォルト ("") として考慮される必要があります。

  2. 次のコマンドを入力して値を変更します。<value> を有効な値のいずれかに置き換えます (""、"Standard"、または "Slower")。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"controlPlaneHardwareSpeed": "<value>"}}'
    Copy to Clipboard Toggle word wrap

    次の表は、各プロファイルのハートビート間隔とリーダー選出タイムアウトを示しています。これらの値は変更になる可能性があります。

    Expand

    プロファイル

    ETCD_HEARTBEAT_INTERVAL

    ETCD_LEADER_ELECTION_TIMEOUT

    ""

    プラットフォームによって異なる

    プラットフォームによって異なる

    Standard

    100

    1000

    Slower

    500

    2500

  3. 出力を確認します。

    出力例

    etcd.operator.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

    有効な値以外の値を入力すると、エラー出力が表示されます。たとえば、"Faster" 値を入力すると、出力は次のようになります。

    出力例

    The Etcd "cluster" is invalid: spec.controlPlaneHardwareSpeed: Unsupported value: "Faster": supported values: "", "Standard", "Slower"
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを入力して、値が変更したことを確認します。 

    $ oc describe etcd/cluster | grep "Control Plane Hardware Speed"
    Copy to Clipboard Toggle word wrap

    出力例

    Control Plane Hardware Speed:  ""
    Copy to Clipboard Toggle word wrap

  5. etcd Pod がロールアウトされるまで待ちます。 

    $ oc get pods -n openshift-etcd -w
    Copy to Clipboard Toggle word wrap

    次の出力は、master-0 の予期されるエントリーを示しています。続行する前に、すべてのマスターのステータスが 4/4 Running になるまで待ちます。

    出力例

    installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Pending             0          0s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Pending             0          0s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     ContainerCreating   0          0s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     ContainerCreating   0          1s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           1/1     Running             0          2s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Completed           0          34s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Completed           0          36s
installer-9-ci-ln-qkgs94t-72292-9clnd-master-0           0/1     Completed           0          36s
etcd-guard-ci-ln-qkgs94t-72292-9clnd-master-0            0/1     Running             0          26m
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  4/4     Terminating         0          11m
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  4/4     Terminating         0          11m
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  0/4     Pending             0          0s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  0/4     Init:1/3            0          1s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  0/4     Init:2/3            0          2s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  0/4     PodInitializing     0          3s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  3/4     Running             0          4s
etcd-guard-ci-ln-qkgs94t-72292-9clnd-master-0            1/1     Running             0          26m
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  3/4     Running             0          20s
etcd-ci-ln-qkgs94t-72292-9clnd-master-0                  4/4     Running             0          20s
    Copy to Clipboard Toggle word wrap

  6. 次のコマンドを入力して値を確認します。 

    $ oc describe -n openshift-etcd pod/<ETCD_PODNAME> | grep -e HEARTBEAT_INTERVAL -e ELECTION_TIMEOUT
    Copy to Clipboard Toggle word wrap
    注記

    これらの値はデフォルトから変更されていない可能性があります。

3.5. etcd のデータベースサイズを増やす
リンクのコピー

各 etcd インスタンスのディスククォータをギビバイト (GiB) 単位で設定できます。etcd インスタンスにディスククォータを設定する場合は、8 から 32 までの整数値を指定できます。デフォルト値は 8 です。増加値のみ指定できます。

low space アラートが表示された場合は、ディスククォータを増やすことを推奨します。このアラートは、自動コンパクションおよびデフラグにもかかわらず、クラスターが大きすぎて etcd に収まらないことを示します。このアラートが表示された場合、etcd のスペースが不足すると書き込みが失敗するため、すぐにディスククォータを増やす必要があります。

ディスククォータを増やすことが推奨されるもう 1 つのシナリオは、excessive database growth アラートが発生した場合です。このアラートは、今後 4 時間以内にデータベースが大きくなりすぎる可能性があることを警告しています。このシナリオでは、最終的に low space アラートが表示されたり、書き込みが失敗したりしないように、ディスククォータを増やすことを検討してください。

ディスククォータを増やしても、指定したディスク領域はすぐには予約されません。代わりに、etcd は必要に応じてそのサイズまで拡張できます。etcd が、ディスククォータに指定した値よりも大きい専用ディスク上で実行されていることを確認します。

大規模な etcd データベースの場合、コントロールプレーンノードに追加のメモリーとストレージが必要です。API サーバーキャッシュを考慮する必要があるため、最小メモリー要件は etcd データベースの設定サイズの 3 倍以上になります。

重要

etcd のデータベースサイズを増やす機能は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

3.5.1. etcd データベースのサイズを変更する
リンクのコピー

etcd のデータベースサイズを変更するには、次の手順を実行します。

手順

  1. 次のコマンドを入力して、各 etcd インスタンスのディスククォータの現在の値を確認します。 

    $ oc describe etcd/cluster | grep "Backend Quota"
    Copy to Clipboard Toggle word wrap

    出力例

    Backend Quota Gi B: <value>
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力して、ディスククォータの値を変更します。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"backendQuotaGiB": <value>}}'
    Copy to Clipboard Toggle word wrap

    出力例

    etcd.operator.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

検証

  1. 次のコマンドを入力して、ディスククォータの新しい値が設定されていることを確認します。 

    $ oc describe etcd/cluster | grep "Backend Quota"
    Copy to Clipboard Toggle word wrap

    etcd Operator は、新しい値を使用して etcd インスタンスを自動的にロールアウトします。

  2. 次のコマンドを入力して、etcd Pod が起動して実行されていることを確認します。 

    $ oc get pods -n openshift-etcd
    Copy to Clipboard Toggle word wrap

    次の出力は、予想されるエントリーを示しています。

    出力例

    NAME                                                   READY   STATUS      RESTARTS   AGE
etcd-ci-ln-b6kfsw2-72292-mzwbq-master-0                4/4     Running     0          39m
etcd-ci-ln-b6kfsw2-72292-mzwbq-master-1                4/4     Running     0          37m
etcd-ci-ln-b6kfsw2-72292-mzwbq-master-2                4/4     Running     0          41m
etcd-guard-ci-ln-b6kfsw2-72292-mzwbq-master-0          1/1     Running     0          51m
etcd-guard-ci-ln-b6kfsw2-72292-mzwbq-master-1          1/1     Running     0          49m
etcd-guard-ci-ln-b6kfsw2-72292-mzwbq-master-2          1/1     Running     0          54m
installer-5-ci-ln-b6kfsw2-72292-mzwbq-master-1         0/1     Completed   0          51m
installer-7-ci-ln-b6kfsw2-72292-mzwbq-master-0         0/1     Completed   0          46m
installer-7-ci-ln-b6kfsw2-72292-mzwbq-master-1         0/1     Completed   0          44m
installer-7-ci-ln-b6kfsw2-72292-mzwbq-master-2         0/1     Completed   0          49m
installer-8-ci-ln-b6kfsw2-72292-mzwbq-master-0         0/1     Completed   0          40m
installer-8-ci-ln-b6kfsw2-72292-mzwbq-master-1         0/1     Completed   0          38m
installer-8-ci-ln-b6kfsw2-72292-mzwbq-master-2         0/1     Completed   0          42m
revision-pruner-7-ci-ln-b6kfsw2-72292-mzwbq-master-0   0/1     Completed   0          43m
revision-pruner-7-ci-ln-b6kfsw2-72292-mzwbq-master-1   0/1     Completed   0          43m
revision-pruner-7-ci-ln-b6kfsw2-72292-mzwbq-master-2   0/1     Completed   0          43m
revision-pruner-8-ci-ln-b6kfsw2-72292-mzwbq-master-0   0/1     Completed   0          42m
revision-pruner-8-ci-ln-b6kfsw2-72292-mzwbq-master-1   0/1     Completed   0          42m
revision-pruner-8-ci-ln-b6kfsw2-72292-mzwbq-master-2   0/1     Completed   0          42m
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを入力して、etcd Pod のディスククォータ値が更新されていることを確認します。 

    $ oc describe -n openshift-etcd pod/<etcd_podname> | grep "ETCD_QUOTA_BACKEND_BYTES"
    Copy to Clipboard Toggle word wrap

    値はデフォルト値の 8 から変更されていない可能性があります。

    出力例

    ETCD_QUOTA_BACKEND_BYTES:                               8589934592
    Copy to Clipboard Toggle word wrap

    注記

    設定する値は GiB 単位の整数ですが、出力に表示される値はバイトに変換されます。

3.5.2. トラブルシューティング
リンクのコピー

etcd のデータベースサイズを増やそうとしたときに問題が発生した場合、次のトラブルシューティング手順が役立つ場合があります。

3.5.2.1. 値が小さすぎる
リンクのコピー

指定した値が 8 未満の場合、次のエラーメッセージが表示されます。 

$ oc patch etcd/cluster --type=merge -p '{"spec": {"backendQuotaGiB": 5}}'
Copy to Clipboard Toggle word wrap

エラーメッセージの例

The Etcd "cluster" is invalid:
* spec.backendQuotaGiB: Invalid value: 5: spec.backendQuotaGiB in body should be greater than or equal to 8
* spec.backendQuotaGiB: Invalid value: "integer": etcd backendQuotaGiB may not be decreased
Copy to Clipboard Toggle word wrap

この問題を解決するには、8 - 32 の間の整数を指定します。

3.5.2.2. 値が大きすぎる
リンクのコピー

指定した値が 32 より大きい場合、次のエラーメッセージが表示されます。 

$ oc patch etcd/cluster --type=merge -p '{"spec": {"backendQuotaGiB": 64}}'
Copy to Clipboard Toggle word wrap

エラーメッセージの例

The Etcd "cluster" is invalid: spec.backendQuotaGiB: Invalid value: 64: spec.backendQuotaGiB in body should be less than or equal to 32
Copy to Clipboard Toggle word wrap

この問題を解決するには、8 - 32 の間の整数を指定します。

3.5.2.3. 価値が下がっている
リンクのコピー

値が 8 - 32 の有効な値に設定されている場合、値を減らすことはできません。減らそうとすると、エラーメッセージが表示されます。

  1. 次のコマンドを入力して現在の値を確認します。 

    $ oc describe etcd/cluster | grep "Backend Quota"
    Copy to Clipboard Toggle word wrap

    出力例

    Backend Quota Gi B: 10
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力してディスククォータ値を減らします。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"backendQuotaGiB": 8}}'
    Copy to Clipboard Toggle word wrap

    エラーメッセージの例

    The Etcd "cluster" is invalid: spec.backendQuotaGiB: Invalid value: "integer": etcd backendQuotaGiB may not be decreased
    Copy to Clipboard Toggle word wrap

  3. この問題を解決するには、10 より大きい整数を指定します。

第4章 etcd データのバックアップと復元
リンクのコピー

4.1. etcd データのバックアップと復元
リンクのコピー

OpenShift Container Platform のキー値ストアとして、etcd はすべてのリソースオブジェクトの状態を保持します。

クラスターの etcd データを定期的にバックアップし、セキュアな場所 (理想的には OpenShift Container Platform 環境の外部) に保存します。インストールの 24 時間後に行われる最初の証明書のローテーションが完了するまで etcd のバックアップを実行することはできません。ローテーションの完了前に実行すると、バックアップに期限切れの証明書が含まれることになります。etcd スナップショットは I/O コストが高いため、ピーク使用時間以外に etcd バックアップを取得することも推奨します。

クラスターを更新する前に、必ず etcd のバックアップを作成してください。クラスターを復元するときに、同じ z-stream リリースから取得した etcd バックアップを使用する必要があるため、更新する前にバックアップを作成することが重要です。たとえば、OpenShift Container Platform 4.17.5 クラスターでは、4.17.5 から取得した etcd バックアップを使用する必要があります。

重要

コントロールプレーンホストでバックアップスクリプトの単一の呼び出しを実行して、クラスターの etcd データをバックアップします。各コントロールプレーンホストのバックアップを取得しないでください。

etcd のバックアップを作成した後に、クラスターの直前の状態への復元 を実行できます。

4.1.1. etcd データのバックアップ
リンクのコピー

以下の手順に従って、etcd スナップショットを作成し、静的 Pod のリソースをバックアップして etcd データをバックアップします。このバックアップは保存でき、etcd を復元する必要がある場合に後で使用することができます。

重要

単一のコントロールプレーンホストからのバックアップのみを保存します。クラスター内の各コントロールプレーンホストからのバックアップは取得しないでください。

前提条件

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

  • クラスター全体のプロキシーが有効になっているかどうかを確認している。

    ヒント

    oc get proxy cluster -o yaml の出力を確認して、プロキシーが有効にされているかどうかを確認できます。プロキシーは、httpProxy、httpsProxy、および noProxy フィールドに値が設定されている場合に有効にされます。

手順

  1. コントロールプレーンノードの root としてデバッグセッションを開始します。 

    $ oc debug --as-root node/<node_name>
    Copy to Clipboard Toggle word wrap

  2. デバッグシェルで root ディレクトリーを /host に変更します。 

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap

  3. クラスター全体のプロキシーが有効になっている場合は、次のコマンドを実行して、NO_PROXY、HTTP_PROXY、および HTTPS_PROXY 環境変数をエクスポートします。 

    $ export HTTP_PROXY=http://<your_proxy.example.com>:8080
    Copy to Clipboard Toggle word wrap 
    $ export HTTPS_PROXY=https://<your_proxy.example.com>:8080
    Copy to Clipboard Toggle word wrap 
    $ export NO_PROXY=<example.com>
    Copy to Clipboard Toggle word wrap

  4. デバッグシェルで cluster-backup.sh スクリプトを実行し、バックアップの保存先となる場所を渡します。

    ヒント

    cluster-backup.sh スクリプトは etcd Cluster Operator のコンポーネントとして維持され、etcdctl snapshot save コマンドに関連するラッパーです。 

    sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup
    Copy to Clipboard Toggle word wrap

    スクリプトの出力例

    found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6
found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7
found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3
ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1
etcdctl version: 3.4.14
API version: 3.4
{"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"}
{"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"}
{"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
{"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459}
{"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"}
Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db
{"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336}
snapshot db and kube resources are successfully saved to /home/core/assets/backup
    Copy to Clipboard Toggle word wrap

    この例では、コントロールプレーンホストの /home/core/assets/backup/ ディレクトリーにファイルが 2 つ作成されます。

    • snapshot_<datetimestamp>.db: このファイルは etcd スナップショットです。cluster-backup.sh スクリプトで、その有効性を確認します。

    • static_kuberesources_<datetimestamp>.tar.gz: このファイルには、静的 Pod のリソースが含まれます。etcd 暗号化が有効にされている場合、etcd スナップショットの暗号化キーも含まれます。

      注記

      etcd 暗号化が有効にされている場合、セキュリティー上の理由から、この 2 つ目のファイルを etcd スナップショットとは別に保存することが推奨されます。ただし、このファイルは etcd スナップショットから復元するために必要になります。

      etcd 暗号化はキーではなく値のみを暗号化することに注意してください。つまり、リソースタイプ、namespace、およびオブジェクト名は暗号化されません。

4.1.2. 自動 etcd バックアップの作成
リンクのコピー

etcd の自動バックアップ機能は、繰り返しバックアップとシングルバックアップの両方をサポートします。繰り返しバックアップでは、ジョブがトリガーされるたびにシングルバックアップを開始する cron ジョブが作成されます。

重要

etcd バックアップの自動化はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

etcd の自動バックアップを有効にするには、次の手順を実行します。

警告

クラスターで TechPreviewNoUpgrade 機能セットを有効にすると、マイナーバージョンの更新ができなくなります。TechPreviewNoUpgrade 機能セットは無効にできません。実稼働クラスターではこの機能セットを有効にしないでください。

前提条件

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

手順

  1. 次の内容で、enable-tech-preview-no-upgrade.yaml という名前の FeatureGate カスタムリソース (CR) ファイルを作成します。 

    apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
  name: cluster
spec:
  featureSet: TechPreviewNoUpgrade
    Copy to Clipboard Toggle word wrap

  2. CR を適用し、自動バックアップを有効にします。 

    $ oc apply -f enable-tech-preview-no-upgrade.yaml
    Copy to Clipboard Toggle word wrap

  3. 関連する API を有効にするのに時間がかかります。次のコマンドを実行して、カスタムリソース定義 (CRD) が作成されたことを確認します。 

    $ oc get crd | grep backup
    Copy to Clipboard Toggle word wrap

    出力例

    backups.config.openshift.io 2023-10-25T13:32:43Z
etcdbackups.operator.openshift.io 2023-10-25T13:32:04Z
    Copy to Clipboard Toggle word wrap

4.1.2.1. 単一の自動化された etcd バックアップの作成
リンクのコピー

次の手順でカスタムリソース (CR) を作成して適用することで、シングル etcd バックアップを作成します。

前提条件

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

手順

  • 動的にプロビジョニングされたストレージが利用可能な場合は、次の手順を実行して、単一の自動 etcd バックアップを作成します。

    1. 次の例のような内容で、etcd-backup-pvc.yaml という名前の永続ボリューム要求 (PVC) を作成します。 

      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: etcd-backup-pvc
  namespace: openshift-etcd
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 200Gi
      1 
      
  volumeMode: Filesystem
      Copy to Clipboard Toggle word wrap
      1 1
      PVC に利用できるストレージの量。この値は、要件に合わせて調整します。

    2. 以下のコマンドを実行して PVC を適用します。 

      $ oc apply -f etcd-backup-pvc.yaml
      Copy to Clipboard Toggle word wrap

    3. 次のコマンドを実行して、PVC が作成されたことを確認します。 

      $ oc get pvc
      Copy to Clipboard Toggle word wrap

      出力例

      NAME              STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
etcd-backup-pvc   Bound                                                       51s
      Copy to Clipboard Toggle word wrap

      注記

      動的 PVC は、マウントされるまで Pending 状態から遷移しません。

    4. 次の例のような内容で、etcd-single-backup.yaml という名前の CR ファイルを作成します。 

      apiVersion: operator.openshift.io/v1alpha1
kind: EtcdBackup
metadata:
  name: etcd-single-backup
  namespace: openshift-etcd
spec:
  pvcName: etcd-backup-pvc
      1
      Copy to Clipboard Toggle word wrap
      1
      バックアップを保存する PVC の名前。この値は、使用している環境に応じて調整してください。

    5. CR を適用してシングルバックアップを開始します。 

      $ oc apply -f etcd-single-backup.yaml
      Copy to Clipboard Toggle word wrap

  • 動的にプロビジョニングされたストレージが利用できない場合は、次の手順を実行して、単一の自動 etcd バックアップを作成します。

    1. 次の内容で、etcd-backup-local-storage.yaml という名前の StorageClass CR ファイルを作成します。 

      apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: etcd-backup-local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: Immediate
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、StorageClass CR を適用します。 

      $ oc apply -f etcd-backup-local-storage.yaml
      Copy to Clipboard Toggle word wrap

    3. 次の例のような内容の etcd-backup-pv-fs.yaml という名前の PV を作成します。 

      apiVersion: v1
kind: PersistentVolume
metadata:
  name: etcd-backup-pv-fs
spec:
  capacity:
    storage: 100Gi
      1 
      
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: etcd-backup-local-storage
  local:
    path: /mnt
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
      - key: kubernetes.io/hostname
         operator: In
         values:
         - <example_master_node>
      2
      Copy to Clipboard Toggle word wrap
      1
      PV が使用できるストレージの量。この値は、要件に合わせて調整します。
      2
      この値は、この PV をアタッチするノードに置き換えます。

    4. 次のコマンドを実行して、PV が作成されたことを確認します。 

      $ oc get pv
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS                REASON   AGE
etcd-backup-pv-fs       100Gi      RWO            Retain           Available           etcd-backup-local-storage            10s
      Copy to Clipboard Toggle word wrap

    5. 次の例のような内容で、etcd-backup-pvc.yaml という名前の PVC を作成します。 

      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: etcd-backup-pvc
  namespace: openshift-etcd
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Gi
      1
      Copy to Clipboard Toggle word wrap
      1
      PVC に利用できるストレージの量。この値は、要件に合わせて調整します。

    6. 以下のコマンドを実行して PVC を適用します。 

      $ oc apply -f etcd-backup-pvc.yaml
      Copy to Clipboard Toggle word wrap

    7. 次の例のような内容で、etcd-single-backup.yaml という名前の CR ファイルを作成します。 

      apiVersion: operator.openshift.io/v1alpha1
kind: EtcdBackup
metadata:
  name: etcd-single-backup
  namespace: openshift-etcd
spec:
  pvcName: etcd-backup-pvc
      1
      Copy to Clipboard Toggle word wrap
      1
      バックアップを保存する永続ボリューム要求 (PVC) の名前。この値は、使用している環境に応じて調整してください。

    8. CR を適用してシングルバックアップを開始します。 

      $ oc apply -f etcd-single-backup.yaml
      Copy to Clipboard Toggle word wrap
4.1.2.2. 定期的な自動 etcd バックアップの作成
リンクのコピー

etcd の自動繰り返しバックアップを作成するには、次の手順に従います。

可能であれば、動的にプロビジョニングされたストレージを使用して、作成された etcd バックアップデータを安全な外部の場所に保存します。動的にプロビジョニングされたストレージが利用できない場合は、バックアップの復元にアクセスしやすくするために、バックアップデータを NFS 共有に保存することを検討してください。

前提条件

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

手順

  1. 動的にプロビジョニングされたストレージが利用可能な場合は、次の手順を実行して、自動化された繰り返しバックアップを作成します。

    1. 次の例のような内容で、etcd-backup-pvc.yaml という名前の永続ボリューム要求 (PVC) を作成します。 

      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: etcd-backup-pvc
  namespace: openshift-etcd
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 200Gi
      1 
      
  volumeMode: Filesystem
  storageClassName: etcd-backup-local-storage
      Copy to Clipboard Toggle word wrap
      1
      PVC に利用できるストレージの量。この値は、要件に合わせて調整します。
      注記

      次の各プロバイダーでは、accessModes キーと storageClassName キーを変更する必要があります。

      Expand
      ProvideraccessModes 値storageClassName 値

      versioned-installer-efc_operator-ci プロファイルを持つ AWS

      - ReadWriteMany

      efs-sc

      Google Cloud Platform

      - ReadWriteMany

      filestore-csi

      Microsoft Azure

      - ReadWriteMany

      azurefile-csi

    2. 以下のコマンドを実行して PVC を適用します。 

      $ oc apply -f etcd-backup-pvc.yaml
      Copy to Clipboard Toggle word wrap

    3. 次のコマンドを実行して、PVC が作成されたことを確認します。 

      $ oc get pvc
      Copy to Clipboard Toggle word wrap

      出力例

      NAME              STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
etcd-backup-pvc   Bound                                                       51s
      Copy to Clipboard Toggle word wrap

      注記

      動的 PVC は、マウントされるまで Pending 状態から遷移しません。

  2. 動的にプロビジョニングされたストレージが使用できない場合は、次の手順を実行してローカルストレージ PVC を作成します。

    警告

    保存されているバックアップデータが格納されたノードを削除するか、該当ノードへのアクセスを失うと、データが失われる可能性があります。

    1. 次の内容で、etcd-backup-local-storage.yaml という名前の StorageClass CR ファイルを作成します。 

      apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: etcd-backup-local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: Immediate
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、StorageClass CR を適用します。 

      $ oc apply -f etcd-backup-local-storage.yaml
      Copy to Clipboard Toggle word wrap

    3. 適用された StorageClass から、次の例のような内容の etcd-backup-pv-fs.yaml という名前の PV を作成します。 

      apiVersion: v1
kind: PersistentVolume
metadata:
  name: etcd-backup-pv-fs
spec:
  capacity:
    storage: 100Gi
      1 
      
  volumeMode: Filesystem
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Delete
  storageClassName: etcd-backup-local-storage
  local:
    path: /mnt/
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - <example_master_node>
      2
      Copy to Clipboard Toggle word wrap
      1
      PV が使用できるストレージの量。この値は、要件に合わせて調整します。
      2
      この値は、この PV をアタッチするマスターノードに置き換えます。
      ヒント

      次のコマンドを実行して、使用可能なノードのリストを表示します。 

      $ oc get nodes
      Copy to Clipboard Toggle word wrap

    4. 次のコマンドを実行して、PV が作成されたことを確認します。 

      $ oc get pv
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS                REASON   AGE
etcd-backup-pv-fs       100Gi      RWX            Delete           Available           etcd-backup-local-storage            10s
      Copy to Clipboard Toggle word wrap

    5. 次の例のような内容で、etcd-backup-pvc.yaml という名前の PVC を作成します。 

      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: etcd-backup-pvc
spec:
  accessModes:
  - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Gi
      1 
      
  storageClassName: etcd-backup-local-storage
      Copy to Clipboard Toggle word wrap
      1
      PVC に利用できるストレージの量。この値は、要件に合わせて調整します。

    6. 以下のコマンドを実行して PVC を適用します。 

      $ oc apply -f etcd-backup-pvc.yaml
      Copy to Clipboard Toggle word wrap

  3. etcd-recurring-backups.yaml という名前のカスタムリソース定義 (CRD) ファイルを作成します。作成された CRD の内容は、自動化されたバックアップのスケジュールと保持タイプを定義します。

    • 15 個のバックアップを保持する RetentionNumber のデフォルトの保持タイプでは、次の例のような内容を使用します。 

      apiVersion: config.openshift.io/v1alpha1
kind: Backup
metadata:
  name: etcd-recurring-backup
spec:
  etcd:
    schedule: "20 4 * * *"
      1 
      
    timeZone: "UTC"
    pvcName: etcd-backup-pvc
      Copy to Clipboard Toggle word wrap
      1
      定期的なバックアップの CronTab スケジュール。この値は、必要に応じて調整します。

    • バックアップの最大数に基づいて保持を使用するには、次のキーと値のペアを etcd キーに追加します。 

      spec:
  etcd:
    retentionPolicy:
      retentionType: RetentionNumber
      1 
      
      retentionNumber:
        maxNumberOfBackups: 5
      2
      Copy to Clipboard Toggle word wrap
      1
      保持タイプ。指定しない場合、デフォルトは RetentionNumber です。
      2
      保持するバックアップの最大数。この値は、必要に応じて調整します。指定しない場合、デフォルトは 15 個のバックアップです。
      警告

      既知の問題により、保持されるバックアップの数が設定された値に 1 を加えた数になります。

    • バックアップのファイルサイズに基いて保持する場合は、以下を使用します。 

      spec:
  etcd:
    retentionPolicy:
      retentionType: RetentionSize
      retentionSize:
        maxSizeOfBackupsGb: 20
      1
      Copy to Clipboard Toggle word wrap
      1
      保持するバックアップの最大ファイルサイズ (ギガバイト単位)。この値は、必要に応じて調整します。指定しない場合、デフォルトは 10 GB になります。
      警告

      既知の問題により、保持されるバックアップの最大サイズが設定値より最大 10 GB 大きくなります。

  4. 次のコマンドを実行して、CRD で定義される cron ジョブを作成します。 

    $ oc create -f etcd-recurring-backup.yaml
    Copy to Clipboard Toggle word wrap

  5. 作成された cron ジョブを検索するには、次のコマンドを実行します。 

    $ oc get cronjob -n openshift-etcd
    Copy to Clipboard Toggle word wrap

4.2. 正常でない etcd メンバーの置き換え
リンクのコピー

単一の異常な etcd メンバーを置き換えるプロセスは、etcd メンバーが異常な状態である理由が、マシンが実行されていないか、ノードの準備ができていないか、または etcd Pod がクラッシュループしているかどうかによって異なります。

注記

コントロールプレーンホストの大部分を喪失した場合は、この手順ではなく、障害復旧手順に従って、以前のクラスター状態への復元 を行います。

コントロールプレーンの証明書が置き換えているメンバーで有効でない場合は、この手順ではなく、期限切れのコントロールプレーン証明書からの回復 手順を実行する必要があります。

コントロールプレーンノードが失われ、新規ノードが作成される場合、etcd クラスター Operator は新規 TLS 証明書の生成と、ノードの etcd メンバーとしての追加を処理します。

4.2.1. 正常でない etcd メンバーの特定
リンクのコピー

クラスターに正常でない etcd メンバーがあるかどうかを特定することができます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • etcd のバックアップを取得している。詳細は、「etcd データのバックアップ」を参照してください。

手順

  1. 以下のコマンドを使用して EtcdMembersAvailable ステータス条件のステータスを確認します。 

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="EtcdMembersAvailable")]}{.message}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

  2. 出力を確認します。 

    2 of 3 members are available, ip-10-0-131-183.ec2.internal is unhealthy
    Copy to Clipboard Toggle word wrap

    この出力例は、ip-10-0-131-183.ec2.internal etcd メンバーが正常ではないことを示しています。

4.2.2. 正常でない etcd メンバーの状態の判別
リンクのコピー

正常でない etcd メンバーを置き換える手順は、etcd メンバーが以下のどの状態にあるかによって異なります。

  • マシンが実行されていないか、ノードが準備状態にない
  • etcd Pod がクラッシュループしている。

以下の手順では、etcd メンバーがどの状態にあるかを判別します。これにより、正常でない etcd メンバーを置き換えるために実行する必要のある手順を確認できます。

注記

マシンが実行されていないか、ノードが準備状態にないものの、すぐに正常な状態に戻ることが予想される場合は、etcd メンバーを置き換える手順を実行する必要はありません。etcd クラスター Operator はマシンまたはノードが正常な状態に戻ると自動的に同期します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • 正常でない etcd メンバーを特定している。

手順

  1. マシンが実行されていない かどうかを確認します。 

    $ oc get machines -A -ojsonpath='{range .items[*]}{@.status.nodeRef.name}{"\t"}{@.status.providerStatus.instanceState}{"\n"}' | grep -v running
    Copy to Clipboard Toggle word wrap

    出力例

    ip-10-0-131-183.ec2.internal  stopped
    1
    Copy to Clipboard Toggle word wrap

    1
    この出力には、ノードおよびノードのマシンのステータスをリスト表示されます。ステータスが running 以外の場合は、マシンは実行されていません。

    マシンが実行されていない 場合は、マシンが実行されていないか、ノードが準備状態にない場合の正常でない etcd メンバーの置き換え の手順を実行します。

  2. ノードの準備ができていない かどうかを確認します。

    以下のシナリオのいずれかが true の場合、ノードは準備状態にありません。

    • マシンが実行されている場合は、ノードに到達できないかどうかを確認します。 

      $ oc get nodes -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{"\t"}{range .spec.taints[*]}{.key}{" "}' | grep unreachable
      Copy to Clipboard Toggle word wrap

      出力例

      ip-10-0-131-183.ec2.internal	node-role.kubernetes.io/master node.kubernetes.io/unreachable node.kubernetes.io/unreachable
      1
      Copy to Clipboard Toggle word wrap

      1
      ノードが unreachable テイントと共にリスト表示される場合、ノードの準備はできていません。

    • ノードにまだ到達可能な場合は、ノードが NotReady としてリストされるかどうかを確認します。 

      $ oc get nodes -l node-role.kubernetes.io/master | grep "NotReady"
      Copy to Clipboard Toggle word wrap

      出力例

      ip-10-0-131-183.ec2.internal   NotReady   master   122m   v1.32.3
      1
      Copy to Clipboard Toggle word wrap

      1
      ノードが NotReady としてリスト表示されている場合、ノードの準備はできていません。

    ノードの準備ができていない 場合は、マシンが実行されていないか、ノードの準備ができていない場合の正常でない etcd メンバーの置き換え の手順を実行します。

  3. etcd Pod がクラッシュループしている かどうかを確認します。

    マシンが実行され、ノードが準備できている場合は、etcd Pod がクラッシュループしているかどうかを確認します。

    1. すべてのコントロールプレーンノードが Ready としてリスト表示されていることを確認します。 

      $ oc get nodes -l node-role.kubernetes.io/master
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                           STATUS   ROLES    AGE     VERSION
ip-10-0-131-183.ec2.internal   Ready    master   6h13m   v1.32.3
ip-10-0-164-97.ec2.internal    Ready    master   6h13m   v1.32.3
ip-10-0-154-204.ec2.internal   Ready    master   6h13m   v1.32.3
      Copy to Clipboard Toggle word wrap

    2. etcd Pod のステータスが Error または CrashloopBackoff のいずれかであるかどうかを確認します。 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd
      Copy to Clipboard Toggle word wrap

      出力例

      etcd-ip-10-0-131-183.ec2.internal                2/3     Error       7          6h9m
      1 
      
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          6h6m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          6h6m
      Copy to Clipboard Toggle word wrap

      1
      この Pod のこのステータスは Error であるため、etcd Pod はクラッシュループしています。

    etcd Pod がクラッシュループしている 場合、etcd Pod がクラッシュループしている場合の正常でない etcd メンバーの置き換え に関する手順を実行します。

4.2.3. 正常でない etcd メンバーの置き換え
リンクのコピー

正常でない etcd メンバーの状態に応じて、以下のいずれかの手順を使用します。

  • マシンが実行されていないか、ノードの準備ができていない場合の正常でない etcd メンバーの置き換え
  • 正常でないクラスターへのプライマリーコントロールプレーンノードのインストール
  • etcd Pod がクラッシュループしている場合の正常でない etcd メンバーの置き換え
  • 異常停止したベアメタル etcd メンバーの置き換え

マシンが実行されていない、またはノードの準備ができていない、正常ではない etcd メンバーを置き換える手順を説明します。

注記

クラスターがコントロールプレーンマシンセットを使用している場合は、「コントロールプレーンマシンセットのトラブルシューティング」の「劣化した etcd Operator のリカバリー」で etcd のリカバリー手順を参照してください。

前提条件

  • 正常でない etcd メンバーを特定している。

  • マシンが実行されていないか、ノードが準備状態にないことを確認している。

    重要

    他のコントロールプレーンノードの電源をオフにする場合は、待機する必要があります。異常な etcd メンバーの交換が完了するまで、コントロールプレーンノードの電源をオフのままにしておく必要があります。

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

  • etcd のバックアップを取得している。

    重要

    この手順を実行する前に、問題が発生した場合にクラスターを復元できるように、etcd のバックアップを作成してください。

手順

  1. 正常でないメンバーを削除します。

    1. 影響を受けるノード上にない Pod を選択します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd
      Copy to Clipboard Toggle word wrap

      出力例

      etcd-ip-10-0-131-183.ec2.internal                3/3     Running     0          123m
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m
      Copy to Clipboard Toggle word wrap

    2. 実行中の etcd コンテナーに接続し、影響を受けるノードにない Pod の名前を渡します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    3. メンバーのリストを確認します。 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 6fc1e7c9db35841d | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      正常でない etcd メンバーの ID と名前をメモしてください。これらの値はこの手順で後ほど必要になります。$ etcdctl endpoint health コマンドは、補充手順が完了し、新しいメンバーが追加されるまで、削除されたメンバーをリスト表示します。

    4. ID を etcdctl member remove コマンドに指定して、正常でない etcd メンバーを削除します。 

      sh-4.2# etcdctl member remove 6fc1e7c9db35841d
      Copy to Clipboard Toggle word wrap

      出力例

      Member 6fc1e7c9db35841d removed from cluster ead669ce1fbfb346
      Copy to Clipboard Toggle word wrap

    5. メンバーのリストを再度表示し、メンバーが削除されたことを確認します。 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      これでノードシェルを終了できます。

  2. 次のコマンドを入力して、クォーラムガードをオフにします。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

    このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。

    重要

    クォーラムガードをオフにすると、設定の変更を反映するために残りの etcd インスタンスが再起動するまで、短時間クラスターにアクセスできなくなる可能性があります。

    注記

    etcd は、2 つのメンバーで実行されている場合、新たなメンバー障害を許容できません。残りのメンバーのいずれかを再起動すると、クォーラムが破棄され、クラスターでダウンタイムが発生します。クォーラムガードによって、ダウンタイムを引き起こす可能性のある設定変更による再起動から etcd が保護されるため、この手順を完了するには、クォーラムガードを無効にする必要があります。

  3. 次のコマンドを実行して、影響を受けるノードを削除します。 

    $ oc delete node <node_name>
    Copy to Clipboard Toggle word wrap

    コマンドの例

    $ oc delete node ip-10-0-131-183.ec2.internal
    Copy to Clipboard Toggle word wrap

  4. 削除された正常でない etcd メンバーの古いシークレットを削除します。

    1. 削除された正常でない etcd メンバーのシークレット一覧を表示します。 

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal
      1
      Copy to Clipboard Toggle word wrap
      1
      この手順で先ほど書き留めた正常でない etcd メンバーの名前を渡します。

      以下の出力に示されるように、ピア、サービング、およびメトリクスシークレットがあります。

      出力例

      etcd-peer-ip-10-0-131-183.ec2.internal              kubernetes.io/tls                     2      47m
etcd-serving-ip-10-0-131-183.ec2.internal           kubernetes.io/tls                     2      47m
etcd-serving-metrics-ip-10-0-131-183.ec2.internal   kubernetes.io/tls                     2      47m
      Copy to Clipboard Toggle word wrap

    2. 削除された正常でない etcd メンバーのシークレットを削除します。

      1. ピアシークレットを削除します。 

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      2. サービングシークレットを削除します。 

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      3. メトリクスシークレットを削除します。 

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

  5. 次のコマンドを入力して、コントロールプレーンマシンセットが存在するかどうかを確認します。 

    $ oc -n openshift-machine-api get controlplanemachineset
    Copy to Clipboard Toggle word wrap

    • コントロールプレーンマシンセットが存在する場合は、コントロールプレーンマシンを削除して再作成します。このマシンが再作成されると、新しいリビジョンが強制的に適用され、etcd は自動的にスケールアップします。詳細は、「マシンが実行されていないか、ノードの準備ができていない場合の正常でない etcd メンバーの置き換え」を参照してください。

      インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。それ以外の場合は、最初にコントロールプレーンを作成したときと同じ方法を使用して、新しいコントロールプレーンを作成する必要があります。

      1. 正常でないメンバーのマシンを取得します。

        クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped
        1 
        
clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
        Copy to Clipboard Toggle word wrap

        1
        これは正常でないノードのコントロールプレーンマシンです (ip-10-0-131-183.ec2.internal)。

      2. 正常でないメンバーのマシンを削除します。 

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
        1
        Copy to Clipboard Toggle word wrap
        1
        正常でないノードのコントロールプレーンマシンの名前を指定します。

        正常でないメンバーのマシンを削除すると、新しいマシンが自動的にプロビジョニングされます。

      3. 新しいマシンが作成されたことを確認します。 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-133-53.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8   running
        1 
        
clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
        Copy to Clipboard Toggle word wrap

        1
        新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

        新規マシンが作成されるまでに数分の時間がかかる場合があります。マシンまたはノードが正常な状態に戻ると、etcd クラスター Operator が自動的に同期します。

        注記

        マシンセットに使用しているサブネット ID を確認し、それが正しいアベイラビリティーゾーン内にあることを確認してください。

    • コントロールプレーンマシンセットが存在しない場合は、コントロールプレーンマシンを削除して再作成します。このマシンが再作成されると、新しいリビジョンが強制的に適用され、etcd は自動的にスケールアップします。

      インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。それ以外の場合は、最初にコントロールプレーンを作成したときと同じ方法を使用して、新しいコントロールプレーンを作成する必要があります。

      1. 正常でないメンバーのマシンを取得します。

        クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped
        1 
        
clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
        Copy to Clipboard Toggle word wrap

        1
        これは正常でないノードのコントロールプレーンマシンです (ip-10-0-131-183.ec2.internal)。

      2. マシン設定をファイルシステムのファイルに保存します。 

        $ oc get machine clustername-8qw5l-master-0 \
        1 
        
    -n openshift-machine-api \
    -o yaml \
    > new-master-machine.yaml
        Copy to Clipboard Toggle word wrap
        1
        正常でないノードのコントロールプレーンマシンの名前を指定します。

      3. 直前の手順で作成された new-master-machine.yaml ファイルを編集し、新しい名前を割り当て、不要なフィールドを削除します。

        1. status セクション全体を削除します。 

          status:
  addresses:
  - address: 10.0.131.183
    type: InternalIP
  - address: ip-10-0-131-183.ec2.internal
    type: InternalDNS
  - address: ip-10-0-131-183.ec2.internal
    type: Hostname
  lastUpdated: "2020-04-20T17:44:29Z"
  nodeRef:
    kind: Node
    name: ip-10-0-131-183.ec2.internal
    uid: acca4411-af0d-4387-b73e-52b2484295ad
  phase: Running
  providerStatus:
    apiVersion: awsproviderconfig.openshift.io/v1beta1
    conditions:
    - lastProbeTime: "2020-04-20T16:53:50Z"
      lastTransitionTime: "2020-04-20T16:53:50Z"
      message: machine successfully created
      reason: MachineCreationSucceeded
      status: "True"
      type: MachineCreation
    instanceId: i-0fdb85790d76d0c3f
    instanceState: stopped
    kind: AWSMachineProviderStatus
          Copy to Clipboard Toggle word wrap

        2. metadata.name フィールドを新規の名前に変更します。

          古いマシンと同じベース名を維持し、最後の番号を次の使用可能な番号に変更します。この例では、clustername-8qw5l-master-0 は clustername-8qw5l-master-3 に変更されています。

          以下に例を示します。 

          apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  name: clustername-8qw5l-master-3
  ...
          Copy to Clipboard Toggle word wrap

        3. spec.providerID フィールドを削除します。 

            providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
          Copy to Clipboard Toggle word wrap

      4. 正常でないメンバーのマシンを削除します。 

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
        1
        Copy to Clipboard Toggle word wrap
        1
        正常でないノードのコントロールプレーンマシンの名前を指定します。

      5. マシンが削除されたことを確認します。 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
        Copy to Clipboard Toggle word wrap

      6. new-master-machine.yaml ファイルを使用して新しいマシンを作成します。 

        $ oc apply -f new-master-machine.yaml
        Copy to Clipboard Toggle word wrap

      7. 新しいマシンが作成されたことを確認します。 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-133-53.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8   running
        1 
        
clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
        Copy to Clipboard Toggle word wrap

        1
        新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

        新規マシンが作成されるまでに数分の時間がかかる場合があります。マシンまたはノードが正常な状態に戻ると、etcd クラスター Operator が自動的に同期します。

  6. 次のコマンドを入力して、クォーラムガードをオンに戻します。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
    Copy to Clipboard Toggle word wrap

  7. 次のコマンドを入力して、unsupportedConfigOverrides セクションがオブジェクトから削除されたことを確認できます。 

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

  8. シングルノードの OpenShift を使用している場合は、ノードを再起動します。そうしないと、etcd クラスター Operator で次のエラーが発生する可能性があります。

    出力例

    EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]
    Copy to Clipboard Toggle word wrap

検証

  1. すべての etcd Pod が適切に実行されていることを確認します。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

    $ oc -n openshift-etcd get pods -l k8s-app=etcd
    Copy to Clipboard Toggle word wrap

    出力例

    etcd-ip-10-0-133-53.ec2.internal                 3/3     Running     0          7m49s
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m
    Copy to Clipboard Toggle word wrap

    直前のコマンドの出力に 2 つの Pod のみがリスト表示される場合、etcd の再デプロイメントを手動で強制できます。クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。

  2. 3 つの etcd メンバーがあることを確認します。

    1. 実行中の etcd コンテナーに接続し、影響を受けるノードになかった Pod の名前を渡します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    2. メンバーのリストを確認します。 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 5eb0d6b8ca24730c | started |  ip-10-0-133-53.ec2.internal |  https://10.0.133.53:2380 |  https://10.0.133.53:2379 |
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      直前のコマンドの出力に 4 つ以上の etcd メンバーが表示される場合、不要なメンバーを慎重に削除する必要があります。

      警告

      必ず適切な etcd メンバーを削除します。適切な etcd メンバーを削除すると、クォーラム (定足数) が失われる可能性があります。

4.2.3.2. etcd Pod がクラッシュループしている場合の正常でない etcd メンバーの置き換え
リンクのコピー

この手順では、etcd Pod がクラッシュループしている場合の正常でない etcd メンバーを置き換える手順を説明します。

前提条件

  • 正常でない etcd メンバーを特定している。
  • etcd Pod がクラッシュループしていることを確認している。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

  • etcd のバックアップを取得している。

    重要

    問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd バックアップを作成しておくことは重要です。

手順

  1. クラッシュループしている etcd Pod を停止します。

    1. クラッシュループしているノードをデバッグします。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

      $ oc debug node/ip-10-0-131-183.ec2.internal
      1
      Copy to Clipboard Toggle word wrap
      1
      これを正常でないノードの名前に置き換えます。

    2. ルートディレクトリーを /host に変更します。 

      sh-4.2# chroot /host
      Copy to Clipboard Toggle word wrap

    3. 既存の etcd Pod ファイルを kubelet マニフェストディレクトリーから移動します。 

      sh-4.2# mkdir /var/lib/etcd-backup
      Copy to Clipboard Toggle word wrap 
      sh-4.2# mv /etc/kubernetes/manifests/etcd-pod.yaml /var/lib/etcd-backup/
      Copy to Clipboard Toggle word wrap

    4. etcd データディレクトリーを別の場所に移動します。 

      sh-4.2# mv /var/lib/etcd/ /tmp
      Copy to Clipboard Toggle word wrap

      これでノードシェルを終了できます。

  2. 正常でないメンバーを削除します。

    1. 影響を受けるノード上に ない Pod を選択します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd
      Copy to Clipboard Toggle word wrap

      出力例

      etcd-ip-10-0-131-183.ec2.internal                2/3     Error       7          6h9m
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          6h6m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          6h6m
      Copy to Clipboard Toggle word wrap

    2. 実行中の etcd コンテナーに接続し、影響を受けるノードにない Pod の名前を渡します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    3. メンバーのリストを確認します。 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 62bcf33650a7170a | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
| b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      これらの値はこの手順で後ほど必要となるため、ID および正常でない etcd メンバーの名前を書き留めておきます。

    4. ID を etcdctl member remove コマンドに指定して、正常でない etcd メンバーを削除します。 

      sh-4.2# etcdctl member remove 62bcf33650a7170a
      Copy to Clipboard Toggle word wrap

      出力例

      Member 62bcf33650a7170a removed from cluster ead669ce1fbfb346
      Copy to Clipboard Toggle word wrap

    5. メンバーのリストを再度表示し、メンバーが削除されたことを確認します。 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+
      Copy to Clipboard Toggle word wrap

      これでノードシェルを終了できます。

  3. 次のコマンドを入力して、クォーラムガードをオフにします。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

    このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。

  4. 削除された正常でない etcd メンバーの古いシークレットを削除します。

    1. 削除された正常でない etcd メンバーのシークレット一覧を表示します。 

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal
      1
      Copy to Clipboard Toggle word wrap
      1
      この手順で先ほど書き留めた正常でない etcd メンバーの名前を渡します。

      以下の出力に示されるように、ピア、サービング、およびメトリクスシークレットがあります。

      出力例

      etcd-peer-ip-10-0-131-183.ec2.internal              kubernetes.io/tls                     2      47m
etcd-serving-ip-10-0-131-183.ec2.internal           kubernetes.io/tls                     2      47m
etcd-serving-metrics-ip-10-0-131-183.ec2.internal   kubernetes.io/tls                     2      47m
      Copy to Clipboard Toggle word wrap

    2. 削除された正常でない etcd メンバーのシークレットを削除します。

      1. ピアシークレットを削除します。 

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      2. サービングシークレットを削除します。 

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

      3. メトリクスシークレットを削除します。 

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
        Copy to Clipboard Toggle word wrap

  5. etcd の再デプロイメントを強制的に実行します。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "single-master-recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。

    etcd クラスター Operator が再デプロイを実行する場合、すべてのコントロールプレーンノードで etcd Pod が機能していることを確認します。

  6. 次のコマンドを入力して、クォーラムガードをオンに戻します。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
    Copy to Clipboard Toggle word wrap

  7. 次のコマンドを入力して、unsupportedConfigOverrides セクションがオブジェクトから削除されたことを確認できます。 

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

  8. シングルノードの OpenShift を使用している場合は、ノードを再起動します。そうしないと、etcd クラスター Operator で次のエラーが発生する可能性があります。

    出力例

    EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]
    Copy to Clipboard Toggle word wrap

検証

  • 新しいメンバーが利用可能で、正常な状態にあることを確認します。

    1. 再度実行中の etcd コンテナーに接続します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
      Copy to Clipboard Toggle word wrap

    2. すべてのメンバーが正常であることを確認します。 

      sh-4.2# etcdctl endpoint health
      Copy to Clipboard Toggle word wrap

      出力例

      https://10.0.131.183:2379 is healthy: successfully committed proposal: took = 16.671434ms
https://10.0.154.204:2379 is healthy: successfully committed proposal: took = 16.698331ms
https://10.0.164.97:2379 is healthy: successfully committed proposal: took = 16.621645ms
      Copy to Clipboard Toggle word wrap

以下の手順では、マシンが実行されていないか、ノードが準備状態にない場合の正常でないベアメタル etcd メンバーを置き換える手順を説明します。

インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。それ以外の場合は、最初に作成したときと同じ方法で、新しいコントロールプレーンノードを作成する必要があります。

前提条件

  • 正常でないベアメタル etcd メンバーを特定している。
  • マシンが実行されていないか、ノードが準備状態にないことを確認している。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

  • etcd のバックアップを取得している。

    重要

    問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd バックアップを作成しておく。

手順

  1. 正常でないメンバーを確認し、削除します。

    1. 影響を受けるノード上に ない Pod を選択します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide
      Copy to Clipboard Toggle word wrap

      出力例

      etcd-openshift-control-plane-0   5/5   Running   11   3h56m   192.168.10.9   openshift-control-plane-0  <none>           <none>
etcd-openshift-control-plane-1   5/5   Running   0    3h54m   192.168.10.10   openshift-control-plane-1   <none>           <none>
etcd-openshift-control-plane-2   5/5   Running   0    3h58m   192.168.10.11   openshift-control-plane-2   <none>           <none>
      Copy to Clipboard Toggle word wrap

    2. 実行中の etcd コンテナーに接続し、影響を受けるノードにない Pod の名前を渡します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

      $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
      Copy to Clipboard Toggle word wrap

    3. メンバーのリストを確認します。 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      出力例

      +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
| ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
+------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
| 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
| cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380/ | https://192.168.10.9:2379/   | false |
+------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
      Copy to Clipboard Toggle word wrap

      これらの値はこの手順で後ほど必要となるため、ID および正常でない etcd メンバーの名前を書き留めておきます。etcdctl endpoint health コマンドは、置き換えの手順が完了し、新規メンバーが追加されるまで、削除されたメンバーをリスト表示します。

    4. ID を etcdctl member remove コマンドに指定して、正常でない etcd メンバーを削除します。

      警告

      必ず適切な etcd メンバーを削除します。適切な etcd メンバーを削除すると、クォーラム (定足数) が失われる可能性があります。 

      sh-4.2# etcdctl member remove 7a8197040a5126c8
      Copy to Clipboard Toggle word wrap

      出力例

      Member 7a8197040a5126c8 removed from cluster b23536c33f2cdd1b
      Copy to Clipboard Toggle word wrap

    5. メンバーのリストを再度表示し、メンバーが削除されたことを確認します。 

      sh-4.2# etcdctl member list -w table
      Copy to Clipboard Toggle word wrap

      出力例

      +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
| ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
+------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
| cc3830a72fc357f9 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
+------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
      Copy to Clipboard Toggle word wrap

      これでノードシェルを終了できます。

      重要

      メンバーを削除した後、残りの etcd インスタンスが再起動している間、クラスターに短時間アクセスできない場合があります。

  2. 次のコマンドを入力して、クォーラムガードをオフにします。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

    このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。

  3. 以下のコマンドを実行して、削除された正常でない etcd メンバーの古いシークレットを削除します。

    1. 削除された正常でない etcd メンバーのシークレット一覧を表示します。 

      $ oc get secrets -n openshift-etcd | grep openshift-control-plane-2
      Copy to Clipboard Toggle word wrap

      この手順で先ほど書き留めた正常でない etcd メンバーの名前を渡します。

      以下の出力に示されるように、ピア、サービング、およびメトリクスシークレットがあります。 

      etcd-peer-openshift-control-plane-2             kubernetes.io/tls   2   134m
etcd-serving-metrics-openshift-control-plane-2  kubernetes.io/tls   2   134m
etcd-serving-openshift-control-plane-2          kubernetes.io/tls   2   134m
      Copy to Clipboard Toggle word wrap

    2. 削除された正常でない etcd メンバーのシークレットを削除します。

      1. ピアシークレットを削除します。 

        $ oc delete secret etcd-peer-openshift-control-plane-2 -n openshift-etcd

secret "etcd-peer-openshift-control-plane-2" deleted
        Copy to Clipboard Toggle word wrap

      2. サービングシークレットを削除します。 

        $ oc delete secret etcd-serving-metrics-openshift-control-plane-2 -n openshift-etcd

secret "etcd-serving-metrics-openshift-control-plane-2" deleted
        Copy to Clipboard Toggle word wrap

      3. メトリクスシークレットを削除します。 

        $ oc delete secret etcd-serving-openshift-control-plane-2 -n openshift-etcd

secret "etcd-serving-openshift-control-plane-2" deleted
        Copy to Clipboard Toggle word wrap

  4. 正常でないメンバーのマシンを取得します。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

    $ oc get machines -n openshift-machine-api -o wide
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                               PROVIDERID                                                                                              STATE
examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
    1 
    
examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-control-plane-2    Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned
    Copy to Clipboard Toggle word wrap

    1
    これは正常でないノードのコントロールプレーンマシンです (examplecluster-control-plane-2)。

  5. 以下のコマンドを実行して、Bare Metal Operator が利用可能であることを確認します。 

    $ oc get clusteroperator baremetal
    Copy to Clipboard Toggle word wrap

    出力例

    NAME        VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
baremetal   4.19.0    True        False         False      3d15h
    Copy to Clipboard Toggle word wrap

  6. 次のコマンドを実行して、古い BareMetalHost オブジェクトを削除します。 

    $ oc delete bmh openshift-control-plane-2 -n openshift-machine-api
    Copy to Clipboard Toggle word wrap

    出力例

    baremetalhost.metal3.io "openshift-control-plane-2" deleted
    Copy to Clipboard Toggle word wrap

  7. 次のコマンドを実行して、異常なメンバーのマシンを削除します。 

    $ oc delete machine -n openshift-machine-api examplecluster-control-plane-2
    Copy to Clipboard Toggle word wrap

    BareMetalHost および Machine オブジェクトを削除すると、Machine コントローラーにより Node オブジェクトが自動的に削除されます。

    何らかの理由でマシンの削除が遅れたり、コマンドが妨げられて遅れたりする場合は、マシンオブジェクトのファイナライザーフィールドを削除することで強制的に削除できます。

    重要

    Ctrl+c を押してマシンの削除を中断しないでください。コマンドが完了するまで続行できるようにする必要があります。新しいターミナルウィンドウを開き、ファイナライザーフィールドを編集して削除します。

    正常でないメンバーのマシンを削除すると、新しいマシンが自動的にプロビジョニングされます。

    1. 次のコマンドを実行して、マシン設定を編集します。 

      $ oc edit machine -n openshift-machine-api examplecluster-control-plane-2
      Copy to Clipboard Toggle word wrap

    2. Machine カスタムリソースの次のフィールドを削除し、更新されたファイルを保存します。 

      finalizers:
- machine.machine.openshift.io
      Copy to Clipboard Toggle word wrap

      出力例

      machine.machine.openshift.io/examplecluster-control-plane-2 edited
      Copy to Clipboard Toggle word wrap

  8. 以下のコマンドを実行して、マシンが削除されていることを確認します。 

    $ oc get machines -n openshift-machine-api -o wide
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                                 PROVIDERID                                                                                       STATE
examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned
    Copy to Clipboard Toggle word wrap

  9. 次のコマンドを実行して、ノードが削除されたことを確認します。 

    $ oc get nodes

NAME                     STATUS ROLES   AGE   VERSION
openshift-control-plane-0 Ready master 3h24m v1.32.3
openshift-control-plane-1 Ready master 3h24m v1.32.3
openshift-compute-0       Ready worker 176m v1.32.3
openshift-compute-1       Ready worker 176m v1.32.3
    Copy to Clipboard Toggle word wrap

  10. 新しい BareMetalHost オブジェクトとシークレットを作成して BMC 認証情報を保存します。 

    $ cat <<EOF | oc apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: openshift-control-plane-2-bmc-secret
  namespace: openshift-machine-api
data:
  password: <password>
  username: <username>
type: Opaque
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: openshift-control-plane-2
  namespace: openshift-machine-api
spec:
  automatedCleaningMode: disabled
  bmc:
    address: redfish://10.46.61.18:443/redfish/v1/Systems/1
    credentialsName: openshift-control-plane-2-bmc-secret
    disableCertificateVerification: true
  bootMACAddress: 48:df:37:b0:8a:a0
  bootMode: UEFI
  externallyProvisioned: false
  online: true
  rootDeviceHints:
    deviceName: /dev/disk/by-id/scsi-<serial_number>
  userData:
    name: master-user-data-managed
    namespace: openshift-machine-api
EOF
    Copy to Clipboard Toggle word wrap
    注記

    ユーザー名とパスワードは、他のベアメタルホストのシークレットで確認できます。bmc:address で使用するプロトコルは、他の bmh オブジェクトから取得できます。

    重要

    既存のコントロールプレーンホストから BareMetalHost オブジェクト定義を再利用する場合は、externallyProvisioned フィールドを true に設定したままにしないでください。

    既存のコントロールプレーン BareMetalHost オブジェクトが、OpenShift Container Platform インストールプログラムによってプロビジョニングされた場合には、externallyProvisioned フラグが true に設定されている可能性があります。

    検査が完了すると、BareMetalHost オブジェクトが作成され、プロビジョニングできるようになります。

  11. 利用可能な BareMetalHost オブジェクトを使用して作成プロセスを確認します。 

    $ oc get bmh -n openshift-machine-api

NAME                      STATE                  CONSUMER                      ONLINE ERROR   AGE
openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
openshift-control-plane-2 available              examplecluster-control-plane-3 true         47m
openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m
    Copy to Clipboard Toggle word wrap

    1. 新しいマシンが作成されたことを確認します。 

      $ oc get machines -n openshift-machine-api -o wide
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                                   PHASE     TYPE   REGION   ZONE   AGE     NODE                              PROVIDERID                                                                                            STATE
examplecluster-control-plane-0         Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
      1 
      
examplecluster-control-plane-1         Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-control-plane-2         Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
examplecluster-compute-0               Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1               Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned
      Copy to Clipboard Toggle word wrap

      1
      新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

      新規マシンが作成されるまでに数分の時間がかかります。etcd クラスター Operator はマシンまたはノードが正常な状態に戻ると自動的に同期します。

    2. 以下のコマンドを実行して、ベアメタルホストがプロビジョニングされ、エラーが報告されていないことを確認します。 

      $ oc get bmh -n openshift-machine-api
      Copy to Clipboard Toggle word wrap

      出力例

      $ oc get bmh -n openshift-machine-api
NAME                      STATE                  CONSUMER                       ONLINE ERROR AGE
openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
openshift-control-plane-2 provisioned            examplecluster-control-plane-3 true          47m
openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m
      Copy to Clipboard Toggle word wrap

    3. 以下のコマンドを実行して、新規ノードが追加され、Ready の状態であることを確認します。 

      $ oc get nodes
      Copy to Clipboard Toggle word wrap

      出力例

      $ oc get nodes
NAME                     STATUS ROLES   AGE   VERSION
openshift-control-plane-0 Ready master 4h26m v1.32.3
openshift-control-plane-1 Ready master 4h26m v1.32.3
openshift-control-plane-2 Ready master 12m   v1.32.3
openshift-compute-0       Ready worker 3h58m v1.32.3
openshift-compute-1       Ready worker 3h58m v1.32.3
      Copy to Clipboard Toggle word wrap

  12. 次のコマンドを入力して、クォーラムガードをオンに戻します。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
    Copy to Clipboard Toggle word wrap

  13. 次のコマンドを入力して、unsupportedConfigOverrides セクションがオブジェクトから削除されたことを確認できます。 

    $ oc get etcd/cluster -oyaml
    Copy to Clipboard Toggle word wrap

  14. シングルノードの OpenShift を使用している場合は、ノードを再起動します。そうしないと、etcd クラスター Operator で次のエラーが発生する可能性があります。

    出力例

    EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]
    Copy to Clipboard Toggle word wrap

検証

  1. すべての etcd Pod が適切に実行されていることを確認します。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

    $ oc -n openshift-etcd get pods -l k8s-app=etcd
    Copy to Clipboard Toggle word wrap

    出力例

    etcd-openshift-control-plane-0      5/5     Running     0     105m
etcd-openshift-control-plane-1      5/5     Running     0     107m
etcd-openshift-control-plane-2      5/5     Running     0     103m
    Copy to Clipboard Toggle word wrap

    直前のコマンドの出力に 2 つの Pod のみがリスト表示される場合、etcd の再デプロイメントを手動で強制できます。クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。

    etcd メンバーがちょうど 3 つあることを確認するには、実行中の etcd コンテナーに接続し、影響を受けたノード上になかった Pod の名前を渡します。クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

    $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
    Copy to Clipboard Toggle word wrap

  2. メンバーのリストを確認します。 

    sh-4.2# etcdctl member list -w table
    Copy to Clipboard Toggle word wrap

    出力例

    +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
|        ID        | STATUS  |        NAME        |        PEER ADDRS         |       CLIENT ADDRS        |    IS LEARNER    |
+------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
| 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380 | https://192.168.10.11:2379 |   false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380 | https://192.168.10.10:2379 |   false |
| cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380 | https://192.168.10.9:2379 |     false |
+------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
    Copy to Clipboard Toggle word wrap

    注記

    直前のコマンドの出力に 4 つ以上の etcd メンバーが表示される場合、不要なメンバーを慎重に削除する必要があります。

  3. 以下のコマンドを実行して、すべての etcd メンバーが正常であることを確認します。 

    # etcdctl endpoint health --cluster
    Copy to Clipboard Toggle word wrap

    出力例

    https://192.168.10.10:2379 is healthy: successfully committed proposal: took = 8.973065ms
https://192.168.10.9:2379 is healthy: successfully committed proposal: took = 11.559829ms
https://192.168.10.11:2379 is healthy: successfully committed proposal: took = 11.665203ms
    Copy to Clipboard Toggle word wrap

  4. 以下のコマンドを実行して、すべてのノードが最新のリビジョンであることを確認します。 

    $ oc get etcd -o=jsonpath='{range.items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
    Copy to Clipboard Toggle word wrap 
    AllNodesAtLatestRevision
    Copy to Clipboard Toggle word wrap

4.3. Disaster recovery
リンクのコピー

この障害復旧ドキュメントでは、OpenShift Container Platform クラスターで発生する可能性のある複数の障害のある状態からの復旧方法に関する管理者向けの情報を提供しています。管理者は、クラスターの状態を機能する状態に戻すために、以下の 1 つまたは複数の手順を実行する必要がある場合があります。

重要

障害復旧には、少なくとも 1 つの正常なコントロールプレーンホストが必要です。

4.3.1. クォーラムの復元
リンクのコピー

quorum-restore.sh スクリプトを使用すると、クォーラムの喪失によりオフラインになっているクラスターの etcd クォーラムを復元できます。クォーラムが失われると、OpenShift Container Platform API が読み取り専用になります。クォーラムが復元されると、OpenShift Container Platform API は読み取り/書き込みモードに戻ります。

4.3.1.1. 高可用性クラスターの etcd クォーラムの復元
リンクのコピー

quorum-restore.sh スクリプトを使用すると、クォーラムの喪失によりオフラインになっているクラスターの etcd クォーラムを復元できます。クォーラムが失われると、OpenShift Container Platform API が読み取り専用になります。クォーラムが復元されると、OpenShift Container Platform API は読み取り/書き込みモードに戻ります。

quorum-restore.sh スクリプトは、ローカルのデータディレクトリーに基づいてシングルメンバーの新しい etcd クラスターを即座に戻し、以前のクラスター識別子を廃止して他のすべてのメンバーを無効としてマークします。コントロールプレーンを復元するために事前のバックアップは必要ありません。

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

警告

復元を実行するホストにすべてのデータがレプリケートされていない場合、データが失われる可能性があります。

重要

クォーラムの復元は、復元プロセス外のノード数を減らすために使用しないでください。ノードの数を減らすと、サポート対象外のクラスター設定になります。

前提条件

  • クォーラムを復元するために使用するノードへの SSH アクセス権がある。

手順

  1. リカバリーホストとして使用するコントロールプレーンホストを選択します。このホストで復元操作を実行します。

    1. 次のコマンドを実行して、実行中の etcd Pod をリスト表示します。 

      $ oc get pods -n openshift-etcd -l app=etcd --field-selector="status.phase==Running"
      Copy to Clipboard Toggle word wrap

    2. Pod を 1 つ選択し、次のコマンドを実行してその IP アドレスを取得します。 

      $ oc exec -n openshift-etcd <etcd-pod> -c etcdctl -- etcdctl endpoint status -w table
      Copy to Clipboard Toggle word wrap

      Raft インデックスが最も大きく、Learner ではないメンバーの IP アドレスをメモします。

    3. 次のコマンドを実行し、選択した etcd メンバーの IP アドレスに対応するノード名をメモします。 

      $ oc get nodes -o jsonpath='{range .items[*]}[{.metadata.name},{.status.addresses[?(@.type=="InternalIP")].address}]{end}'
      Copy to Clipboard Toggle word wrap

  2. SSH を使用して、選択したリカバリーノードに接続し、次のコマンドを実行して etcd クォーラムを復元します。 

    $ sudo -E /usr/local/bin/quorum-restore.sh
    Copy to Clipboard Toggle word wrap

    数分後、ダウンしたノードが、リカバリースクリプトを実行したノードと自動的に同期されます。残りのオンラインのノードは、quorum-restore.sh スクリプトによって作成された新しい etcd クラスターに自動的に再参加します。このプロセスには数分かかります。

  3. SSH セッションを終了します。

  4. いずれかのノードがオフラインの場合は、3 ノード設定に戻ります。オフラインになっているノードごとに次の手順を繰り返して、ノードを削除し、再作成します。マシンが再作成された後、新しいリビジョンが強制され、etcd が自動的にスケールアップします。

    • ユーザーがプロビジョニングしたベアメタルインストールを使用する場合は、最初に作成したときと同じ方法を使用して、コントロールプレーンマシンを再作成できます。詳細は、「ユーザーによってプロビジョニングされるクラスターのベアメタルへのインストール」を参照してください。

      警告

      リカバリーホストのマシンを削除し、再作成しないでください。

    • installer-provisioned infrastructure を実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。

      警告

      リカバリーホストのマシンを削除し、再作成しないでください。

      installer-provisioned infrastructure でのベアメタルインストールの場合、コントロールプレーンマシンは再作成されません。詳細は、「ベアメタルコントロールプレーンノードの交換」を参照してください。

      1. いずれかのオフラインノードのマシンを取得します。

        クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。 

        $ oc get machines -n openshift-machine-api -o wide
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped
        1 
        
clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
        Copy to Clipboard Toggle word wrap

        1
        これは、オフラインノード ip-10-0-131-183.ec2.internal のコントロールプレーンマシンです。

      2. 次のコマンドを実行して、オフラインノードのマシンを削除します。 

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0
        1
        Copy to Clipboard Toggle word wrap
        1
        オフラインノードのコントロールプレーンマシンの名前を指定します。

        オフラインノードのマシンを削除すると、新しいマシンが自動的にプロビジョニングされます。

  5. 以下を実行して、新しいマシンが作成されたことを確認します。 

    $ oc get machines -n openshift-machine-api -o wide
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running
    1 
    
clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running
    Copy to Clipboard Toggle word wrap

    1
    新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

    新規マシンが作成されるまでに数分の時間がかかる場合があります。マシンまたはノードが正常な状態に戻ると、etcd クラスター Operator が自動的に同期します。

    1. オフラインになっているノードごとに上記の手順を繰り返します。

  6. 次のコマンドを実行して、コントロールプレーンが回復するまで待ちます。 

    $ oc adm wait-for-stable-cluster
    Copy to Clipboard Toggle word wrap
    注記

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

トラブルシューティング

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

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$(date --rfc-3339=ns )"'"}}' --type=merge
    Copy to Clipboard Toggle word wrap
注記

コントロールプレーンノードの大部分がまだ使用可能であり、etcd のクォーラムがある場合は、1 つの異常な etcd メンバーを置き換えます。

4.3.2. 以前のクラスター状態への復元
リンクのコピー

クラスターを以前の状態に復元するには、スナップショットを作成して etcd データを事前にバックアップしておく必要があります。このスナップショットを使用して、クラスターの状態を復元します。詳細は、「etcd データのバックアップ」を参照してください。

該当する場合は、コントロールプレーン証明書の期限切れの状態からのリカバリー が必要になる場合もあります。

警告

以前のクラスター状態に復元することは、実行中のクラスターを不安定な状態にする破壊的な操作です。この手順は、最後の手段としてのみ使用してください。

復元を実行する前に、クラスターへの影響の詳細について、「以前のクラスター状態への復元について」を参照してください。

4.3.2.1. 以前のクラスター状態への復元について
リンクのコピー

クラスターを以前の状態に復元するには、スナップショットを作成して etcd データを事前にバックアップしておく必要があります。このスナップショットを使用して、クラスターの状態を復元します。詳細は、「etcd データのバックアップ」を参照してください。

etcd バックアップを使用して、クラスターを直前の状態に復元できます。これは、以下の状況から回復するために使用できます。

  • クラスターは、大多数のコントロールプレーンホストを失いました (クォーラムの喪失)。
  • 管理者が重要なものを削除し、クラスターを復旧するために復元する必要があります。
警告

以前のクラスター状態に復元することは、実行中のクラスターを不安定な状態にする破壊的な操作です。これは、最後の手段としてのみ使用してください。

Kubernetes API サーバーを使用してデータを取得できる場合は、etcd が利用できるため、etcd バックアップを使用して復元することはできません。

etcd を効果的に復元すると、クラスターが時間内に元に戻され、すべてのクライアントは競合する並列履歴が発生します。これは、kubelet、Kubernetes コントローラーマネージャー、永続ボリュームコントローラー、OpenShift Container Platform Operator (ネットワーク Operator を含む) などの監視コンポーネントの動作に影響を与える可能性があります。

etcd のコンテンツがディスク上の実際のコンテンツと一致しないと、Operator チャーンが発生し、ディスク上のファイルが etcd のコンテンツと競合すると、Kubernetes API サーバー、Kubernetes コントローラーマネージャー、Kubernetes スケジューラーなどの Operator が停止する場合があります。この場合は、問題の解決に手動のアクションが必要になる場合があります。

極端な場合、クラスターは永続ボリュームを追跡できなくなり、存在しなくなった重要なワークロードを削除し、マシンのイメージを再作成し、期限切れの証明書を使用して CA バンドルを書き換えることができます。

4.3.2.2. シングルノードで以前のクラスター状態に復元する
リンクのコピー

保存された etcd バックアップを使用して、シングルノードでクラスターの以前の状態を復元できます。

重要

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

前提条件

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

手順

  1. SSH を使用してシングルノードに接続し、次のコマンドを実行して etcd バックアップを /home/core ディレクトリーにコピーします。 

    $ cp <etcd_backup_directory> /home/core
    Copy to Clipboard Toggle word wrap

  2. シングルノードで次のコマンドを実行し、以前のバックアップからクラスターを復元します。 

    $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd_backup_directory>
    Copy to Clipboard Toggle word wrap
  3. SSH セッションを終了します。

  4. 次のコマンドを実行して、コントロールプレーンの回復の進行状況を監視します。 

    $ oc adm wait-for-stable-cluster
    Copy to Clipboard Toggle word wrap
    注記

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

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.19.2 クラスターは、4.19.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
    Copy to Clipboard Toggle word wrap

  4. etcd バックアップディレクトリーをリカバリーコントロールプレーンホストにコピーします。

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

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

    $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd-backup-directory>
    Copy to Clipboard Toggle word wrap
  6. SSH セッションを終了します。

  7. API が応答したら、次のコマンドを実行して etcd Operator のクォーラムガードをオフにします。 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
    Copy to Clipboard Toggle word wrap

  8. 次のコマンドを実行して、コントロールプレーンの回復の進行状況を監視します。 

    $ oc adm wait-for-stable-cluster
    Copy to Clipboard Toggle word wrap
    注記

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

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

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
    Copy to Clipboard Toggle word wrap

トラブルシューティング

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

$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$(date --rfc-3339=ns )"'"}}' --type=merge
Copy to Clipboard Toggle word wrap
4.3.2.4. etcd バックアップからのクラスターの手動復元
リンクのコピー

「以前のクラスター状態への復元」セクションで説明されている復元手順は次のとおりです。

  • 2 つのコントロールプレーンノードを完全に再作成する必要があります。ただし、UPI インストール方式でインストールされたクラスターでは複雑な手順になる可能性があります。UPI インストールでは、コントロールプレーンノード用の Machine または ControlPlaneMachineset が作成されないためです。
  • /usr/local/bin/cluster-restore.sh スクリプトを使用して、シングルメンバーの新しい etcd クラスターを起動し、それを 3 つのメンバーに拡張します。

これに対し、この手順は次の点が異なります。

  • コントロールプレーンノードを再作成する必要はありません。
  • 3 つのメンバーからなる etcd クラスターを直接起動します。

クラスターがコントロールプレーンに MachineSet を使用する場合は、etcd の回復手順を簡素化するために、「以前のクラスター状態への復元」を使用することを推奨します。

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

前提条件

  • cluster-admin ロールを持つユーザー (例: kubeadmin ユーザー) としてクラスターにアクセスします。
  • すべて のコントロールプレーンホストへの SSH アクセス権があり、ホストユーザーが root (デフォルトの core ホストユーザーなど) になることが許可されている。
  • 同じバックアップからの以前の etcd スナップショットと静的 Pod のリソースの両方を含むバックアップディレクトリー。ディレクトリー内のファイル名は、snapshot_<datetimestamp>.db および static_kuberesources_<datetimestamp>.tar.gz の形式にする必要があります。

手順

  1. SSH を使用して各コントロールプレーンノードに接続します。

    Kubernetes API サーバーは復元プロセスの開始後にアクセスできなくなるため、コントロールプレーンノードにはアクセスできません。このため、アクセスするコントロールプレーンホストごとに、別のターミナルで SSH 接続を使用することを推奨します。

    重要

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

  2. etcd バックアップディレクトリーを各コントロールプレーンホストにコピーします。

    この手順では、etcd スナップショットと静的 Pod のリソースを含む backup ディレクトリーを各コントロールプレーンホストの /home/core/assets ディレクトリーにコピーしていることを前提としています。この assets フォルダーがまだ存在しない場合は、作成する必要がある場合があります。

  3. すべてのコントロールプレーンノード上の静的 Pod を、一度に 1 つのホストずつ停止します。

    1. 既存の Kubernetes API サーバーの静的 Pod マニフェストを kubelet マニフェストディレクトリーから移動します。 

      $ mkdir -p /root/manifests-backup
$ mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /root/manifests-backup/
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを使用して、Kubernetes API Server コンテナーが停止したことを確認します。 

      $ crictl ps | grep kube-apiserver | grep -E -v "operator|guard"
      Copy to Clipboard Toggle word wrap

      コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。

    3. Kubernetes API サーバーコンテナーがまだ実行中の場合は、次のコマンドを使用して手動で終了します。 

      $ crictl stop <container_id>
      Copy to Clipboard Toggle word wrap

    4. 同じ手順を、kube-controller-manager-pod.yaml、kube-scheduler-pod.yaml、最後に etcd-pod.yaml に対して繰り返します。

      1. 次のコマンドで kube-controller-manager Pod を停止します。 

        $ mv /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /root/manifests-backup/
        Copy to Clipboard Toggle word wrap

      2. 次のコマンドを使用して、コンテナーが停止しているかどうかを確認します。 

        $ crictl ps | grep kube-controller-manager | grep -E -v "operator|guard"
        Copy to Clipboard Toggle word wrap

      3. 次のコマンドを使用して、kube-scheduler Pod を停止します。 

        $ mv /etc/kubernetes/manifests/kube-scheduler-pod.yaml /root/manifests-backup/
        Copy to Clipboard Toggle word wrap

      4. 次のコマンドを使用して、コンテナーが停止しているかどうかを確認します。 

        $ crictl ps | grep kube-scheduler | grep -E -v "operator|guard"
        Copy to Clipboard Toggle word wrap

      5. 次のコマンドを使用して etcd Pod を停止します。 

        $ mv /etc/kubernetes/manifests/etcd-pod.yaml /root/manifests-backup/
        Copy to Clipboard Toggle word wrap

      6. 次のコマンドを使用して、コンテナーが停止しているかどうかを確認します。 

        $ crictl ps | grep etcd | grep -E -v "operator|guard"
        Copy to Clipboard Toggle word wrap

  4. 各コントロールプレーンホストで、現在の etcd データを backup フォルダーに移動して保存します。 

    $ mkdir /home/core/assets/old-member-data
$ mv /var/lib/etcd/member /home/core/assets/old-member-data
    Copy to Clipboard Toggle word wrap

    このデータは、etcd バックアップの復元が機能せず、etcd クラスターを現在の状態に復元する必要がある場合に役立ちます。

  5. 各コントロールプレーンホストの正しい etcd パラメーターを確認します。

    1. <ETCD_NAME> の値は、各コントロールプレーンホストごとに一意であり、特定のコントロールプレーンホストのマニフェスト /etc/kubernetes/static-pod-resources/etcd-certs/configmaps/restore-etcd-pod/pod.yaml ファイル内にある ETCD_NAME 変数の値と同じです。次のコマンドで確認できます。 

      RESTORE_ETCD_POD_YAML="/etc/kubernetes/static-pod-resources/etcd-certs/configmaps/restore-etcd-pod/pod.yaml"
cat $RESTORE_ETCD_POD_YAML | \
  grep -A 1 $(cat $RESTORE_ETCD_POD_YAML | grep 'export ETCD_NAME' | grep -Eo 'NODE_.+_ETCD_NAME') | \
  grep -Po '(?<=value: ").+(?=")'
      Copy to Clipboard Toggle word wrap

    2. <UUID> の値は、次のコマンドを使用してコントロールプレーンホストで生成できます。 

      $ uuidgen
      Copy to Clipboard Toggle word wrap
      注記

      <UUID> の値は 1 回だけ生成する必要があります。1 つのコントロールプレーンホストで UUID を生成した後あ、他のホストで再度生成しないでください。次の手順では、すべてのコントロールプレーンホストで同じ UUID を使用します。

    3. ETCD_NODE_PEER_URL の値は、次の例のように設定する必要があります。 

      https://<IP_CURRENT_HOST>:2380
      Copy to Clipboard Toggle word wrap

      正しい IP は、次のコマンドを使用して、特定のコントロールプレーンホストの <ETCD_NAME> から確認できます。 

      $ echo <ETCD_NAME> | \
  sed -E 's/[.-]/_/g' | \
  xargs -I {} grep {} /etc/kubernetes/static-pod-resources/etcd-certs/configmaps/etcd-scripts/etcd.env | \
  grep "IP" | grep -Po '(?<=").+(?=")'
      Copy to Clipboard Toggle word wrap

    4. <ETCD_INITIAL_CLUSTER> の値は、次のように設定する必要があります。<ETCD_NAME_n> は各コントロールプレーンホストの <ETCD_NAME> です。

      注記

      使用するポートは 2379 ではなく 2380 である必要があります。ポート 2379 は etcd データベース管理に使用され、コンテナー内の etcd 起動コマンドで直接設定されます。

      出力例

      <ETCD_NAME_0>=<ETCD_NODE_PEER_URL_0>,<ETCD_NAME_1>=<ETCD_NODE_PEER_URL_1>,<ETCD_NAME_2>=<ETCD_NODE_PEER_URL_2>
      1
      Copy to Clipboard Toggle word wrap

      1
      各コントロールプレーンホストの ETCD_NODE_PEER_URL 値を指定します。

      <ETCD_INITIAL_CLUSTER> 値は、すべてのコントロールプレーンホストで同じです。次の手順では、すべてのコントロールプレーンホストで同じ値が必要です。

  6. バックアップから etcd データベースを再生成します。

    この操作は、各コントロールプレーンホストで実行する必要があります。

    1. 次のコマンドを使用して、etcd バックアップを /var/lib/etcd ディレクトリーにコピーします。 

      $ cp /home/core/assets/backup/<snapshot_yyyy-mm-dd_hhmmss>.db /var/lib/etcd
      Copy to Clipboard Toggle word wrap

    2. 続行する前に、正しい etcdctl イメージを特定します。次のコマンドを使用して、Pod マニフェストのバックアップからイメージを取得します。 

      $ jq -r '.spec.containers[]|select(.name=="etcdctl")|.image' /root/manifests-backup/etcd-pod.yaml
      Copy to Clipboard Toggle word wrap 
      $ podman run --rm -it --entrypoint="/bin/bash" -v /var/lib/etcd:/var/lib/etcd:z <image-hash>
      Copy to Clipboard Toggle word wrap

    3. etcdctl ツールのバージョンが、バックアップが作成された etcd サーバーのバージョンであることを確認します。 

      $ etcdctl version
      Copy to Clipboard Toggle word wrap

    4. 現在のホストの正しい値を使用して次のコマンドを実行し、etcd データベースを再生成します。 

      $ ETCDCTL_API=3 /usr/bin/etcdctl snapshot restore /var/lib/etcd/<snapshot_yyyy-mm-dd_hhmmss>.db \
  --name "<ETCD_NAME>" \
  --initial-cluster="<ETCD_INITIAL_CLUSTER>" \
  --initial-cluster-token "openshift-etcd-<UUID>" \
  --initial-advertise-peer-urls "<ETCD_NODE_PEER_URL>" \
  --data-dir="/var/lib/etcd/restore-<UUID>" \
  --skip-hash-check=true
      Copy to Clipboard Toggle word wrap
      注記

      etcd データベースを再生成する場合、引用符は必須です。

  7. added member ログに出力される値を記録します。次に例を示します。

    出力例

    2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "56cd73b614699e7", "added-peer-peer-urls": ["https://10.0.91.5:2380"], "added-peer-is-learner": false}
2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "1f63d01b31bb9a9e", "added-peer-peer-urls": ["https://10.0.90.221:2380"], "added-peer-is-learner": false}
2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "fdc2725b3b70127c", "added-peer-peer-urls": ["https://10.0.94.214:2380"], "added-peer-is-learner": false}
    Copy to Clipboard Toggle word wrap

    1. コンテナーから出ます。
    2. この手順を他のコントロールプレーンホストでも繰り返し、added member ログに出力される値がすべてのコントロールプレーンホストで同じであることを確認します。

  8. 再生成された etcd データベースをデフォルトの場所に移動します。

    この操作は、各コントロールプレーンホストで実行する必要があります。

    1. 再生成されたデータベース (以前の etcdctl snapshot restore コマンドによって作成された member フォルダー) を、デフォルトの etcd の場所 /var/lib/etcd に移動します。 

      $ mv /var/lib/etcd/restore-<UUID>/member /var/lib/etcd
      Copy to Clipboard Toggle word wrap

    2. /var/lib/etcd ディレクトリーの /var/lib/etcd/member フォルダーの SELinux コンテキストを復元します。 

      $ restorecon -vR /var/lib/etcd/
      Copy to Clipboard Toggle word wrap

    3. 残りのファイルとディレクトリーを削除します。 

      $ rm -rf /var/lib/etcd/restore-<UUID>
      Copy to Clipboard Toggle word wrap 
      $ rm /var/lib/etcd/<snapshot_yyyy-mm-dd_hhmmss>.db
      Copy to Clipboard Toggle word wrap
      重要

      完了すると、/var/lib/etcd ディレクトリーに含まれるフォルダーが member だけになります。

    4. 他のコントロールプレーンホストでもこの手順を繰り返します。

  9. etcd クラスターを再起動します。

    1. 次の手順は、すべてのコントロールプレーンホストで実行する必要があります。ただし、一度に 1 つのホストずつ 実行する必要があります。

    2. kubelet が関連コンテナーを起動するように、etcd 静的 Pod マニフェストを kubelet マニフェストディレクトリーに戻します。 

      $ mv /tmp/etcd-pod.yaml /etc/kubernetes/manifests
      Copy to Clipboard Toggle word wrap

    3. すべての etcd コンテナーが起動していることを確認します。 

      $ crictl ps | grep etcd | grep -v operator
      Copy to Clipboard Toggle word wrap

      出力例

      38c814767ad983       f79db5a8799fd2c08960ad9ee22f784b9fbe23babe008e8a3bf68323f004c840                                                         28 seconds ago       Running             etcd-health-monitor                   2                   fe4b9c3d6483c
e1646b15207c6       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcd-metrics                          0                   fe4b9c3d6483c
08ba29b1f58a7       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcd                                  0                   fe4b9c3d6483c
2ddc9eda16f53       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcdctl
      Copy to Clipboard Toggle word wrap

      このコマンドの出力が空の場合は、数分待ってからもう一度確認してください。

  10. etcd クラスターのステータスを確認します。

    1. いずれかのコントロールプレーンホストで、次のコマンドを使用して etcd クラスターのステータスを確認します。 

      $ crictl exec -it $(crictl ps | grep etcdctl | awk '{print $1}') etcdctl endpoint status -w table
      Copy to Clipboard Toggle word wrap

      出力例

      +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT         |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| https://10.0.89.133:2379 | 682e4a83a0cec6c0 |   3.5.0 |   67 MB |      true |      false |         2 |        218 |                218 |        |
|  https://10.0.92.74:2379 | 450bcf6999538512 |   3.5.0 |   67 MB |     false |      false |         2 |        218 |                218 |        |
| https://10.0.93.129:2379 | 358efa9c1d91c3d6 |   3.5.0 |   67 MB |     false |      false |         2 |        218 |                218 |        |
+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      Copy to Clipboard Toggle word wrap

  11. 他の静的 Pod を再起動します。

    次の手順は、すべてのコントロールプレーンホストで実行する必要があります。ただし、一度に 1 つのホストずつ実行する必要があります。

    1. 次のコマンドを使用して、Kubernetes API サーバーの静的 Pod マニフェストを kubelet マニフェストディレクトリーに戻し、kubelet が関連するコンテナーを起動するようにします。 

      $ mv /root/manifests-backup/kube-apiserver-pod.yaml /etc/kubernetes/manifests
      Copy to Clipboard Toggle word wrap

    2. すべての Kubernetes API サーバーコンテナーが起動したことを確認します。 

      $ crictl ps | grep kube-apiserver | grep -v operator
      Copy to Clipboard Toggle word wrap
      注記

      次のコマンドの出力が空の場合は、数分待ってからもう一度確認してください。

    3. 同じ手順を、kube-controller-manager-pod.yaml ファイルと kube-scheduler-pod.yaml ファイルに対して繰り返します。

      1. 次のコマンドを使用して、すべてのノードで kubelet を再起動します。 

        $ systemctl restart kubelet
        Copy to Clipboard Toggle word wrap

      2. 次のコマンドを使用して、残りのコントロールプレーン Pod を起動します。 

        $ mv /root/manifests-backup/kube-* /etc/kubernetes/manifests/
        Copy to Clipboard Toggle word wrap

      3. kube-apiserver、kube-scheduler、および kube-controller-manager Pod が正しく起動しているかどうかを確認します。 

        $ crictl ps | grep -E 'kube-(apiserver|scheduler|controller-manager)' | grep -v -E 'operator|guard'
        Copy to Clipboard Toggle word wrap

      4. 次のコマンドを使用して OVN データベースをワイプします。 

        for NODE in  $(oc get node -o name | sed 's:node/::g')
do
  oc debug node/${NODE} -- chroot /host /bin/bash -c  'rm -f /var/lib/ovn-ic/etc/ovn*.db && systemctl restart ovs-vswitchd ovsdb-server'
  oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName=${NODE} --wait
  oc -n openshift-ovn-kubernetes wait pod -l app=ovnkube-node --field-selector=spec.nodeName=${NODE} --for condition=ContainersReady --timeout=600s
done
        Copy to Clipboard Toggle word wrap
4.3.2.5. 永続ストレージの状態復元に関する問題および回避策
リンクのコピー

OpenShift Container Platform クラスターがいずれかの形式の永続ストレージを使用する場合に、クラスターの状態は通常 etcd 外に保存されます。たとえば、Pod で実行されている Elasticsearch クラスター、または StatefulSet オブジェクトで実行されているデータベースなどである可能性があります。etcd バックアップから復元する場合には、OpenShift Container Platform のワークロードのステータスも復元されます。ただし、etcd スナップショットが古い場合には、ステータスは無効または期限切れの可能性があります。

重要

永続ボリューム (PV) の内容は etcd スナップショットには含まれません。etcd スナップショットから OpenShift Container Platform クラスターを復元する時に、重要ではないワークロードから重要なデータにアクセスしたり、その逆ができたりする場合があります。

以下は、古いステータスを生成するシナリオ例です。

  • MySQL データベースが PV オブジェクトでバックアップされる Pod で実行されている。etcd スナップショットから OpenShift Container Platform を復元すると、Pod の起動を繰り返し試行しても、ボリュームをストレージプロバイダーに戻したり、実行中の MySQL Pod が生成したりされるわけではありません。この Pod は、ストレージプロバイダーでボリュームを復元し、次に PV を編集して新規ボリュームを参照するように手動で復元する必要があります。
  • Pod P1 は、ノード X に割り当てられているボリューム A を使用している。別の Pod がノード Y にある同じボリュームを使用している場合に etcd スナップショットが作成された場合に、etcd の復元が実行されると、ボリュームがノード Y に割り当てられていることが原因で Pod P1 が正常に起動できなくなる可能性があります。OpenShift Container Platform はこの割り当てを認識せず、ボリュームが自動的に切り離されるわけではありません。これが生じる場合には、ボリュームをノード Y から手動で切り離し、ノード X に割り当ててることで Pod P1 を起動できるようにします。
  • クラウドプロバイダーまたはストレージプロバイダーの認証情報が etcd スナップショットの作成後に更新された。これが原因で、プロバイダーの認証情報に依存する CSI ドライバーまたは Operator が機能しなくなります。これらのドライバーまたは Operator で必要な認証情報を手動で更新する必要がある場合があります。

  • デバイスが etcd スナップショットの作成後に OpenShift Container Platform ノードから削除されたか、名前が変更された。ローカルストレージ Operator で、/dev/disk/by-id または /dev ディレクトリーから管理する各 PV のシンボリックリンクが作成されます。この状況では、ローカル PV が存在しないデバイスを参照してしまう可能性があります。

    この問題を修正するには、管理者は以下を行う必要があります。

    1. デバイスが無効な PV を手動で削除します。
    2. 各ノードからシンボリックリンクを削除します。
    3. LocalVolume または LocalVolumeSet オブジェクトを削除します (ストレージ → 永続ストレージの設定 → ローカルボリュームを使用した永続ストレージ → ローカルストレージ Operator のリソースの削除 を参照)。

4.3.3. コントロールプレーン証明書の期限切れの状態からのリカバリー
リンクのコピー

クラスターはコントロールプレーン証明書の期限切れの状態から自動的に回復できます。

ただし、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。ユーザーによってプロビジョニングされるインストールの場合は、保留中の kubelet 提供の CSR を承認しないといけない場合があります。

保留中の CSR を承認するには、以下の手順に従います。

手順

  1. 現在の CSR の一覧を取得します。 

    $ oc get csr
    Copy to Clipboard Toggle word wrap

    出力例

    NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending
    1 
    
csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending
csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    2 
    
csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
...
    Copy to Clipboard Toggle word wrap

    1
    保留中の kubelet サービス CSR (ユーザーがプロビジョニングしたインストール用)。
    2
    保留中の node-bootstrapper CSR。

  2. CSR の詳細をレビューし、これが有効であることを確認します。 

    $ oc describe csr <csr_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    <csr_name> は、現行の CSR のリストからの CSR の名前です。

  3. それぞれの有効な node-bootstrapper CSR を承認します。 

    $ oc adm certificate approve <csr_name>
    Copy to Clipboard Toggle word wrap

  4. ユーザーによってプロビジョニングされるインストールの場合は、それぞれの有効な kubelet 提供の CSR を承認します。 

    $ oc adm certificate approve <csr_name>
    Copy to Clipboard Toggle word wrap

4.3.4. 復元手順のテスト
リンクのコピー

自動化とワークロードが新しいクラスターの状態を適切に処理できるように、復元手順をテストすることが重要です。etcd クォーラムの複雑な性質と、etcd Operator による自動修復が原因で、クラスターを復元可能な状態に正しく戻すことが困難な場合がよくあります。

警告

クラスターへの SSH アクセス権が 必要 です。SSH アクセスがないと、クラスターが完全に失われる可能性があります。

前提条件

  • コントロールプレーンホストへの SSH アクセス権がある。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. SSH を使用してリカバリーノード以外の各ノードに接続し、次のコマンドを実行して etcd と kubelet サービスを無効にします。

    1. 次のコマンドを実行して etcd を無効にします。 

      $ sudo /usr/local/bin/disable-etcd.sh
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、etcd の変数データを削除します。 

      $ sudo rm -rf /var/lib/etcd
      Copy to Clipboard Toggle word wrap

    3. 次のコマンドを実行して、kubelet サービスを無効にします。 

      $ sudo systemctl disable kubelet.service
      Copy to Clipboard Toggle word wrap
  2. すべての SSH セッションを終了します。

  3. 次のコマンドを実行して、リカバリーノード以外のノードが NOT READY 状態であることを確認します。 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap
  4. 「以前のクラスター状態への復元」の手順に従い、クラスターを復元します。

  5. クラスターを復元し、API が応答したら、SSH を使用してリカバリーノード以外の各ノードに接続し、kubelet サービスを有効にします。 

    $ sudo systemctl enable kubelet.service
    Copy to Clipboard Toggle word wrap
  6. すべての SSH セッションを終了します。

  7. 次のコマンドを実行して、ノードが READY 状態に戻ることを確認します。 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

  8. 次のコマンドを実行して、etcd が利用可能であることを確認します。 

    $ oc get pods -n openshift-etcd
    Copy to Clipboard Toggle word wrap

第5章 etcd 暗号化の有効化
リンクのコピー

5.1. etcd 暗号化について
リンクのコピー

デフォルトで、etcd データは OpenShift Container Platform で暗号化されません。クラスターの etcd 暗号化を有効にして、データセキュリティーのレイヤーを追加で提供することができます。たとえば、etcd バックアップが正しくない公開先に公開される場合に機密データが失われないように保護することができます。

etcd の暗号化を有効にすると、以下の OpenShift API サーバーおよび Kubernetes API サーバーリソースが暗号化されます。

  • シークレット
  • config map
  • ルート
  • OAuth アクセストークン
  • OAuth 認証トークン

etcd 暗号を有効にすると、暗号化キーが作成されます。etcd バックアップから復元するには、これらのキーが必要です。

注記

etcd 暗号化は、キーではなく、値のみを暗号化します。リソースの種類、namespace、およびオブジェクト名は暗号化されません。

バックアップ中に etcd 暗号化が有効になっている場合は、static_kuberesources_<datetimestamp>.tar.gz ファイルに etcd スナップショットの暗号化キーが含まれています。セキュリティー上の理由から、このファイルは etcd スナップショットとは別に保存してください。ただし、このファイルは、それぞれの etcd スナップショットから etcd の以前の状態を復元するために必要です。

5.2. サポートされている暗号化の種類
リンクのコピー

以下の暗号化タイプは、OpenShift Container Platform で etcd データを暗号化するためにサポートされています。

AES-CBC
暗号化を実行するために、PKCS#7 パディングと 32 バイトの鍵を含む AES-CBC を使用します。暗号化キーは毎週ローテーションされます。
AES-GCM
AES-GCM とランダムナンスおよび 32 バイトキーを使用して暗号化を実行します。暗号化キーは毎週ローテーションされます。

5.3. etcd 暗号化の有効化
リンクのコピー

etcd 暗号化を有効にして、クラスターで機密性の高いリソースを暗号化できます。

警告

初期暗号化プロセスが完了するまで、etcd リソースをバックアップしないでください。暗号化プロセスが完了しない場合、バックアップは一部のみ暗号化される可能性があります。

etcd 暗号化を有効にすると、いくつかの変更が発生する可能性があります。

  • etcd 暗号化は、いくつかのリソースのメモリー消費に影響を与える可能性があります。
  • リーダーがバックアップを提供する必要があるため、バックアップのパフォーマンスに一時的な影響が生じる場合があります。
  • ディスク I/O は、バックアップ状態を受け取るノードに影響を与える可能性があります。

etcd データベースは、AES-GCM または AES-CBC 暗号化で暗号化できます。

注記

etcd データベースをある暗号化タイプから別の暗号化タイプに移行するには、API サーバーの spec.encryption.type フィールドを変更します。etcd データの新しい暗号化タイプへの移行は自動的に行われます。

前提条件

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

手順

  1. APIServer オブジェクトを変更します。 

    $ oc edit apiserver
    Copy to Clipboard Toggle word wrap

  2. spec.encryption.type フィールドを aesgcm または aescbc に設定します。 

    spec:
  encryption:
    type: aesgcm
    1
    Copy to Clipboard Toggle word wrap
    1
    AES-CBC 暗号化の場合は aescbc に、AES-GCM 暗号化の場合は aesgcm に設定します。

  3. 変更を適用するためにファイルを保存します。

    暗号化プロセスが開始されます。etcd データベースのサイズによっては、このプロセスが完了するまでに 20 分以上かかる場合があります。

  4. etcd 暗号化が正常に行われたことを確認します。

    1. OpenShift API サーバーの Encrypted ステータスを確認し、そのリソースが正常に暗号化されたことを確認します。 

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      この出力には、暗号化が正常に実行されると EncryptionCompleted が表示されます。 

      EncryptionCompleted
All resources encrypted: routes.route.openshift.io
      Copy to Clipboard Toggle word wrap

      出力に EncryptionInProgress が表示される場合、これは暗号化が進行中であることを意味します。数分待機した後に再試行します。

    2. Kubernetes API サーバーの Encrypted ステータス状態を確認し、そのリソースが正常に暗号化されたことを確認します。 

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      この出力には、暗号化が正常に実行されると EncryptionCompleted が表示されます。 

      EncryptionCompleted
All resources encrypted: secrets, configmaps
      Copy to Clipboard Toggle word wrap

      出力に EncryptionInProgress が表示される場合、これは暗号化が進行中であることを意味します。数分待機した後に再試行します。

    3. OpenShift OAuth API サーバーの Encrypted ステータスを確認し、そのリソースが正常に暗号化されたことを確認します。 

      $ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      この出力には、暗号化が正常に実行されると EncryptionCompleted が表示されます。 

      EncryptionCompleted
All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io
      Copy to Clipboard Toggle word wrap

      出力に EncryptionInProgress が表示される場合、これは暗号化が進行中であることを意味します。数分待機した後に再試行します。

5.4. etcd 暗号化の無効化
リンクのコピー

クラスターで etcd データの暗号化を無効にできます。

前提条件

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

手順

  1. APIServer オブジェクトを変更します。 

    $ oc edit apiserver
    Copy to Clipboard Toggle word wrap

  2. encryption フィールドタイプを identity に設定します。 

    spec:
  encryption:
    type: identity
    1
    Copy to Clipboard Toggle word wrap
    1
    identity タイプはデフォルト値であり、暗号化は実行されないことを意味します。

  3. 変更を適用するためにファイルを保存します。

    復号化プロセスが開始されます。クラスターのサイズによっては、このプロセスが完了するまで 20 分以上かかる場合があります。

  4. etcd の復号化が正常に行われたことを確認します。

    1. OpenShift API サーバーの Encrypted ステータス条件を確認し、そのリソースが正常に暗号化されたことを確認します。 

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      この出力には、復号化が正常に実行されると DecryptionCompleted が表示されます。 

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

      出力に DecryptionInProgress が表示される場合、これは復号化が進行中であることを意味します。数分待機した後に再試行します。

    2. Kubernetes API サーバーの Encrypted ステータス状態を確認し、そのリソースが正常に復号化されたことを確認します。 

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      この出力には、復号化が正常に実行されると DecryptionCompleted が表示されます。 

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

      出力に DecryptionInProgress が表示される場合、これは復号化が進行中であることを意味します。数分待機した後に再試行します。

    3. OpenShift API サーバーの Encrypted ステータス条件を確認し、そのリソースが正常に復号化されたことを確認します。 

      $ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
      Copy to Clipboard Toggle word wrap

      この出力には、復号化が正常に実行されると DecryptionCompleted が表示されます。 

      DecryptionCompleted
Encryption mode set to identity and everything is decrypted
      Copy to Clipboard Toggle word wrap

      出力に DecryptionInProgress が表示される場合、これは復号化が進行中であることを意味します。数分待機した後に再試行します。

Legal Notice
リンクのコピー

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat