排查 Kubernetes 控制器管理器问题

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

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

主节点选举失败

kube-controller-manager (KCM) 意外重启时,可能会在区域级集群或复制的控制平面中观察到此错误。此重启可能涉及自行退出或由 kubelet 重启。KCM 日志可能包含 leaderelection lost 消息。

当主节点检查在 KCM 健康检查中仍处于主动领导状态时,可能会发生这种情况。

如果主节点不再处于领导状态或租用检查失败,则健康检查会报告健康状况不佳,并且主节点会重启。

可以通过获取 coordination.k8s.io 组的 Lease 资源来检索主节点选举状态:

  1. 如需查看所有租约,请运行以下 kubectl 命令:

    kubectl -n kube-system get lease
    
  2. 如需检查给定租约的状态(例如 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-managercontainer_name 过滤的 kubernetes.io/anthos/container/uptimekubernetes.io/anthos/container/restart_count 指标来确认失败。

如果您遇到主节点选举过程重复运行或失败的问题,请查看以下补救注意事项:

  • 如果 KCM 每隔几分钟或更短时间重启一次,请检查 KCM 日志中是否有向 API 服务器发出的失败请求。失败的请求表明组件之间的连接问题或服务的某个部分过载。
  • 如果控制器管理器太长时间无法与 API 服务器通信,则即使连接稍后恢复,续订也会失败并且 KCM 实例会失去其领导资格。
  • 如果复制了控制平面,则新的主节点应该会在不停机的情况下顺利接管。您无需采取任何操作。多云或区域级集群的控制平面始终会复制。请勿尝试为复制的控制平面停用主节点选举。您无法在不停机的情况下重新启用主节点选举。

后续步骤

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