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

手順

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 分の時間がかかる可能性があります。