Kubernetes API Server 503:控制面故障排查路径

从负载均衡、API Server 健康检查、etcd 延迟和聚合 API 逐层定位控制面 503。

文章目录 · 4 节

kubectl 间歇性返回 503 时,先确认错误由负载均衡器、API Server 还是聚合 API 返回。不同来源的处理路径完全不同。

判断故障边界

kubectl get --raw='/readyz?verbose'
kubectl get --raw='/livez?verbose'
kubectl get apiservice | grep -v True

readyz 中 etcd 检查失败应立即转向 etcd;聚合 API 不可用通常只影响 metrics 或扩展 API,不一定代表核心 API 故障。

查看控制面饱和度

检查 API 请求 P99、inflight 数量、限流计数、进程 CPU 和内存。审计日志写入阻塞、异常 List 请求和控制器重试风暴都可能拖慢 API Server。

kubectl top pod -n kube-system
kubectl get --raw='/metrics' | grep apiserver_current_inflight_requests

检查负载均衡

逐个访问控制面节点健康端点,确认是否只有一个后端异常。健康检查路径、证书 SNI 和连接超时配置错误,也会制造 503。

止血原则

暂停高频自动化和非必要控制器,限制异常客户端请求,再处理 etcd 或节点资源问题。不要在控制面过载时同时重启所有 API Server。