月曜朝の障害デスクに座り、コーヒーを片手に、いつものように kubectl get nodes を実行したとします。しかし、正常なノードリストが表示される代わりに、ターミナルには次のような TLS エラーが返されます。
Unable to connect to the server: x509: certificate has expired or is not yet valid
これは通常、クラスターを最初に初期化してからちょうど365日後に発生します。内部証明書が有効期限に達したため、API サーバーがすべてのリクエストを拒否するようになります。アプリケーション自体は動作し続けているかもしれませんが、管理操作は完全に凍結されてしまいます。
なぜ Kubernetes の証明書には期限があるのかkubeadm を使用してクラスターをセットアップすると、/etc/kubernetes/pki 内に一連の証明書が生成されます。デフォルトでは、これらは1年間のみ有効です。最近の Kubernetes バージョンでは一部の Kubelet 証明書を自動的にローテーションしようとしますが、クラスターのアップグレードを長期間行っていない場合、コアとなるコントロールプレーンの証明書は手動での更新が必要になることがよくあります。
API サーバーは安全な通信のためにこれらの証明書に依存しています。1年の期限が切れると、TLS ハンドシェイクが失敗し、kubectl はクラスターと通信する権限を失います。
ステップ 1：証明書の期限を確認するまず、具体的にどの証明書が期限切れになったかを確認しましょう。マスター（コントロールプレーン）ノードにログインし、ステータスをチェックします。
sudo kubeadm certs check-expiration
注意：古いバージョン（v1.20 未満）を使用している場合は、代わりに sudo kubeadm alpha certs check-expiration を使用してください。
RESIDUAL TIME（残り時間）列を確認してください。admin.conf や apiserver などの項目で 0d やマイナスの値が表示されている場合、それが原因です。たとえ残り2、3日であっても、すべてが壊れる前に今すぐ更新することをお勧めします。
ステップ 2：すべての証明書を一括更新する最も効率的な修正方法は、クラスターで管理されているすべての証明書を更新することです。マスターノードで以下のコマンドを実行します。
sudo kubeadm certs renew all
このコマンドは、/etc/kubernetes/pki 内の .crt および .key ファイルを更新します。また、.conf ファイル内に埋め込まれた証明書も更新されます。ただし、これだけではクラスターはまだ復旧しません。ローカルのユーザープロファイルには、まだ古い認証情報が残っているからです。
ステップ 3：Kubeconfig を更新する~/.kube/config ファイルは、期限切れの古い証明書のコピーです。これを更新しないと、kubectl は期限切れの認証情報を使い続けようとします。更新によって生成された新しい設定ファイルで、ローカルの設定を上書きします。
# マスターノードの root または現在のユーザー用
sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
リモートのノート PC からクラスターを管理している場合は、新しく生成された /etc/kubernetes/admin.conf の内容をローカルマシンの設定ファイルにコピーしてください。この手順を怠ると、サーバー側が正常になっても x509 エラーが表示され続けます。
ステップ 4：コントロールプレーンを強制的に再起動するAPI サーバーと Controller Manager は、メモリ上でまだ古い証明書を使用して動作しています。これらを再起動して新しいファイルを読み込ませる必要があります。これらはスタティック Pod であるため、最も確実な方法はマニフェストファイルをデプロイ用フォルダーから一旦移動させ、再び戻すことです。
# Pod を停止するためにマニフェストを一時フォルダーに移動
sudo mv /etc/kubernetes/manifests/*.yaml /tmp/
# Kubelet がプロセスを終了するまで約30秒待機
sleep 30
# 再起動をトリガーするためにマニフェストを元の場所に戻す
sudo mv /tmp/*.yaml /etc/kubernetes/manifests/
API サーバーが安定するまで1分ほど待ちます。watch docker ps または watch crictl ps を実行して、コンテナが復旧する様子を確認できます。
修正の確認サービスがオンラインに戻ったら、接続をテストします。
kubectl get nodes
ノードが Ready 状態で表示されれば、危機は去りました。最後にもう一度 sudo kubeadm certs check-expiration を実行してください。すべての証明書の残り時間が 364 日になっているはずです。