K8s 1.19.9集群kube-scheduler与kube-controller-manager leader选举失败排查

没错，API Server负载过高确实是引发这类问题的常见原因之一！结合你提供的日志和临时恢复方案，我来梳理下具体的排查思路和解决方案：

一、为什么API Server负载高会导致这个问题？ #

Leader选举的核心逻辑是kube-controller-manager/kube-scheduler通过API Server操作Lease（或旧版本的Endpoints）资源来完成租约续约。一旦API Server负载过高，请求处理排队、响应延迟超过了leader选举的超时阈值（默认续约超时15秒），就会出现日志里的context deadline exceeded错误；而后续的resource name may not be empty通常是超时导致请求返回不完整，组件解析响应时出现的连锁错误。

二、排查步骤 #

1. 确认API Server的负载状态 #

• 查看API Server的资源占用：

  kubectl top pods -n kube-system | grep kube-apiserver
  

  同时在节点上用top/htop观察kube-apiserver进程的CPU、内存使用率，如果CPU持续超过70%，内存接近分配上限，基本可以确认负载过高。
• 检查API Server日志：

  kubectl logs -n kube-system <kube-apiserver-pod-name> --tail=100
  

  重点查找slow request、request timeout或etcd相关的报错（API Server依赖etcd，etcd性能瓶颈也会传导过来）。
• 测试API Server响应速度：

  time kubectl get endpoints kube-controller-manager -n kube-system
  

  多次执行，若平均响应时间超过2-3秒，说明API Server响应确实缓慢。

2. 排查leader选举相关配置与资源 #

• 检查组件的leader选举参数：K8s 1.19默认租约时长15秒、续约间隔5秒、超时15秒。你可以通过以下参数调整：
  • --leader-elect-lease-duration：租约有效期
  • --leader-elect-renew-deadline：续约超时时间
  • --leader-elect-retry-period：重试间隔
• 查看Lease资源状态：

  kubectl get leases -n kube-system
  

  观察kube-controller-manager和kube-scheduler对应的Lease的RenewTime是否频繁更新，HolderIdentity是否频繁切换（频繁切换说明一直在重复选举）。
• 检查网络连通性：在组件所在节点测试到API Server的网络延迟和丢包：

  ping <api-server-ip> -c 10
  curl -v https://<api-server-ip>:<port>/api/v1/namespaces/kube-system/endpoints/kube-controller-manager
  

  网络丢包或延迟过高也会导致续约超时。

三、解决方案 #

1. 临时应急优化（基于你的现有方案） #

• 除指定leader节点外，其他master节点的kube-controller-manager/kube-scheduler添加--leader-elect=false参数，停止选举循环，待集群稳定后再逐个恢复。
• 临时调大leader选举超时参数，给续约更多缓冲时间：
  在leader节点的组件启动参数中添加：

  --leader-elect-lease-duration=30s --leader-elect-renew-deadline=20s --leader-elect-retry-period=5s
  

2. 长期优化（针对API Server负载问题） #

• 扩容API Server：如果是单实例API Server，立即扩容到3个以上；若已多实例，给API Server Pod增加CPU/内存配额（比如CPU请求从1核调至2核，内存从2G调至4G，根据实际负载调整）。
• 优化API Server配置：调整并发处理参数，适当提高--max-requests-inflight（默认400）和--max-mutating-requests-inflight（默认200）的值，但不要过高避免压垮etcd；启用--enable-aggregator-routing优化聚合层请求路由。
• 优化etcd性能：etcd是API Server的核心依赖，确保etcd使用SSD磁盘，检查etcd的CPU/内存占用，必要时扩容etcd集群；启用etcd自动压缩清理旧数据：

  etcdctl compact $(etcdctl endpoint status --write-out="json" | jq -r '.[0].revision')
  etcdctl defrag
  

• 排查异常请求：启用API Server审计日志，排查是否有大量重复或异常的API请求（比如某个Pod高频调用API），或者检查kubectl get apiservices是否有异常聚合API服务消耗资源。

3. 修复resource name may not be empty错误 #

这个错误是续约超时导致响应解析异常的连锁问题，解决API Server超时或网络问题后，该错误会自动消失。如果仍出现，检查组件的kubeconfig配置是否正确，确保能正常访问API Server资源。

内容的提问来源于stack exchange，提问作者janeosaka