k8s租约 && containerd status上报

7c45a0e610654d1ca94d247e20ebde61

 从kube-controller-manager 和kube-scheduler 租约看 平面本身正常。从event看 部分node离线了default  10m   

要判断 Kubernetes 控制平面是否曾发生过异常，不能仅看当前状态，而应通过历史事件、组件日志、租约续期记录、节点心跳中断等多维度进行回溯分析。以下是系统性的判断方法：

一、检查控制平面组件的租约（Lease）历史记录

你已查看了 kube-controller-manager 和 kube-scheduler 的 Endpoints，其中包含 control-plane.alpha.kubernetes.io/leader 注解，该注解记录了 Leader 选举和续期信息：

  • acquireTime：首次获得 Leader 的时间。
  • renewTime：最近一次成功续期的时间。
  • leaderTransitions：Leader 切换次数。

异常判断依据：

  • 如果 leaderTransitions 数值异常高（如短时间内多次切换），说明组件曾频繁重启或网络不稳定导致 Leader 丢失。
  • 如果 renewTime 与当前时间间隔远超 leaseDurationSeconds（默认15秒），说明组件曾长时间无法续期，可能发生过宕机或 API Server 不可用。

二、查看控制平面组件的 Pod 事件与日志

控制平面组件通常以静态 Pod 形式运行在 kube-system 命名空间下。可通过以下命令查看其历史状态：

# 查看 kube-apiserver、kube-controller-manager、kube-scheduler 的 Pod 状态
kubectl get pods -n kube-system | grep -E 'apiserver|controller|scheduler'

# 查看某个组件的详细事件（如 kube-controller-manager）
kubectl describe pod <pod-name> -n kube-system

# 查看组件日志（重点关注错误、重启、超时等关键词）
kubectl logs <pod-name> -n kube-system --previous  # 查看上一次崩溃前的日志

异常判断依据：

  • Pod 状态为 CrashLoopBackOff、Error、Evicted 或重启次数（RESTARTS）过高。
  • 日志中出现 etcd connection refused、context deadline exceeded、leader election lost 等关键错误。

三、检查 etcd 集群健康状态

etcd 是控制平面的“记忆中枢”，其稳定性直接影响 API Server 和组件选举。

# 检查 etcd 集群健康（需在 master 节点执行）
ETCDCTL_API=3 etcdctl endpoint health \
  --endpoints=https://<etcd-ip>:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

异常判断依据：

  • 输出中包含 unhealthy 或 connection refused。
  • etcd Pod 重启频繁或资源占用过高（CPU/内存）。

四、分析节点心跳（Node Lease）中断情况

节点通过 kube-node-lease 命名空间下的 Lease 对象向 API Server 发送心跳。如果大量节点同时出现心跳中断，可能是 API Server 或网络层异常。

# 查看 kube-node-lease 命名空间下的 Lease 对象
kubectl get leases -n kube-node-lease

# 检查节点状态变化事件
kubectl get events -n default --field-selector reason=NodeNotReady,NodeReady

异常判断依据：

  • 多个节点的 renewTime 同时停滞或大幅延迟。
  • 事件中出现大规模 NodeNotReady 与 NodeReady 交替震荡（如你截图中所示），这通常不是节点本身问题，而是控制平面无法及时处理心跳。

五、检查 API Server 的审计日志或监控指标

如果集群开启了审计日志或接入了 Prometheus/Grafana 监控系统，可通过以下方式回溯：

  • 审计日志：搜索 403、500、timeout 等 HTTP 状态码，或 impersonate、delete 等敏感操作。
  • 监控指标：
    • apiserver_request_total{code=~"5.."}：API Server 5xx 错误请求数。
    • etcd_disk_wal_fsync_duration_seconds：etcd 磁盘写入延迟。
    • leader_election_master_status：Leader 选举状态变化。

六、结合你当前截图的分析结论

从你提供的截图来看：

  • kube-controller-manager 和 kube-scheduler 的 renewTime 均为 2026-07-27T09:12:xxZ，说明当前它们正在正常工作。
  • 但 kubectl get event -A 显示多个节点（如 spider50, spider59）在 10 分钟内反复出现 NodeNotReady → NodeReady → NodeNotReady 的震荡。

这表明：控制平面组件本身当前是正常的，但可能在 10 分钟前经历过一次短暂的中断或高负载，导致无法及时处理节点心跳，从而引发节点状态震荡。 建议重点排查：

  1. API Server 在该时间段的日志和 resourceVersion 变化。
  2. etcd 是否有短暂的写入延迟或连接中断。
  3. Master 节点的网络或资源（CPU/内存）是否在 10 分钟前出现过瓶颈。

以上方法可组合使用，形成完整的“控制平面异常回溯”诊断链路。如果你能提供 kubectl describe pod 或 etcdctl endpoint health 的输出，我可以帮你进一步定位具体原因。

 

是的，kube-apiserver 也有租约（Lease），但它的工作机制与 kube-controller-manager 和 kube-scheduler 不同，因此你无法通过 kubectl get endpoints 看到它的“Leader 租约”。

为什么 api-master 没有“Endpoints 租约”？

  • Controller/Scheduler：它们是“主备模式”，同一时间只有一个实例在工作（Leader），所以需要通过 Endpoints 的注解来记录谁是 Leader。
  • API Server：它是“多活模式”，所有 API Server 实例同时工作，共同分担流量，不存在“只有一个能干活”的情况，所以不需要 Leader 选举租约。

如何查看 API Server 的租约？

从 Kubernetes v1.26 开始，API Server 会为自己创建一个身份租约，用于标识自己还活着。你可以通过以下命令查看：

kubectl get lease -n kube-system -l apiserver.kubernetes.io/identity=kube-apiserver

或者查看所有 Lease 对象：

kubectl get lease -n kube-system

你会看到类似这样的输出：

NAME                          HOLDER                                     AGE
kube-apiserver-<hash>         kube-apiserver-<hash>                      10d

这个 Lease 的 renewTime 就是 API Server 最近一次“报平安”的时间。如果这个时间很久远，说明该 API Server 实例可能已经宕机或网络中断。

如何判断 API Server 是否异常过？

除了看 Lease，你还可以：

  1. 查看 API Server Pod 的重启次数：

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

    如果 RESTARTS 列数字很大，说明它频繁崩溃过。

  2. 查看 API Server 的日志：

    kubectl logs <apiserver-pod-name> -n kube-system --previous

    重点关注 error、panic、timeout、context deadline exceeded 等关键词。

  3. 检查 Etcd 的健康状态：
    API Server 依赖 Etcd，如果 Etcd 不稳定，API Server 也会表现异常。

    etcdctl endpoint health --endpoints=<etcd-endpoint>

  4. 监控 API Server 的请求延迟和错误率：
    通过 Prometheus + Grafana 监控 apiserver_request_duration_seconds 和 apiserver_request_total{code=~"5.."}，可以直观看到 API Server 是否经历过性能瓶颈或服务中断。

总结

  • API Server 有租约，但不是 Leader 租约，而是身份租约，用于多实例共存时的健康标识。
  • 判断其历史异常，应结合 Lease 续期时间、Pod 重启次数、日志错误、以及 Etcd 状态综合判断。
  • 你之前看到的节点 NotReady 事件，如果 API Server 本身稳定，那问题更可能出在 Kubelet、容器运行时或节点资源上。

既然排除了控制平面的问题，需要我帮你列一份排查节点 NodeNotReady 的具体命令清单吗？

 

分析：

查了一下containerd status上报和pods status上报是两个循环，containerd流程正常，pods都阻塞了。syncPod()
  ↓
computePodStatus()
  ↓
generatePodStatus()
  ↓
statusManager.SetPodStatus()
  ↓
statusManager.sync()
  ↓
PatchPodStatus → API Server       kubelet 内 statusManager 自己死了，还没到PatchPodStatus → API Server

 

遗留问题：

不清楚是api慢拖死了，还是kubelet因为服务器过载了。

嗯。我找了几台kubelet看了pprof没看到podstatus问题 应该是kubelet自己出问题了

posted on 2026-08-24 23:46  小镇-做题家  阅读(3)  评论(0)    收藏  举报

导航