このページでは、Google Distributed Cloud Virtual for Bare Metal の Kubernetes コントローラ マネージャー（kube-controller-manager）の問題を解決する方法について説明します。
リーダー選出の失敗
このエラーは、kube-controller-manager（KCM）が予期せず再起動したときに、リージョン クラスタまたはレプリケートされたコントロール プレーンで発生する可能性があります。この再起動には、アプリが自動的に終了する場合や、kubelet によって再起動される場合もあります。KCM ログには、leaderelection lost のメッセージが含まれている場合があります。
このシナリオは、リーダーが KCM ヘルスチェックの一部として積極的にリードしているかどうかを確認する場合に発生します。
リーダーがリーダーとして機能していないか、リースのチェックに失敗した場合、ヘルスチェックは異常であると報告され、リーダーが再起動されます。
リーダー選出ステータスは、coordination.k8s.io グループの Lease リソースを取得することで取得できます。
すべてのリースを表示するには、次の
kubectlコマンドを実行します。kubectl -n kube-system get leaselease/kube-controller-managerなどの特定のリースのステータスを確認するには、次のkubectl describeコマンドを使用します。kubectl -n kube-system describe lease/kube-controller-managerEventsセクションで、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 leadernameでグループ化された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 インスタンスがリーダーシップを失います。
- コントロール プレーンがレプリケートされると、新しいリーダーはダウンタイムなしでスムーズに引き継ぐ必要があります。ご対応は必要ありません。マルチクラウド クラスタまたはリージョン クラスタのコントロール プレーンは常にレプリケートされます。レプリケートされたコントロール プレーンのリーダー選出を無効にしようとしないでください。リーダー選出は、ダウンタイムなしで再度有効にすることはできません。