Kubernetes/Terraform部署多E2E测试栈性能劣化排查求助

1. K8s调度器性能瓶颈 #

• 30套栈总计1500个Pod，你的集群总Pod容量是6110+3330=1650，已经接近满负载。调度器在处理大规模并发Pod调度时，很容易因为以下原因变慢：
  • 如果你的Terraform模块给栈内Pod设置了同栈亲和/跨栈反亲和规则，调度器需要反复计算候选节点，匹配规则的开销会指数级上升，导致Pod长时间卡在Pending状态。
  • 默认kube-scheduler的QPS和并发请求限制没调优，大规模调度时会触发限流，直接拖慢调度速度。

2. 底层资源争抢（非CPU/内存） #

• 存储IO饱和：单栈包含数据库、内存存储等组件，30套栈会同时创建上百个PVC并初始化存储。即使是SSD，并发执行数据库初始化脚本、存储快照加载这类高IO操作时，也会导致IO队列阻塞，Pod初始化步骤大幅延迟。
• 网络带宽/规则更新瓶颈：
  • 30套栈同时拉取容器镜像，若镜像仓库不在集群内部，节点带宽会被占满，镜像拉取超时或变慢。
  • Kube-proxy用iptables模式时，1500个Pod会生成上万条iptables规则，规则更新会占用大量CPU，导致Pod无法快速进入Ready状态。

3. Terraform与K8s API的交互限制 #

• 用Terraform批量部署时，默认并发请求数有限，若没配置provider "kubernetes"的max_concurrent_requests参数，Terraform会串行或低并行度调用K8s API，导致资源创建请求排队，实际启动的并行度远低于你预期的“所有栈同时启动”。
• K8s API Server本身的QPS/限流设置如果偏低，大规模请求会被拒绝或延迟，进一步拖慢资源创建。

4. 应用内部的依赖阻塞 #

• 你假设单栈启动时间是5分钟，但实际栈内Pod可能存在隐性依赖：比如后端服务在数据库未完全就绪时就启动，反复重试连接，不仅拉长自身启动时间，还会加剧数据库连接池、DNS查询的资源争抢。30套栈同时触发这种重试，会让整体启动时间呈非线性增长。
• 健康检查配置不合理也会拖慢进度：比如readinessProbe超时时间太短，Pod明明在正常初始化却被判定为未就绪，或者检查频率太高消耗额外资源。

5. Master节点的隐性负载 #

• 你只注意到磁盘偶尔满，但Master节点的CPU/内存可能在大规模调度时被打满：Kube-apiserver要处理上千个资源创建请求，etcd要同步大量状态变更，这些操作都会消耗大量CPU。如果Master节点资源不足，会导致API请求延迟，整个流程卡住。
• 若etcd用的是机械磁盘或单节点部署，大规模写操作会导致etcd性能瓶颈，这是很多大规模集群启动慢的隐性原因。

具体排查动作 #

• 用kubectl get pods -A -w跟踪Pod状态，看是卡在Pending（调度问题）、ContainerCreating（镜像/存储问题）还是Running但NotReady（应用初始化问题）。
• 查看Master组件日志：kubectl logs -n kube-system kube-scheduler-<节点名>、kubectl logs -n kube-system kube-apiserver-<节点名>，找调度超时、API限流的报错。
• 用Prometheus监控节点指标：查node_disk_io_now看IO是否打满，node_network_receive_bytes_total看带宽是否饱和，kube_pod_status_phase统计各状态Pod的数量变化。
• 调优Terraform并发：在K8s provider中设置max_concurrent_requests = 50（根据集群API能力调整），或者用Terraform工作区并行部署不同栈。
• 简化调度规则：如果没有强需求，去掉同栈Pod的节点亲和规则，减少调度器计算开销；调优kube-scheduler的--kube-api-qps和--kube-api-burst参数，提升调度器API请求能力。

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