本页面介绍了如何解决 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事件。查看谁有领导资格，以及何时发生此事件。以下示例输出显示，当第一个节点手动关停时，第二个节点会立即接管领导资格：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 实例会失去其领导资格。
- 如果复制了控制平面，则新的主节点应该会在不停机的情况下顺利接管。您无需采取任何操作。多云或区域级集群的控制平面始终会复制。请勿尝试为复制的控制平面停用主节点选举。您无法在不停机的情况下重新启用主节点选举。