版本 1.15。此版本已不再受支持。如需了解详情，请参阅版本支持政策。

排查 Kubernetes 控制器管理器问题

本页面介绍如何解决 Google Distributed Cloud Virtual for VMware 的 Kubernetes 控制器管理器 (kube-controller-manager) 存在的问题。

如果您需要其他帮助，请与 Cloud Customer Care 联系。

主节点选举失败

当 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 实例会失去其领导资格。
如果复制了控制平面，则新的主节点应该会在不停机的情况下顺利接管。您无需采取任何操作。多云或区域级集群的控制平面始终会复制。请勿尝试为复制的控制平面停用主节点选举。您无法在不停机的情况下重新启用主节点选举。

后续步骤

如果您需要其他帮助，请与 Cloud Customer Care 联系。