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

手順

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

2. リカバリーホストを含む、各コントロールプレーンノードへの SSH 接続を確立します。

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

   重要

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

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

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

4. 他のすべてのコントロールプレーンノードで静的 Pod を停止します。

   注記

   リカバリーホストで Pod を手動で停止する必要はありません。リカバリースクリプトは、リカバリーホストの Pod を停止します。

   1. リカバリーホストではないコントロールプレーンホストにアクセスします。

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

      $ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp

      Copy to Clipboard Toggle word wrap

   3. etcd Pod が停止していることを確認します。

      $ sudo crictl ps | grep etcd | grep -v operator

      Copy to Clipboard Toggle word wrap

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

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

      $ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp

      Copy to Clipboard Toggle word wrap

   5. Kubernetes API サーバー Pod が停止していることを確認します。

      $ sudo crictl ps | grep kube-apiserver | grep -v operator

      Copy to Clipboard Toggle word wrap

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

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

      $ sudo mv /var/lib/etcd/ /tmp

      Copy to Clipboard Toggle word wrap
   7. リカバリーホストではない他のコントロールプレーンホストでこの手順を繰り返します。
5. リカバリーコントロールプレーンホストにアクセスします。

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

   ヒント

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

7. リカバリーコントロールプレーンホストで復元スクリプトを実行し、パスを etcd バックアップディレクトリーに渡します。

   $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/backup

   Copy to Clipboard Toggle word wrap

   スクリプトの出力例

   ...stopping kube-scheduler-pod.yaml
   ...stopping kube-controller-manager-pod.yaml
   ...stopping etcd-pod.yaml
   ...stopping kube-apiserver-pod.yaml
   Waiting for container etcd to stop
   .complete
   Waiting for container etcdctl to stop
   .............................complete
   Waiting for container etcd-metrics to stop
   complete
   Waiting for container kube-controller-manager to stop
   complete
   Waiting for container kube-apiserver to stop
   ..........................................................................................complete
   Waiting for container kube-scheduler to stop
   complete
   Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup
   starting restore-etcd static pod
   starting kube-apiserver-pod.yaml
   static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml
   starting kube-controller-manager-pod.yaml
   static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml
   starting kube-scheduler-pod.yaml
   static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml

   Copy to Clipboard Toggle word wrap

   注記

   最後の etcd バックアップの後にノード証明書が更新された場合、復元プロセスによってノードが NotReady 状態になる可能性があります。

8. ノードをチェックして、Ready 状態であることを確認します。

   1. 以下のコマンドを実行します。

      $ oc get nodes -w

      Copy to Clipboard Toggle word wrap

      出力例

      NAME                STATUS  ROLES          AGE     VERSION
      host-172-25-75-28   Ready   master         3d20h   v1.23.3+e419edf
      host-172-25-75-38   Ready   infra,worker   3d20h   v1.23.3+e419edf
      host-172-25-75-40   Ready   master         3d20h   v1.23.3+e419edf
      host-172-25-75-65   Ready   master         3d20h   v1.23.3+e419edf
      host-172-25-75-74   Ready   infra,worker   3d20h   v1.23.3+e419edf
      host-172-25-75-79   Ready   worker         3d20h   v1.23.3+e419edf
      host-172-25-75-86   Ready   worker         3d20h   v1.23.3+e419edf
      host-172-25-75-98   Ready   infra,worker   3d20h   v1.23.3+e419edf

      Copy to Clipboard Toggle word wrap

      すべてのノードが状態を報告するのに数分かかる場合があります。

   2. NotReady 状態のノードがある場合は、ノードにログインし、各ノードの /var/lib/kubelet/pki ディレクトリーからすべての PEM ファイルを削除します。ノードに SSH 接続するか、Web コンソールのターミナルウィンドウを使用できます。

      $  ssh -i <ssh-key-path> core@<master-hostname>

      Copy to Clipboard Toggle word wrap

      サンプル pki ディレクトリー

      sh-4.4# pwd
      /var/lib/kubelet/pki
      sh-4.4# ls
      kubelet-client-2022-04-28-11-24-09.pem  kubelet-server-2022-04-28-11-24-15.pem
      kubelet-client-current.pem              kubelet-server-current.pem

      Copy to Clipboard Toggle word wrap

9. すべてのコントロールプレーンホストで kubelet サービスを再起動します。

   1. リカバリーホストから以下のコマンドを実行します。

      $ sudo systemctl restart kubelet.service

      Copy to Clipboard Toggle word wrap
   2. 他のすべてのコントロールプレーンホストでこの手順を繰り返します。

10. 保留中の 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 

       2

       
       csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 

       3

       
       csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 

       4

       
       ...

       Copy to Clipboard Toggle word wrap

       1 1 2

       保留中の kubelet サービス CSR (ユーザーがプロビジョニングしたインストール用)。

       3 4

       保留中の 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

11. 単一メンバーのコントロールプレーンが正常に起動していることを確認します。

    1. リカバリーホストから etcd コンテナーが実行中であることを確認します。

       $ sudo crictl ps | grep etcd | grep -v operator

       Copy to Clipboard Toggle word wrap

       出力例

       3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0

       Copy to Clipboard Toggle word wrap

    2. リカバリーホストから、etcd Pod が実行されていることを確認します。

       $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

       Copy to Clipboard Toggle word wrap
       注記

       このコマンドを実行する前に oc login の実行を試行し、以下のエラーを受信すると、認証コントローラーが起動し、再試行するまでしばらく待機します。

       Unable to connect to the server: EOF

       Copy to Clipboard Toggle word wrap

       出力例

       NAME                                             READY   STATUS      RESTARTS   AGE
       etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s

       Copy to Clipboard Toggle word wrap

       ステータスが Pending の場合や出力に複数の実行中の etcd Pod が一覧表示される場合、数分待機してから再度チェックを行います。

12. 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 クラスター Operator が再デプロイメントを実行すると、初期ブートストラップのスケールアップと同様に、既存のノードが新規 Pod と共に起動します。

13. すべてのノードが最新のリビジョンに更新されていることを確認します。

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

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

    Copy to Clipboard Toggle word wrap

    etcd の NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。

    AllNodesAtLatestRevision
    3 nodes are at revision 7 

    1

    Copy to Clipboard Toggle word wrap

    1

    この例では、最新のリビジョン番号は 7 です。

    出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。

14. etcd の再デプロイ後に、コントロールプレーンの新規ロールアウトを強制的に実行します。kubelet が内部ロードバランサーを使用して API サーバーに接続されているため、Kubernetes API サーバーは他のノードに再インストールされます。

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

    1. Kubernetes API サーバーの新規ロールアウトを強制的に実行します。

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

       Copy to Clipboard Toggle word wrap

       すべてのノードが最新のリビジョンに更新されていることを確認します。

       $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       Copy to Clipboard Toggle word wrap

       NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。

       AllNodesAtLatestRevision
       3 nodes are at revision 7 

       1

       Copy to Clipboard Toggle word wrap

       1

       この例では、最新のリビジョン番号は 7 です。

       出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。

    2. Kubernetes コントローラーマネージャーの新規ロールアウトを強制的に実行します。

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

       Copy to Clipboard Toggle word wrap

       すべてのノードが最新のリビジョンに更新されていることを確認します。

       $ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       Copy to Clipboard Toggle word wrap

       NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。

       AllNodesAtLatestRevision
       3 nodes are at revision 7 

       1

       Copy to Clipboard Toggle word wrap

       1

       この例では、最新のリビジョン番号は 7 です。

       出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。

    3. Kubernetes スケジューラーの新規ロールアウトを強制的に実行します。

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

       Copy to Clipboard Toggle word wrap

       すべてのノードが最新のリビジョンに更新されていることを確認します。

       $ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       Copy to Clipboard Toggle word wrap

       NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。

       AllNodesAtLatestRevision
       3 nodes are at revision 7 

       1

       Copy to Clipboard Toggle word wrap

       1

       この例では、最新のリビジョン番号は 7 です。

       出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。

15. すべてのコントロールプレーンホストが起動しており、クラスターに参加していることを確認します。

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

    $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

    Copy to Clipboard Toggle word wrap

    出力例

    etcd-ip-10-0-143-125.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-154-194.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-173-171.ec2.internal                2/2     Running     0          9h

    Copy to Clipboard Toggle word wrap