バックアップおよび復元

OpenShift Container Platform 4.3

OpenShift Container Platform クラスターのバックアップおよび復元

Red Hat OpenShift Documentation Team

概要

本書では、クラスターのデータのバックアップと、さまざまな障害関連のシナリオでの復旧方法について説明します。

第1章 etcd のバックアップ

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

クラスターの etcd データを定期的にバックアップし、OpenShift Container Platform 環境外の安全な場所に保存するのが理想的です。インストールの 24 時間後に行われる最初の証明書のローテーションが完了するまで etcd のバックアップを実行することはできません。ローテーションの完了前に実行すると、バックアップに期限切れの証明書が含まれることになります。さらに、ピーク時には障害が発生させる要素となる可能性があるため、ピーク時以外に etcd バックアップを取得することも推奨されています。

etcd のバックアップを取得した後に、マスターホストが失われた状態からの復旧や、クラスターの直前の状態への復元を実行できます。

etcd データのバックアッププロセスは、適切な証明書が提供されている etcd クラスターに接続できるマスターホストで実行できます。

1.1. etcd データのバックアップ

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

単一マスターホストからのバックアップのみを保存する必要があります。クラスター内の各マスターホストからのバックアップは必要ありません。

注記

OpenShift Container Platform 4.3.0 または 4.3.1 で etcd のバックアップを取る場合、この手順により、etcd スナップショットおよび静的 Kubernetes API サーバーリソースが含まれる単一ファイルが生成されます。復元時に、etcd-snapshot-restore.sh スクリプトには、この単一ファイルを受け入れるために必要な後方互換性があります。

前提条件

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

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

    ヒント

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

手順

  1. マスターノードのデバッグセッションを開始します。 

    $ oc debug node/<node_name>

  2. ルートディレクトリーをホストに切り替えます。 

    sh-4.2# chroot /host

  3. /home/core ディレクトリーに移動します。 

    sh-4.4# cd /home/core
  4. クラスター全体のプロキシーが有効になっている場合は、 NO_PROXY、HTTP_PROXY、および HTTPS_PROXY 環境変数をエクスポートしていることを確認します。

  5. etcd-snapshot-backup.sh スクリプトを実行し、バックアップの保存先となる場所を渡します。 

    sh-4.4# /usr/local/bin/etcd-snapshot-backup.sh /home/core/assets/backup

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

    • snapshot_<datetimestamp>.db: このファイルは etcd スナップショットです。

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

      注記

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

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

第2章 失敗したマスターホストの置き換え

本書では、単一 etcd メンバーを置き換えるプロセスについて説明します。この手順では、クラスターに依然として etcd のクォーラム（定足数）が存在することを前提としています。

注記

大多数のマスターホストが失われ、etcd のクォーラム（定足数）の損失が発生した場合は、この手順ではなく、失われたマスターホストからの回復に向けた障害復旧手順を実行する必要があります。

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

単一マスターホストを置き換えるには、以下を実行します。

2.1. 失敗したマスターホストの etcd クラスターからの削除

以下の手順に従って、失敗したマスターホストを etcd クラスターから削除します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • アクティブなマスターホストへの SSH アクセスがある。

手順

  1. etcd に関連付けられた Pod の一覧を表示します。

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

    $ oc get pods -n openshift-etcd
NAME                                                     READY   STATUS    RESTARTS   AGE
etcd-member-ip-10-0-128-73.us-east-2.compute.internal    2/2     Running   0          15h
etcd-member-ip-10-0-147-172.us-east-2.compute.internal   2/2     Running   7          122m
etcd-member-ip-10-0-171-108.us-east-2.compute.internal   2/2     Running   0          15h
  2. アクティブなマスターホストにアクセスします。

  3. etcd-member-remove.sh スクリプトを実行し、削除する etcd メンバーの名前を渡します。 

    [core@ip-10-0-128-73 ~]$ sudo -E /usr/local/bin/etcd-member-remove.sh etcd-member-ip-10-0-147-172.us-east-2.compute.internal
Downloading etcdctl binary..
etcdctl version: 3.3.10
API version: 3.3
etcd client certs already backed up and available ./assets/backup/
Member 23e4736df4451b32 removed from cluster 6e25bab1bb556673
etcd member etcd-member-ip-10-0-147-172.us-east-2.compute.internal with 23e4736df4451b32 successfully removed..

  4. etcd メンバーがクラスターから正常に削除されていることを確認します。

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

      [core@ip-10-0-128-73 ~] id=$(sudo crictl ps --name etcd-member | awk 'FNR==2{ print $1}') && sudo crictl exec -it $id /bin/sh

    2. etcd コンテナーで、etcd に接続するために必要な変数をエクスポートします。 

      sh-4.3# export ETCDCTL_API=3 ETCDCTL_CACERT=/etc/ssl/etcd/ca.crt ETCDCTL_CERT=$(find /etc/ssl/ -name *peer*crt) ETCDCTL_KEY=$(find /etc/ssl/ -name *peer*key)

    3. etcd コンテナーで、etcdctl member list を実行し、削除されたメンバーが一覧表示されていないことを確認します。 

      sh-4.3#  etcdctl member list -w table

+------------------+---------+------------------------------------------+------------------------------------------------------------------+---------------------------+
|        ID        | STATUS  |                   NAME                   |                            PEER ADDRS                            |       CLIENT ADDRS        |
+------------------+---------+------------------------------------------+------------------------------------------------------------------+---------------------------+
| 29e461db6be4eaaa | started | etcd-member-ip-10-0-128-73.us-east-2.compute.internal | https://etcd-2.clustername.devcluster.openshift.com:2380 | https://10.0.128.73:2379 |
|  cbe982c74cbb42f | started |  etcd-member-ip-10-0-171-108.us-east-2.compute.internal | https://etcd-1.clustername.devcluster.openshift.com:2380 |   https://10.0.171.108:2379 |
+------------------+---------+------------------------------------------+------------------------------------------------------------------+---------------------------+

2.2. メンバーをクラスターに戻す

etcd クラスターからメンバーを削除した後に、以下のいずれかの手順を使用してメンバーをクラスターに追加します。

2.2.1. マスターホストを etcd クラスターに戻す

マスターホストを etcd クラスターに追加するには、以下の手順に従います。この手順では、事前にマスターホストをクラスターから削除し、TLS 証明書や DNS などのその etcd 依存関係が有効であることを前提とします。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • etcd クラスターに追加するマスターホストへの SSH アクセスがある。
  • 既存のアクティブな etcd メンバーの IP アドレスがある。

手順

  1. etcd クラスターに追加するマスターホストにアクセスします。

    重要

    この手順は、etcd クラスターに追加されるマスターホストで実行する必要があります。

  2. etcd-member-add.sh スクリプトを実行し、2 つのパラメーターを渡します。

    • 既存の etcd メンバーの IP アドレス
    • 追加する etcd メンバーの名前 
    [core@ip-10-0-147-172 ~]$ sudo -E /usr/local/bin/etcd-member-add.sh \
10.0.128.73 \ 1
etcd-member-ip-10-0-147-172.us-east-2.compute.internal 2

Downloading etcdctl binary..
etcdctl version: 3.3.10
API version: 3.3
etcd-member.yaml found in ./assets/backup/
etcd.conf backup upready exists ./assets/backup/etcd.conf
Stopping etcd..
Waiting for etcd-member to stop
etcd data-dir backup found ./assets/backup/etcd..
Updating etcd membership..
Removing etcd data_dir /var/lib/etcd..

ETCD_NAME="etcd-member-ip-10-0-147-172.us-east-2.compute.internal"
ETCD_INITIAL_CLUSTER="etcd-member-ip-10-0-147-172.us-east-2.compute.internal=https://etcd-1.clustername.devcluster.openshift.com:2380,etcd-member-ip-10-0-171-108.us-east-2.compute.internal=https://etcd-2.clustername.devcluster.openshift.com:2380,etcd-member-ip-10-0-128-73.us-east-2.compute.internal=https://etcd-0.clustername.devcluster.openshift.com:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://etcd-1.clustername.devcluster.openshift.com:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"'
Member  1e42c7070decd39 added to cluster 6e25bab1bb556673
Starting etcd..
    1
    アクティブな etcd メンバーの IP アドレス。これは、追加しているメンバーの IP アドレス ではありません。
    2
    追加する etcd メンバーの名前。

  3. etcd メンバーが正常に etcd クラスターに追加されたことを確認します。

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

      [core@ip-10-0-147-172 ~] id=$(sudo crictl ps --name etcd-member | awk 'FNR==2{ print $1}') && sudo crictl exec -it $id /bin/sh

    2. etcd コンテナーで、etcd に接続するために必要な変数をエクスポートします。 

      sh-4.3# export ETCDCTL_API=3 ETCDCTL_CACERT=/etc/ssl/etcd/ca.crt ETCDCTL_CERT=$(find /etc/ssl/ -name *peer*crt) ETCDCTL_KEY=$(find /etc/ssl/ -name *peer*key)

    3. etcd コンテナーで、etcdctl member list を実行し、新規メンバーが一覧表示されていることを確認します。 

      sh-4.3#  etcdctl member list -w table

+------------------+---------+------------------------------------------+------------------------------------------------------------------+---------------------------+
|        ID        | STATUS  |                   NAME                   |                            PEER ADDRS                            |       CLIENT ADDRS        |
+------------------+---------+------------------------------------------+------------------------------------------------------------------+---------------------------+
| 29e461db6be4eaaa | started | etcd-member-ip-10-0-128-73.us-east-2.compute.internal | https://etcd-2.clustername.devcluster.openshift.com:2380 | https://10.0.128.73:2379 |
|  cbe982c74cbb42f | started | etcd-member-ip-10-0-147-172.us-east-2.compute.internal | https://etcd-0.clustername.devcluster.openshift.com:2380 | https://10.0.147.172:2379 |
| a752f80bcb0da3e8 | started |   etcd-member-ip-10-0-171-108.us-east-2.compute.internal | https://etcd-1.clustername.devcluster.openshift.com:2380 |   https://10.0.171.108:2379 |
+------------------+---------+------------------------------------------+------------------------------------------------------------------+---------------------------+

      新規メンバーが起動するまで最長 10 分の時間がかかる可能性があります。

    4. etcd コンテナーで、etcdctl endpoint health を実行し、新規メンバーの状態が正常であることを確認します。 

      sh-4.3# etcdctl endpoint health --cluster
https://10.0.128.73:2379 is healthy: successfully committed proposal: took = 4.5576ms
https://10.0.147.172:2379 is healthy: successfully committed proposal: took = 5.1521ms
https://10.0.171.108:2379 is healthy: successfully committed proposal: took = 4.2631ms

  4. 新規メンバーが etcd に関連付けられた Pod の一覧にあり、そのステータスが Runningであることを確認します。

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

    $ oc get pods -n openshift-etcd
NAME                                                     READY   STATUS    RESTARTS   AGE
etcd-member-ip-10-0-128-73.us-east-2.compute.internal    2/2     Running   0          15h
etcd-member-ip-10-0-147-172.us-east-2.compute.internal   2/2     Running   7          122m
etcd-member-ip-10-0-171-108.us-east-2.compute.internal   2/2     Running   0          15h

2.2.2. etcd 証明書の生成およびメンバーのクラスターへの追加

ノードが新規であるか、またはノードの etcd 証明書が有効でなくなった場合、メンバーを etcd クラスターに追加する前に etcd 証明書を生成する必要があります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • etcd クラスターに追加する新規マスターホストへの SSH アクセスがある。
  • 正常なマスターホストの 1 つへの SSH アクセスがある。
  • 正常なマスターホストのいずれかの IP アドレスがある。

手順

  1. 正常なマスターノードのいずれかに一時的な etcd 証明書の署名側のサービスを設定します。

    1. 正常なマスターノードの 1 つにアクセスし、以下のコマンドを使用して cluster-admin ユーザーとしてクラスターにログインします。 

      [core@ip-10-0-143-125 ~]$ sudo oc login https://localhost:6443
Authentication required for https://localhost:6443 (openshift)
Username: kubeadmin
Password:
Login successful.

    2. kube-etcd-signer-server イメージのプル仕様を取得します。 

      [core@ip-10-0-143-125 ~]$ export KUBE_ETCD_SIGNER_SERVER=$(sudo oc adm release info --image-for kube-etcd-signer-server --registry-config=/var/lib/kubelet/config.json)

    3. tokenize-signer.sh スクリプトを実行します。

      -E フラグを sudo に渡し、環境変数がスクリプトに適切に渡されるようにします。 

      [core@ip-10-0-143-125 ~]$ sudo -E /usr/local/bin/tokenize-signer.sh ip-10-0-143-125 1
Populating template /usr/local/share/openshift-recovery/template/kube-etcd-cert-signer.yaml.template
Populating template ./assets/tmp/kube-etcd-cert-signer.yaml.stage1
Tokenized template now ready: ./assets/manifests/kube-etcd-cert-signer.yaml
      1
      署名側のデプロイ先となる正常なマスターのホスト名。

    4. 生成されたファイルを使用して、署名側の Pod を作成します。 

      [core@ip-10-0-143-125 ~]$ sudo oc create -f assets/manifests/kube-etcd-cert-signer.yaml
pod/etcd-signer created

    5. 署名側がこのマスターノードでリッスンしていることを確認します。 

      [core@ip-10-0-143-125 ~]$ ss -ltn | grep 9943
LISTEN   0         128                       *:9943                   *:*

  2. 新規マスターホストを etcd クラスターに追加します。

    1. クラスターに追加される新規マスターホストにアクセスし、以下のコマンドを使用して cluster-admin ユーザーとしてクラスターにログインします。 

      [core@ip-10-0-156-255 ~]$ sudo oc login https://localhost:6443
Authentication required for https://localhost:6443 (openshift)
Username: kubeadmin
Password:
Login successful.

    2. etcd-member-recover.sh スクリプトで必要な 2 つの環境変数をエクスポートします。 

      [core@ip-10-0-156-255 ~]$ export SETUP_ETCD_ENVIRONMENT=$(sudo oc adm release info --image-for machine-config-operator --registry-config=/var/lib/kubelet/config.json)
      [core@ip-10-0-156-255 ~]$ export KUBE_CLIENT_AGENT=$(sudo oc adm release info --image-for kube-client-agent --registry-config=/var/lib/kubelet/config.json)

    3. etcd-member-recover.sh スクリプトを実行します。

      -E フラグを sudo に渡し、環境変数がスクリプトに適切に渡されるようにします。 

      [core@ip-10-0-156-255 ~]$ sudo -E /usr/local/bin/etcd-member-recover.sh 10.0.143.125 etcd-member-ip-10-0-156-255.ec2.internal 1
Downloading etcdctl binary..
etcdctl version: 3.3.10
API version: 3.3
etcd-member.yaml found in ./assets/backup/
etcd.conf backup upready exists ./assets/backup/etcd.conf
Trying to backup etcd client certs..
etcd client certs already backed up and available ./assets/backup/
Stopping etcd..
Waiting for etcd-member to stop
etcd data-dir backup found ./assets/backup/etcd..
etcd TLS certificate backups found in ./assets/backup..
Removing etcd certs..
Populating template /usr/local/share/openshift-recovery/template/etcd-generate-certs.yaml.template
Populating template ./assets/tmp/etcd-generate-certs.stage1
Populating template ./assets/tmp/etcd-generate-certs.stage2
Starting etcd client cert recovery agent..
Waiting for certs to generate..
Waiting for certs to generate..
Waiting for certs to generate..
Waiting for certs to generate..
Stopping cert recover..
Waiting for generate-certs to stop
Patching etcd-member manifest..
Updating etcd membership..
Member 249a4b9a790b3719 added to cluster 807ae3bffc8d69ca

ETCD_NAME="etcd-member-ip-10-0-156-255.ec2.internal"
ETCD_INITIAL_CLUSTER="etcd-member-ip-10-0-143-125.ec2.internal=https://etcd-0.clustername.devcluster.openshift.com:2380,etcd-member-ip-10-0-156-255.ec2.internal=https://etcd-1.clustername.devcluster.openshift.com:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://etcd-1.clustername.devcluster.openshift.com:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"
Starting etcd..
      1
      署名側のサーバーが実行されている正常なマスターの IP アドレスと、新規メンバーの etcd 名の両方を指定します。

    4. 新規マスターホストが etcd メンバーの一覧に追加されていることを確認します。

      1. 正常なマスターにアクセスし、実行中の etcd コンテナーに接続します。 

        [core@ip-10-0-143-125 ~] id=$(sudo crictl ps --name etcd-member | awk 'FNR==2{ print $1}') && sudo crictl exec -it $id /bin/sh

      2. etcd コンテナーで、etcd に接続するために必要な変数をエクスポートします。 

        sh-4.3# export ETCDCTL_API=3 ETCDCTL_CACERT=/etc/ssl/etcd/ca.crt ETCDCTL_CERT=$(find /etc/ssl/ -name *peer*crt) ETCDCTL_KEY=$(find /etc/ssl/ -name *peer*key)

      3. etcd コンテナーで、etcdctl member list を実行し、新規メンバーが一覧表示されていることを確認します。 

        sh-4.3#  etcdctl member list -w table

+------------------+---------+------------------------------------------+----------------------------------------------------------------+---------------------------+
|        ID        | STATUS  |                   NAME                   |                           PEER ADDRS                           |       CLIENT ADDRS        |
+------------------+---------+------------------------------------------+----------------------------------------------------------------+---------------------------+
|  cbe982c74cbb42f | started |  etcd-member-ip-10-0-156-255.ec2.internal | https://etcd-0.clustername.devcluster.openshift.com:2380 |  https://10.0.156.255:2379 |
| 249a4b9a790b3719 | started | etcd-member-ip-10-0-143-125.ec2.internal | https://etcd-1.clustername.devcluster.openshift.com:2380 | https://10.0.143.125:2379 |
+------------------+---------+------------------------------------------+----------------------------------------------------------------+---------------------------+

        新規メンバーが起動するまで最長 20 分の時間がかかる可能性があります。

  3. 新規メンバーの追加後に、署名側の Pod は不要になるため、これを削除します。

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

    $ oc delete pod -n openshift-config etcd-signer

第3章 障害復旧

3.1. 障害復旧について

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

マスターホストの失われた状態からのリカバリー

このソリューションは、大多数のマスターホストが失われたために etcd クォーラム(定足数) が失われ、クラスターがオフラインになる状態に対応します。etcd のバックアップを取得し、かつ少なくとも 1 つ以上の正常なマスターホストが残っている限り、以下の手順に従ってクラスターを復旧できます。

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

注記

大多数のマスターが依然として利用可能であり、etcd のクォーラムがある場合は、手順に従って単一の失敗したマスターホストの置き換えを実行します。

クラスターの直前の状態への復元

このソリューションは、管理者が重要なものを削除した場合など、クラスターを直前の状態に復元する必要がある状態に対応します。etcd バックアップを取得している限り、以下の手順に従ってクラスターを直前の状態に復元できます。

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

コントロールプレーン証明書の期限切れの状態からのリカバリー
このソリューションは、コントロールプレーン証明書の期限が切れた状態に対応します。たとえば、インストールの 24 時間後に行われる最初の証明書のローテーション前にクラスターをシャットダウンする場合、証明書はローテーションされず、期限切れになります。以下の手順に従って、コントロールプレーン証明書の期限切れの状態からのリカバリーを実行できます。

3.2. マスターホストの失われた状態からのリカバリー

以下では、マスターホストの完全に失われた状態からのリカバリープロセスについて説明します。大多数のマスターホストが失われたために etcd クォーラム(定足数) が失われ、クラスターがオフラインになる状態などがこれに該当します。この手順では、少なくとも 1 つ以上の正常なマスターホストがあることを前提とします。

概観すると、この手順では以下を実行します。

  1. 残りのマスターホストでクォーラム(定足数) を復元します。
  2. 新規マスターホストを作成します。
  3. DNS およびロードバランサーエントリーを修正します。
  4. etcd をフルメンバーシップに拡張します。

大多数のマスターホストが失われた場合、etcd のバックアップ が必要となり、残りのマスターホストで etcd クォーラム (定足数) を復元する必要があります。

注記

大多数のマスターが依然として利用可能であり、etcd のクォーラムがある場合は、手順に従って単一の失敗したマスターホストの置き換えを実行します。

3.2.1. マスターホストの失われた状態からのリカバリー

以下の手順に従って、etcd のクォーラム (定足数) が失われる状態をもたらす大多数のマスターホストの失われた状態からのリカバリーを実行します。

前提条件

  • cluster-admin ロールを持つユーザーとしてのクラスターへのアクセスがあること。
  • 残りのマスターホストへの SSH アクセス。

  • etcd スナップショットと静的 Kubernetes API サーバーリソースの両方を含むバックアップディレクトリー（同じバックアップから取られるもの)。ディレクトリー内のファイル名は、snapshot_<datetimestamp>.db および static_kuberesources_<datetimestamp>.tar.gz の形式にする必要があります。

    注記

    etcd バックアップが OpenShift Container Platform 4.3.0 または 4.3.1 から取得された場合、これは etcd スナップショットおよび静的 Kubernetes API サーバーリソースが含まれる単一ファイルになります。etcd-snapshot-restore.sh スクリプトは、この単一ファイルを受け入れるために必要な後方互換性があります。この形式は snapshot_db_kuberesources_<datetimestamp>.tar.gz になります。

手順

  1. 残りのマスターホストでクォーラム(定足数) を復元します。

    1. etcd バックアップディレクトリーを残りのマスターホストにコピーします。

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

    2. 残りのマスターホストにアクセスします。

    3. INITIAL_CLUSTER 変数を、 <name>=<url> 形式でメンバー一覧に追加します。この変数は復元スクリプトに渡されます。 この手順では、この時点で単一メンバーのみが存在することを前提とします。 

      [core@ip-10-0-143-125 ~]$ export INITIAL_CLUSTER="etcd-member-ip-10-0-143-125.ec2.internal=https://etcd-0.clustername.devcluster.openshift.com:2380"

    4. クラスター全体のプロキシーが有効になっている場合は、 NO_PROXY、HTTP_PROXY、および HTTPS_PROXY 環境変数をエクスポートしていることを確認します。

      ヒント

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

    5. etcd-snapshot-restore.sh スクリプトを実行します。

      2 つのパラメーターを etcd-snapshot-restore.sh スクリプトに渡します。それらは、etcd バックアップディレクトリーへのパスと INITIAL_CLUSTER 変数で定義されるメンバーの一覧です。

      -E フラグを sudo に渡し、環境変数がスクリプトに適切に渡されるようにします。 

      [core@ip-10-0-143-125 ~]$ sudo -E /usr/local/bin/etcd-snapshot-restore.sh /home/core/backup $INITIAL_CLUSTER
Creating asset directory ./assets
Downloading etcdctl binary..
etcdctl version: 3.3.10
API version: 3.3
Backing up /etc/kubernetes/manifests/etcd-member.yaml to ./assets/backup/
Stopping all static pods..
..stopping kube-scheduler-pod.yaml
..stopping kube-controller-manager-pod.yaml
..stopping kube-apiserver-pod.yaml
..stopping etcd-member.yaml
Stopping etcd..
Waiting for etcd-member to stop
Stopping kubelet..
Stopping all containers..
bd44e4bc942276eb1a6d4b48ecd9f5fe95570f54aa9c6b16939fa2d9b679e1ea
d88defb9da5ae623592b81619e3690faeb4fa645440e71c029812cb960ff586f
3920ced20723064a379739c4a586f909497a7b6705a5b3cf367d9b930f23a5f1
d470f7a2d962c90f3a21bcc021970bde96bc8908f317ec70f1c21720b322c25c
Backing up etcd data-dir..
Removing etcd data-dir /var/lib/etcd
Restoring etcd member etcd-member-ip-10-0-143-125.ec2.internal from snapshot..
2019-05-15 19:03:34.647589 I | pkg/netutil: resolving etcd-0.clustername.devcluster.openshift.com:2380 to 10.0.143.125:2380
2019-05-15 19:03:34.883545 I | mvcc: restore compact to 361491
2019-05-15 19:03:34.915679 I | etcdserver/membership: added member cbe982c74cbb42f [https://etcd-0.clustername.devcluster.openshift.com:2380] to cluster 807ae3bffc8d69ca
Starting static pods..
..starting kube-scheduler-pod.yaml
..starting kube-controller-manager-pod.yaml
..starting kube-apiserver-pod.yaml
..starting etcd-member.yaml
Starting kubelet..

      etcd-snapshot-restore.sh スクリプトが完了すると、クラスターでは単一メンバーの etcd クラスターを確認でき、API サービスは再起動を開始します。これには最長 15 分の時間がかかる可能性があります。

      クラスターにアクセスできるターミナルで、以下のコマンドを実行し、クラスターが準備状態にあることを確認します。 

      $ oc get nodes -l node-role.kubernetes.io/master
NAME                                         STATUS   ROLES    AGE   VERSION
ip-10-0-143-125.us-east-2.compute.internal   Ready    master   46m   v1.16.2
      注記

      置き換えられる古い etcd メンバーがすべてシャットダウンしていることを確認します。シャットダウンしていない場合には、それらが新規クラスターへの接続を試行し、以下のようなエラーをログに報告します。 

      2019-05-20 15:33:17.648445 E | rafthttp: request cluster ID mismatch (got 9f5f9f05e4d43b7f want 807ae3bffc8d69ca)

  2. 新規マスターホストを作成します。

    クラスターでマシン API が有効にされており、かつ機能する場合、OpenShift machine-api Operator が復元すると、新規マスターが作成されます。しかし、machine-api Operator が有効にされていない場合は、最初にマスターを作成するために使用した方法と同じ方法を使って新規マスターを作成する必要があります。

    また、これらの新規マスターホストの証明書署名要求 (CSR) を承認する必要もあります。クラスターに追加された各マシンについて 2 つの保留状態の CSR が生成されます。

    1. クラスターにアクセスできるターミナルで、以下のコマンドを実行し、CSR を承認します。

      1. 現在の CSR の一覧を取得します。 

        $ oc get csr

      2. CSR の詳細をレビューし、これが有効であることを確認します。 

        $ oc describe csr <csr_name> 1
        1
        <csr_name> は、現行の CSR の一覧からの CSR の名前です。

      3. それぞれの有効な CSR を承認します。 

        $ oc adm certificate approve <csr_name>

        クラスターに追加されたそれぞれのマスターについての保留状態のクライアントおよびサーバー CSR の両方を承認します。

    2. クラスターにアクセスできるターミナルで、以下のコマンドを実行し、マスターが準備状態にあることを確認します。 

      $ oc get nodes -l node-role.kubernetes.io/master
NAME                                         STATUS   ROLES    AGE   VERSION
ip-10-0-143-125.us-east-2.compute.internal   Ready    master   50m   v1.16.2
ip-10-0-156-255.us-east-2.compute.internal   Ready    master   92s   v1.16.2
ip-10-0-162-178.us-east-2.compute.internal   Ready    master   70s   v1.16.2

  3. DNS エントリーを修正します。

    1. AWS コンソールで、プライベート DNS ゾーンにある etcd-0、etcd-1、および etcd-2 Route 53 レコードを確認し、必要な場合には、値を適切な新規のプライベート IP アドレスに更新します。具体的な方法については、AWS ドキュメントの「 Editing Records 」を参照してください。

      クラスターにアクセスできるターミナルで以下のコマンドを実行して、インスタンスのプライベート IP アドレスを取得できます。 

      $ oc get node ip-10-0-143-125.us-east-2.compute.internal -o  jsonpath='{.status.addresses[?(@.type=="InternalIP")].address}{"\n"}'
10.0.143.125

  4. ロードバランサーのエントリーを更新します。

    クラスターで管理されるロードバランサーを使用している場合、エントリーは自動的に更新されます。このロードバランサーを使用していない場合には、お使いのロードバランサーをマスターホストの現在のアドレスで更新してください。

    負荷分散が AWS によって管理されている場合には、ロードバランサーのエントリーを更新する方法について、AWS ドキュメントの「Register or Deregister Targets by IP Address 」を参照してください。

  5. etcd をフルメンバーシップに拡張します。

    1. etcd を復元したマスターで、一時的な etcd 証明書の署名側サービスをセットアップします。

      1. 元のマスターにアクセスし、以下のコマンドを使用して cluster-admin ユーザーとしてクラスターにログインします。 

        [core@ip-10-0-143-125 ~]$ sudo oc login https://localhost:6443
Authentication required for https://localhost:6443 (openshift)
Username: kubeadmin
Password:
Login successful.

      2. kube-etcd-signer-server イメージのプル仕様を取得します。 

        [core@ip-10-0-143-125 ~]$ export KUBE_ETCD_SIGNER_SERVER=$(sudo oc adm release info --image-for kube-etcd-signer-server --registry-config=/var/lib/kubelet/config.json)

      3. tokenize-signer.sh スクリプトを実行します。

        -E フラグを sudo に渡し、環境変数がスクリプトに適切に渡されるようにします。 

        [core@ip-10-0-143-125 ~]$ sudo -E /usr/local/bin/tokenize-signer.sh ip-10-0-143-125 1
Populating template /usr/local/share/openshift-recovery/template/kube-etcd-cert-signer.yaml.template
Populating template ./assets/tmp/kube-etcd-cert-signer.yaml.stage1
Tokenized template now ready: ./assets/manifests/kube-etcd-cert-signer.yaml
        1
        復元したばかりの元のマスターのホスト名です。 ここに署名側のデプロイが行われる必要があります。

      4. 生成されたファイルを使用して、署名側の Pod を作成します。 

        [core@ip-10-0-143-125 ~]$ sudo oc create -f assets/manifests/kube-etcd-cert-signer.yaml
pod/etcd-signer created

      5. 署名側がこのマスターノードでリッスンしていることを確認します。 

        [core@ip-10-0-143-125 ~]$ ss -ltn | grep 9943
LISTEN   0         128                       *:9943                   *:*

    2. 新規マスターホストを etcd クラスターに追加します。

      1. 新規マスターホストの 1 つにアクセスし、以下のコマンドを使用して cluster-admin ユーザーとしてクラスターにログインします。 

        [core@ip-10-0-156-255 ~]$ sudo oc login https://localhost:6443
Authentication required for https://localhost:6443 (openshift)
Username: kubeadmin
Password:
Login successful.

      2. etcd-member-recover.sh スクリプトで必要な 2 つの環境変数をエクスポートします。 

        [core@ip-10-0-156-255 ~]$ export SETUP_ETCD_ENVIRONMENT=$(sudo oc adm release info --image-for machine-config-operator --registry-config=/var/lib/kubelet/config.json)
        [core@ip-10-0-156-255 ~]$ export KUBE_CLIENT_AGENT=$(sudo oc adm release info --image-for kube-client-agent --registry-config=/var/lib/kubelet/config.json)

      3. etcd-member-recover.sh スクリプトを実行します。

        -E フラグを sudo に渡し、環境変数がスクリプトに適切に渡されるようにします。 

        [core@ip-10-0-156-255 ~]$ sudo -E /usr/local/bin/etcd-member-recover.sh 10.0.143.125 etcd-member-ip-10-0-156-255.ec2.internal 1
Downloading etcdctl binary..
etcdctl version: 3.3.10
API version: 3.3
etcd-member.yaml found in ./assets/backup/
etcd.conf backup upready exists ./assets/backup/etcd.conf
Trying to backup etcd client certs..
etcd client certs already backed up and available ./assets/backup/
Stopping etcd..
Waiting for etcd-member to stop
etcd data-dir backup found ./assets/backup/etcd..
etcd TLS certificate backups found in ./assets/backup..
Removing etcd certs..
Populating template /usr/local/share/openshift-recovery/template/etcd-generate-certs.yaml.template
Populating template ./assets/tmp/etcd-generate-certs.stage1
Populating template ./assets/tmp/etcd-generate-certs.stage2
Starting etcd client cert recovery agent..
Waiting for certs to generate..
Waiting for certs to generate..
Waiting for certs to generate..
Waiting for certs to generate..
Stopping cert recover..
Waiting for generate-certs to stop
Patching etcd-member manifest..
Updating etcd membership..
Member 249a4b9a790b3719 added to cluster 807ae3bffc8d69ca

ETCD_NAME="etcd-member-ip-10-0-156-255.ec2.internal"
ETCD_INITIAL_CLUSTER="etcd-member-ip-10-0-143-125.ec2.internal=https://etcd-0.clustername.devcluster.openshift.com:2380,etcd-member-ip-10-0-156-255.ec2.internal=https://etcd-1.clustername.devcluster.openshift.com:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://etcd-1.clustername.devcluster.openshift.com:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"
Starting etcd..
        1
        署名側のサーバーが実行されている元のマスターの IP アドレスと、新規メンバーの etcd 名の両方を指定します。

      4. 新規マスターホストが etcd メンバーの一覧に追加されていることを確認します。

        1. 元のマスターにアクセスし、実行中の etcd コンテナーに接続します。 

          [core@ip-10-0-143-125 ~] id=$(sudo crictl ps --name etcd-member | awk 'FNR==2{ print $1}') && sudo crictl exec -it $id /bin/sh

        2. etcd コンテナーで、etcd に接続するために必要な変数をエクスポートします。 

          sh-4.3# export ETCDCTL_API=3 ETCDCTL_CACERT=/etc/ssl/etcd/ca.crt ETCDCTL_CERT=$(find /etc/ssl/ -name *peer*crt) ETCDCTL_KEY=$(find /etc/ssl/ -name *peer*key)

        3. etcd コンテナーで、etcdctl member list を実行し、新規メンバーが一覧表示されていることを確認します。 

          sh-4.3#  etcdctl member list -w table

+------------------+---------+------------------------------------------+----------------------------------------------------------------+---------------------------+
|        ID        | STATUS  |                   NAME                   |                           PEER ADDRS                           |       CLIENT ADDRS        |
+------------------+---------+------------------------------------------+----------------------------------------------------------------+---------------------------+
|  cbe982c74cbb42f | started |  etcd-member-ip-10-0-156-255.ec2.internal | https://etcd-0.clustername.devcluster.openshift.com:2380 |  https://10.0.156.255:2379 |
| 249a4b9a790b3719 | started | etcd-member-ip-10-0-143-125.ec2.internal | https://etcd-1.clustername.devcluster.openshift.com:2380 | https://10.0.143.125:2379 |
+------------------+---------+------------------------------------------+----------------------------------------------------------------+---------------------------+

          新規メンバーが起動するまで最長 20 分の時間がかかる可能性があります。

      5. これらの手順を繰り返し実行し、etcd のフルメンバーシップに達するまで他の新規マスターホストを追加します。

    3. すべてのメンバーが復元された後に、署名側 Pod は不要になるため、これを削除します。

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

      $ oc delete pod -n openshift-config etcd-signer

この手順の完了後、すべてのサービスを復元するまでに数分かかる場合があります。たとえば、oc login を使用した認証は、OAuth サーバー Pod が再起動するまですぐに機能しない可能性があります。

3.3. クラスターの直前の状態への復元

クラスターを直前の状態に復元するには、スナップショットを作成して、事前に etcd データのバックアップを行っている必要があります。このスナップショットを使用して、クラスターの状態を復元します。

3.3.1. クラスターの直前の状態への復元

保存された etcd バックアップを使用して、クラスターの以前の状態に戻すことができます。

前提条件

  • cluster-admin ロールを持つユーザーとしてのクラスターへのアクセスがあること。
  • マスターホストへの SSH アクセス。

  • etcd スナップショットと静的 Kubernetes API サーバーリソースの両方を含むバックアップディレクトリー（同じバックアップから取られるもの)。ディレクトリー内のファイル名は、snapshot_<datetimestamp>.db および static_kuberesources_<datetimestamp>.tar.gz の形式にする必要があります。

    注記

    クラスター内のすべてのマスターホストで同じ etcd バックアップディレクトリーを使用する必要があります。

    注記

    etcd バックアップが OpenShift Container Platform 4.3.0 または 4.3.1 から取得された場合、これは etcd スナップショットおよび静的 Kubernetes API サーバーリソースが含まれる単一ファイルになります。etcd-snapshot-restore.sh スクリプトは、この単一ファイルを受け入れるために必要な後方互換性があります。この形式は snapshot_db_kuberesources_<datetimestamp>.tar.gz になります。

手順

  1. 復元するクラスター内のそれぞれのマスターホストを準備します。

    短期間でマスターホストのすべてに復元スクリプトを実行し、クラスターのメンバーがほぼ同時に起動し、クォーラム(定足数) を構成できるようにする必要がありなす。そのため、それぞれのマスターホストを別々のターミナルに分け、復元スクリプトをそれぞれに対して迅速に開始できるようにすることが推奨されます。

    1. etcd バックアップディレクトリーをマスターホストにコピーします。

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

    2. マスターホストにアクセスします。

    3. INITIAL_CLUSTER 変数を、 <name>=<url> 形式でメンバー一覧に追加します。この変数は復元スクリプトに渡され、各メンバーに同一の変数が使用される必要があります。 

      [core@ip-10-0-143-125 ~]$ export INITIAL_CLUSTER="etcd-member-ip-10-0-143-125.ec2.internal=https://etcd-0.clustername.devcluster.openshift.com:2380,etcd-member-ip-10-0-35-108.ec2.internal=https://etcd-1.clustername.devcluster.openshift.com:2380,etcd-member-ip-10-0-10-16.ec2.internal=https://etcd-2.clustername.devcluster.openshift.com:2380"

    4. クラスター全体のプロキシーが有効になっている場合は、 NO_PROXY、HTTP_PROXY、および HTTPS_PROXY 環境変数をエクスポートしていることを確認します。

      ヒント

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

    5. これらの手順を他のマスターホストで繰り返し実行します。 その際、各マスターホストをそれぞれのターミナルで処理します。各マスターホストの同じバックアップファイルセットを含むバックアップディレクトリーを使用するようにしてください。

  2. すべてのマスターホストで復元スクリプトを実行します。

    1. 最初のマスターホストで etcd-snapshot-restore.sh スクリプトを開始します。etcd バックアップディレクトリーのパスと、INITIAL_CLUSTER 変数で定義されるメンバーの一覧の 2 つのパラメーターを渡します。 

      [core@ip-10-0-143-125 ~]$ sudo -E /usr/local/bin/etcd-snapshot-restore.sh /home/core/backup $INITIAL_CLUSTER
Creating asset directory ./assets
Downloading etcdctl binary..
etcdctl version: 3.3.10
API version: 3.3
Backing up /etc/kubernetes/manifests/etcd-member.yaml to ./assets/backup/
Stopping all static pods..
..stopping kube-scheduler-pod.yaml
..stopping kube-controller-manager-pod.yaml
..stopping kube-apiserver-pod.yaml
..stopping etcd-member.yaml
Stopping etcd..
Waiting for etcd-member to stop
Stopping kubelet..
Stopping all containers..
bd44e4bc942276eb1a6d4b48ecd9f5fe95570f54aa9c6b16939fa2d9b679e1ea
d88defb9da5ae623592b81619e3690faeb4fa645440e71c029812cb960ff586f
3920ced20723064a379739c4a586f909497a7b6705a5b3cf367d9b930f23a5f1
d470f7a2d962c90f3a21bcc021970bde96bc8908f317ec70f1c21720b322c25c
Backing up etcd data-dir..
Removing etcd data-dir /var/lib/etcd
Restoring etcd member etcd-member-ip-10-0-143-125.ec2.internal from snapshot..
2019-05-15 19:03:34.647589 I | pkg/netutil: resolving etcd-0.clustername.devcluster.openshift.com:2380 to 10.0.143.125:2380
2019-05-15 19:03:34.883545 I | mvcc: restore compact to 361491
2019-05-15 19:03:34.915679 I | etcdserver/membership: added member cbe982c74cbb42f [https://etcd-0.clustername.devcluster.openshift.com:2380] to cluster 807ae3bffc8d69ca
Starting static pods..
..starting kube-scheduler-pod.yaml
..starting kube-controller-manager-pod.yaml
..starting kube-apiserver-pod.yaml
..starting etcd-member.yaml
Starting kubelet..
    2. 復元が開始されたら、他のマスターホストでスクリプトを実行します。

  3. マシン設定 (Machine Config) が適用されていることを確認します。

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

    $ oc get machineconfigpool
NAME     CONFIG                                             UPDATED   UPDATING
master   rendered-master-50e7e00374e80b767fcc922bdfbc522b   True      False

    スナップショットが適用されると、マスターの currentConfig は etcd スナップショットの取られた時点の ID に一致します。マスターの currentConfig 名は rendered-master-<currentConfig> 形式の名前になります。

  4. すべてのマスターホストが起動しており、クラスターに参加していることを確認します。

    1. マスターホストにアクセスし、実行中の etcd コンテナーに接続します。 

      [core@ip-10-0-143-125 ~] id=$(sudo crictl ps --name etcd-member | awk 'FNR==2{ print $1}') && sudo crictl exec -it $id /bin/sh

    2. etcd コンテナーで、etcd に接続するために必要な変数をエクスポートします。 

      sh-4.3# export ETCDCTL_API=3 ETCDCTL_CACERT=/etc/ssl/etcd/ca.crt ETCDCTL_CERT=$(find /etc/ssl/ -name *peer*crt) ETCDCTL_KEY=$(find /etc/ssl/ -name *peer*key)

    3. etcd コンテナーで、etcdctl member list を実行し、3 つのメンバーが起動済みであることを確認します。 

      sh-4.3#  etcdctl member list -w table

+------------------+---------+------------------------------------------+------------------------------------------------------------------+---------------------------+
|        ID        | STATUS  |                   NAME                   |                            PEER ADDRS                            |       CLIENT ADDRS        |
+------------------+---------+------------------------------------------+------------------------------------------------------------------+---------------------------+
| 29e461db6be4eaaa | started | etcd-member-ip-10-0-164-170.ec2.internal | https://etcd-2.clustername.devcluster.openshift.com:2380 | https://10.0.164.170:2379 |
|  cbe982c74cbb42f | started | etcd-member-ip-10-0-143-125.ec2.internal | https://etcd-0.clustername.devcluster.openshift.com:2380 | https://10.0.143.125:2379 |
| a752f80bcb0da3e8 | started |   etcd-member-ip-10-0-156-2.ec2.internal | https://etcd-1.clustername.devcluster.openshift.com:2380 |   https://10.0.156.2:2379 |
+------------------+---------+------------------------------------------+------------------------------------------------------------------+---------------------------+

      それぞれの新規メンバーが起動するまでに最長 20 分の時間がかかる可能性があります。

3.4. コントロールプレーン証明書の期限切れの状態からのリカバリー

3.4.1. コントロールプレーン証明書の期限切れの状態からのリカバリー

以下の手順に従い、コントロールプレーンの証明書の期限が切れの状態からのリカバリーを実行します。

前提条件

  • マスターホストへの SSH アクセス。

手順

  1. root ユーザーとして、証明書が期限切れになっているマスターホストにアクセスします。

  2. リリースの cluster-kube-apiserver-operator イメージ参照を取得します。 

    # RELEASE_IMAGE=<release_image> 1
    1
    <release_image> のサンプルの値は quay.io/openshift-release-dev/ocp-release:4.3.0-x86_64 です。利用可能なタグの一覧については、「Repository Tags」ページを参照してください。 
    # KAO_IMAGE=$( oc adm release info --registry-config='/var/lib/kubelet/config.json' "${RELEASE_IMAGE}" --image-for=cluster-kube-apiserver-operator )

  3. cluster-kube-apiserver-operator イメージをプルします。 

    # podman pull --authfile=/var/lib/kubelet/config.json "${KAO_IMAGE}"

  4. リカバリー API サーバーを作成します。 

    # podman run -it --network=host -v /etc/kubernetes/:/etc/kubernetes/:Z --entrypoint=/usr/bin/cluster-kube-apiserver-operator "${KAO_IMAGE}" recovery-apiserver create

  5. 上記コマンドの出力から export KUBECONFIG コマンドを実行します。 これはこの手順の後の部分の oc コマンドで必要になります。 

    # export KUBECONFIG=/<path_to_recovery_kubeconfig>/admin.kubeconfig

  6. リカバリー API サーバーの起動を待機します。 

    # until oc get namespace kube-system 2>/dev/null 1>&2; do echo 'Waiting for recovery apiserver to come up.'; sleep 1; done

  7. regenerate-certificates コマンドを実行します。これは API の証明書を修正し、ローカルドライブの古い証明書を上書きし、静的 Pod を再起動して上書き内容を取得できるようにします。 

    # podman run -it --network=host -v /etc/kubernetes/:/etc/kubernetes/:Z --entrypoint=/usr/bin/cluster-kube-apiserver-operator "${KAO_IMAGE}" regenerate-certificates

  8. 証明書が API で修正されたら、以下のコマンドを使用してコントロールプレーンの新規ロールアウトを強制実行します。これは、kubelet が内部ロードバランサーを使用して API サーバーに接続されているため、他のノードにも再インストールされます。 

    # oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    # oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
    # oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

  9. 有効なユーザーとしてブートストラップ kubeconfig を作成します。

    1. recover-kubeconfig.sh スクリプトを実行し、出力を kubeconfigというファイルに保存します。 

      # recover-kubeconfig.sh > kubeconfig
    2. kubeconfig ファイルをすべてのマスターホストにコピーし、これを /etc/kubernetes/kubeconfig に移動します。

    3. API サーバーからの接続を検証するために使用する CA 証明書を取得します。 

      # oc get configmap kube-apiserver-to-kubelet-client-ca -n openshift-kube-apiserver-operator --template='{{ index .data "ca-bundle.crt" }}' > /etc/kubernetes/kubelet-ca.crt
    4. /etc/kubernetes/kubelet-ca.crt ファイルをその他すべてのマスターホストおよびノードにコピーします。

    5. すべてのマスターホストおよびノードに machine-config-daemon-force ファイルを追加して、Machine Config Daemon がこの証明書の更新を受け入れるようにします。 

      # touch /run/machine-config-daemon-force

  10. すべてのマスターで kubelet を回復します。

    1. マスターホストで、kubelet を停止します。 

      # systemctl stop kubelet

    2. 古い kubelet データを削除します。 

      # rm -rf /var/lib/kubelet/pki /var/lib/kubelet/kubeconfig

    3. kubelet を再起動します。 

      # systemctl start kubelet
    4. 他のすべてのマスターホストでこれらの手順を繰り返し実行します。

  11. 必要な場合には、ワーカーノードで kubelet を回復します。

    マスターノードの復元後、ワーカーノードはそれら自体を復元する可能性があります。これは、oc get nodes コマンドを実行して確認できます。ワーカーノードが一覧表示されない場合には、各ワーカーノードで以下の手順を実行します。

    1. kubelet を停止します。 

      # systemctl stop kubelet

    2. 古い kubelet データを削除します。 

      # rm -rf /var/lib/kubelet/pki /var/lib/kubelet/kubeconfig

    3. kubelet を再起動します。 

      # systemctl start kubelet

  12. 保留状態の node-bootstrapper 証明書署名要求 (CSR) を承認します。

    1. 現在の CSR の一覧を取得します。 

      # oc get csr

    2. CSR の詳細をレビューし、これが有効であることを確認します。 

      # oc describe csr <csr_name> 1
      1
      <csr_name> は、現行の CSR の一覧からの CSR の名前です。

    3. それぞれの有効な CSR を承認します。 

      # oc adm certificate approve <csr_name>

      保留状態のすべての node-bootstrapper CSR を承認するようにしてください。

  13. リカバリー API サーバーは不要になるため、これを削除します。 

    # podman run -it --network=host -v /etc/kubernetes/:/etc/kubernetes/:Z --entrypoint=/usr/bin/cluster-kube-apiserver-operator "${KAO_IMAGE}" recovery-apiserver destroy

    コントロールプレーンが再起動し、新規証明書を取得するまで待機します。これには、最長 10 分の時間がかかる可能性があります。

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat 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 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.