Kubernetes API Server间歇性连接异常排查与稳定性优化咨询

一、判断是否存在待处理连接积压 #

可以通过以下方式确认：

• 查看API Server请求指标：访问API Server的metrics端点（https://10.129.86.88:6443/metrics），查看apiserver_current_inflight_requests指标值，对比kube-apiserver启动参数--max-requests-inflight（默认400）和--max-mutating-requests-inflight（默认200）。若指标接近或超过上限，说明存在请求积压。
• 检查API Server日志：执行kubectl logs -n kube-system <kube-apiserver-pod-name>，如果发现request rejected due to exceeding inflight request limit类日志，证明请求数已超出处理上限。
• 查看端口连接状态：在API Server节点上执行ss -tulnp | grep :443，统计ESTABLISHED（活跃连接）和TIME_WAIT（待回收连接）数量。ESTABLISHED过多说明请求处理缓慢，TIME_WAIT堆积则可能是连接回收不及时。
• 监控资源使用率：执行kubectl top pod -n kube-system | grep kube-apiserver，若CPU、内存使用率持续超70%，说明资源不足导致处理能力下降，间接引发连接积压。

二、稳定Kube API Server运行的优化措施 #

1. 调整请求限制参数 #

若确认请求数接近上限，修改kube-apiserver启动参数：

• 调大--max-requests-inflight至600-800（根据集群规模调整）
• 对应调大--max-mutating-requests-inflight至300-400
  注意：参数值不宜过大，避免API Server过载崩溃。

2. 优化监控Pod请求逻辑 #

针对定期通信的监控Pod：

• 降低请求频率：比如从10秒一次调整为30秒一次，减少请求总量
• 缩小请求范围：避免全量资源查询，只请求目标命名空间、指定资源类型和所需字段（例如kubectl get pods -n <监控命名空间> -o custom-columns=NAME:.metadata.name）
• 改用增量请求：利用资源的resourceVersion字段，仅拉取变更后的资源，减少重复请求

3. 扩容API Server资源 #

• 提升kube-apiserver Pod的资源配额：修改Static Pod或Deployment的资源请求/限制，例如将CPU请求从1核提至2核，内存从2G提至4G
• 保证实例数量：集群至少部署3个kube-apiserver实例，分散请求压力，避免单点故障

4. 优化缓存与etcd性能 #

• 确认API Server启用etcd缓存：检查启动参数--enable-etcd-cache是否开启（默认开启），缓存可减少重复请求直达etcd的次数
• 检查etcd状态：执行etcdctl endpoint health确认集群健康，监控etcd的磁盘IO、CPU使用率，确保使用SSD磁盘，必要时扩容etcd节点或增加资源配额

5. 清理集群无用资源 #

• 删除废弃的命名空间、Pod、ConfigMap、Secret等资源，减少API Server需要维护的资源总量，降低处理压力

6. 调整超时配置 #

• 修改API Server的--request-timeout参数（默认60秒），根据业务需求适当调大，避免因请求处理超时导致连接重置
• 同步调整监控Pod的客户端超时配置，与API Server保持一致，减少客户端主动断开连接的情况

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