5.3. 障害復旧

手順

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

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

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

   重要

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

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

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

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

   注記

   リカバリーホストで静的 Pod を停止する必要はありません。

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

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

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

   3. 以下を使用して、etcd Pod が停止していることを確認します。

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

      このコマンドの出力が空でない場合は、数分待ってからもう一度確認してください。

   4. 以下を実行して、既存の kube-apiserver ファイルを kubelet マニフェストディレクトリーから移動します。

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

   5. 以下を実行して、kube-apiserver コンテナーが停止していることを確認します。

      $ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"

      このコマンドの出力が空でない場合は、数分待ってからもう一度確認してください。

   6. 以下を使用して、既存の kube-controller-manager ファイルを kubelet マニフェストディレクトリーから移動します。

      $ sudo mv -v /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /tmp

   7. 以下を実行して、kube-controller-manager コンテナーが停止していることを確認します。

      $ sudo crictl ps | grep kube-controller-manager | egrep -v "operator|guard"

      このコマンドの出力が空でない場合は、数分待ってからもう一度確認してください。

   8. 以下を使用して、既存の kube-scheduler ファイルを kubelet マニフェストディレクトリーから移動します。

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

   9. 以下を使用して、kube-scheduler コンテナーが停止していることを確認します。

      $ sudo crictl ps | grep kube-scheduler | egrep -v "operator|guard"

      このコマンドの出力が空でない場合は、数分待ってからもう一度確認してください。

   10. 次の例を使用して、etcd データディレクトリーを別の場所に移動します。

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

   11. /etc/kubernetes/manifests/keepalived.yaml ファイルが存在し、ノードが削除された場合は、次の手順に従います。

       1. /etc/kubernetes/manifests/keepalived.yaml ファイルを kubelet マニフェストディレクトリーから移動します。

          $ sudo mv -v /etc/kubernetes/manifests/keepalived.yaml /tmp

       2. keepalived デーモンによって管理されているコンテナーが停止していることを確認します。

          $ sudo crictl ps --name keepalived

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

       3. コントロールプレーンに仮想 IP (VIP) が割り当てられているかどうかを確認します。

          $ ip -o address | egrep '<api_vip>|<ingress_vip>'

       4. 報告された仮想 IP ごとに、次のコマンドを実行して仮想 IP を削除します。

          $ sudo ip address del <reported_vip> dev <reported_vip_device>

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

6. keepalived デーモンが使用されている場合は、リカバリーコントロールプレーンノードが仮想 IP を所有していることを確認します。

   $ ip -o address | grep <api_vip>

   仮想 IP のアドレスが存在する場合、出力内で強調表示されます。仮想 IP が設定されていないか、正しく設定されていない場合、このコマンドは空の文字列を返します。

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

   ヒント

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

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

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

   スクリプトの出力例

   ...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

   cluster-restore.sh スクリプトは、etcd、kube-apiserver、kube-controller-manager、および kube-scheduler Pod が停止され、復元プロセスの最後に開始されたことを示す必要があります。

   注記

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

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

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

      $ oc get nodes -w

      出力例

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

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

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

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

      サンプル 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

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

    1. 復元ホストから以下を実行します。

       $ sudo systemctl restart kubelet.service

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

11. 保留中の証明書署名要求 (CSR) を承認します。

    注記

    単一ノードクラスターや 3 つのスケジュール可能なコントロールプレーンノードで構成されるクラスターなど、ワーカーノードを持たないクラスターには、承認する保留中の CSR はありません。この手順にリストされているすべてのコマンドをスキップできます。

    1. 次のコマンドを実行して、現在の CSR のリストを取得します。

       $ oc get csr

       出力例

       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
       ...

       1 2

       kubelet 提供エンドポイントのノードによって要求される、保留中の kubelet 提供 CSR。

       3 4

       node-bootstrapper ノードのブートストラップ認証情報を使用して要求される、保留中の kubelet クライアント CSR。

    2. 次のコマンドを実行して、CSR の詳細と CSR が有効であることを確認します。

       $ oc describe csr <csr_name> 1

       1

       <csr_name> は、現行の CSR のリストからの CSR の名前です。

    3. 以下を実行して、有効な node-bootstrapper CSR をそれぞれ承認します。

       $ oc adm certificate approve <csr_name>

    4. user-provisioned installation の場合、以下を実行して各 kubelet service CSR を承認します。

       $ oc adm certificate approve <csr_name>

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

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

       $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

       出力例

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

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

       $ oc -n openshift-etcd get pods -l k8s-app=etcd

       出力例

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

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

13. OVNKubernetes ネットワークプラグインを使用している場合は、ovnkube-controlplane Pod を再起動する必要があります。

    1. 以下を実行して、すべての ovnkube-controlplane Pod を削除します。

       $ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-control-plane

    2. 次のコマンドを使用して、すべての ovnkube-controlplane Pod が再デプロイされたことを確認します。

       $ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-control-plane

14. OVN-Kubernetes ネットワークプラグインを使用している場合は、すべてのノードで Open Virtual Network (OVN) Kubernetes Pod を 1 つずつ再起動します。次の手順を使用して、各ノードで OVN-Kubernetes Pod を再起動します。

    重要

    次の順序で OVN-Kubernetes Pod を再起動します。

    1. リカバリーコントロールプレーンホスト
    2. 他のコントロールプレーンホスト (利用可能な場合)
    3. 他のノード
    注記

    検証および変更用の受付 Webhook は Pod を拒否することができます。failurePolicy を Fail に設定して追加の Webhook を追加すると、Pod が拒否され、復元プロセスが失敗する可能性があります。これは、クラスターの状態の復元中に Webhook を保存および削除することで回避できます。クラスターの状態が正常に復元された後に、Webhook を再度有効にできます。

    または、クラスターの状態の復元中に failurePolicy を一時的に Ignore に設定できます。クラスターの状態が正常に復元された後に、failurePolicy を Fail にすることができます。

    1. ノースバウンドデータベース (nbdb) とサウスバウンドデータベース (sbdb) を削除します。Secure Shell (SSH) を使用して復元ホストと残りのコントロールプレーンノードにアクセスし、以下を実行します。

       $ sudo rm -f /var/lib/ovn-ic/etc/*.db

    2. OpenVSwitch サービスを再起動します。Secure Shell (SSH) を使用してノードにアクセスし、次のコマンドを実行します。

       $ sudo systemctl restart ovs-vswitchd ovsdb-server

    3. 次のコマンドを実行して、ノード上の ovnkube-node Pod を削除します。<node> は、再起動するノードの名前に置き換えます。

       $ oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>

    4. 以下を使用して、ovnkube-node Pod が再度実行されていることを確認します。

       $ oc -n openshift-ovn-kubernetes get pod -l app=ovnkube-node --field-selector=spec.nodeName==<node>

       注記

       Pod が再起動するまでに数分かかる場合があります。

15. 他の非復旧のコントロールプレーンマシンを 1 つずつ削除して再作成します。マシンが再作成された後、新しいリビジョンが強制され、etcd が自動的にスケールアップします。

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

      警告

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

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

      警告

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

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

      1. 失われたコントロールプレーンホストのいずれかのマシンを取得します。

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

         $ oc get machines -n openshift-machine-api -o wide

         出力例:

         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

         1

         これは、失われたコントロールプレーンホストのコントロールプレーンマシンです (ip-10-0-131-183.ec2.internal)。

      2. 以下を実行して、失われたコントロールプレーンホストのマシンを削除します。

         $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1

         1

         失われたコントロールプレーンホストのコントロールプレーンマシンの名前を指定します。

         失われたコントロールプレーンホストのマシンを削除すると、新しいマシンが自動的にプロビジョニングされます。

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

         $ oc get machines -n openshift-machine-api -o wide

         出力例:

         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

         1

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

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

      4. リカバリーホストではない喪失したコントロールプレーンホストで、これらのステップを繰り返します。

16. 次のように入力して、クォーラムガードをオフにします。

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

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

17. リカバリーホスト内の別のターミナルウィンドウで、以下を実行してリカバリー kubeconfig ファイルをエクスポートします。

    $ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig

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

    リカバリー kubeconfig ファイルをエクスポートしたのと同じターミナルウィンドウで、以下を実行します。

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

    1

    forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。

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

19. 次のように入力して、クォーラムガードをオンに戻します。

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

20. 以下を実行すると、unsupportedConfigOverrides セクションがオブジェクトから削除されたことを確認できます。

    $ oc get etcd/cluster -oyaml

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

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

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

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

    AllNodesAtLatestRevision
    3 nodes are at revision 7 1

    1

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

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

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

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

    1. kube-apiserver の新規ロールアウトを強制します。

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

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

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

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

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       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

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

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

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

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

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

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

    3. 以下を実行して、kube-scheduler の新規ロールアウトを強制します。

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

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

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

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

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

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

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

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

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

    $ oc -n openshift-etcd get pods -l k8s-app=etcd

    出力例

    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

手順

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

   $ oc get csr

   出力例

   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
   ...

   1

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

   2

   保留中の node-bootstrapper CSR。

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

   $ oc describe csr <csr_name> 1

   1

   <csr_name> は、現行の CSR のリストからの CSR の名前です。

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

   $ oc adm certificate approve <csr_name>

4. ユーザーによってプロビジョニングされるインストールの場合は、それぞれの有効な kubelet 提供の CSR を承認します。

   $ oc adm certificate approve <csr_name>