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