先确认是否真慢：用curl测各阶段耗时，DNS高查DNS，TCP高查TLS，首字节与总耗时高才指向API Server自身；再查etcd延迟、磁盘IO、连接状态；接着看API Server参数、goroutine数及高开销特性；最后排查Controller Manager/Scheduler背压。
API Server 响应慢，先确认是不是它真慢了
别急着翻 kube-apiserver 日志或改参数。很多“API Server 慢”的报错，其实是客户端连不上、DNS 解析失败、或者网络中间件（如负载均衡器、Ingress Controller）卡住了请求。先用 curl 测真实耗时：
curl -k -s -w "\nDNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nFirstByte: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://<code>your-api-server-endpoint</code>:6443/healthz
如果 time_namelookup > 1s，查 DNS；如果 time_connect 高但 time_starttransfer 接近 0，说明 TLS 握手或证书验证有问题；如果 time_starttransfer 和 time_total 都高（比如 >2s），才真正指向 API Server 本身处理慢。
查 etcd 连接是否卡死或延迟高
API Server 是个“中转站”，它自己不存状态，所有读写都压到 etcd。一旦 etcd 延迟升高或连接数打满，API Server 就会排队阻塞。重点看两件事：
- API Server 日志里有没有大量
etcdserver: request timed out或context deadline exceeded - 执行
etcdctl endpoint health --cluster，确认每个 etcd 成员是否healthy；再用etcdctl endpoint status --write-out=table查各节点的Round-Trip耗时，超过 100ms 就危险 - 检查 etcd 磁盘 IO：用
iostat -x 1看%util是否持续 >90%，await是否 >50ms —— 这类指标比 CPU 更能暴露瓶颈
kube-apiserver 进程自身是否被资源拖垮
即使 etcd 正常，API Server 自身也可能因配置不当或负载突增而响应变慢：
- 检查启动参数：
--max-requests-inflight和--max-mutating-requests-inflight设得太低（比如默认 400/200），在批量操作（如 helm install、kubectl apply -f 大目录）时会直接排队，表现为“卡顿”而非报错 - 观察 goroutine 数量：
curl -s http://localhost:8080/debug/pprof/goroutine?debug=2 | wc -l，如果 >10k，大概率有 Watch 泄漏或 client 不断重连没断开 - 确认是否启用了高开销特性：比如
--audit-log-path写到慢盘、--enable-admission-plugins=PodSecurityPolicy（已废弃但仍有集群在用）、或自定义 webhook 响应超时未设timeoutSeconds
Controller Manager 和 Scheduler 的背压是否反向拖累 API Server
这两个组件持续 Watch 所有资源变更，一旦它们处理不过来，会在 API Server 上堆积大量未消费的 watch event，占用内存和连接，最终让 API Server 变得“迟钝”。典型表现是：
-
kubectl get events -A里出现大量Failed to list或watch closed with unknown error - API Server 的
apiserver_request_total指标中，resource="events"的verb="LIST"请求延迟飙升 - Controller Manager 日志里频繁打印
too old resource version，说明它跟不上事件流，被迫反复 LIST 全量
这时要优先调大 Controller Manager 的 --kube-api-qps 和 --kube-api-burst，并确认其是否因 RBAC 权限不足反复失败重试——权限问题导致的 watch 失败，比性能问题更隐蔽也更常见。
