このページでは、Google Distributed Cloud 用の Kubernetes コントローラ マネージャー(kube-controller-manager
)の問題を解決する方法について説明します。
リーダー選出の失敗
このエラーは、kube-controller-manager
(KCM)が予期せず再起動したときに、リージョン クラスタまたはレプリケートされたコントロール プレーンで発生する可能性があります。この再起動は、自身が終了する場合と、kubelet
によって再起動される場合があります。KCM ログに leaderelection lost
メッセージが含まれることがあります。
このシナリオは、リーダーが KCM ヘルスチェックの一環として、まだアクティブにリードしているかどうかを確認するときに発生する可能性があります。
リーダーがリーダーとして機能していないか、リースのチェックに失敗した場合、ヘルスチェックは異常であると報告され、リーダーが再起動されます。
リーダー選出のステータスは、coordination.k8s.io
グループの Lease
リソースを取得することで取得できます。
すべてのリースを表示するには、次の
kubectl
コマンドを実行します。kubectl -n kube-system get lease
特定のリースのステータス(
lease/kube-controller-manager
など)を確認するには、次のkubectl describe
コマンドを使用します。kubectl -n kube-system describe lease/kube-controller-manager
[
Events
] セクションで、LeaderElection
イベントがないか確認します。誰がリーダーシップをとるか、およびそのタイミングを確認してください。次の出力例は、最初のノードが手動でシャットダウンされたときに、2 番目のノードがリーダーシップを即座に引き継ぐことを示しています。Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal LeaderElection 26m kube-controller-manager control-plane_056a86ec-84c5-48b8-b58d-86f3fde2ecdd became leader Normal LeaderElection 5m20s kube-controller-manager control-plane2_b0475d49-7010-4f03-8a9d-34f82ed60cd4 became leader
name
でグループ化されたkubernetes.io/anthos/leader_election_master_status
指標を使用して、リーダーシップの喪失と獲得のプロセスを監視することもできます。
リーダー選出プロセスは、現在のリーダーで障害が発生した場合にのみ行われます。kube-controller-manager
の container_name
でフィルタされた kubernetes.io/anthos/container/uptime
と kubernetes.io/anthos/container/restart_count
の指標を確認することで、エラーを確認できます。
リーダー選出プロセスが繰り返し実行されるか失敗する問題が発生した場合は、次の改善策を検討してください。
- KCM が数分程度の時間ごとに再起動する場合は、KCM ログで API サーバーに対する失敗したリクエストを確認します。リクエストの失敗は、コンポーネントまたはサービスの一部間の接続の問題が過負荷であることを示します。
- コントローラ マネージャーが API サーバーとの通信に失敗すると、更新に失敗し、後で接続が復元されても KCM インスタンスはリーダーシップを失います。
- コントロール プレーンがレプリケートされると、新しいリーダーはダウンタイムなしでスムーズに引き継ぐ必要があります。必要な対応は特にありません。マルチクラウドまたはリージョン クラスタのコントロール プレーンは常に複製されます。レプリケートされたコントロール プレーンのリーダー選出を無効にしようとしないでください。ダウンタイムなしでリーダー選出を再度有効にすることはできません。