EKS集群通过Helm部署的Jenkins偶发Job运行过慢问题咨询

• 检查CPU限流相关配置
  当前Pipeline配置里仅给ruby、mysql容器配置了CPU requests，未配置CPU limits，首先排查2点：
  1. Pod所在命名空间是否配置了默认LimitRange，自动给所有未声明limits的容器注入了较低的CPU上限，导致进程被CFS限流无法用满CPU，异常时执行kubectl describe pod <异常Pod名>查看是否有CPUThrottlingHigh相关事件
  2. 确认Pod的QoS等级：由于redis、docker、docker-daemon容器未配置任何资源请求/限制，整个Pod的QoS为Burstable，节点CPU资源紧张时会优先对Burstable等级的Pod进行CPU限流，可将所有容器都配置同值的CPU requests和limits，将Pod QoS提升为Guaranteed排除该问题
• 排查DinD存储性能瓶颈
  使用的docker-in-docker(dind)容器默认会读写节点本地磁盘，若EKS节点挂载的是GP2类型EBS卷，GP2的IOPS依赖Burst余额，余额耗尽时存储性能会骤降，进程等待IO时会出现CPU使用率极低的现象：
  1. 监控EBS卷的BurstBalance指标，确认异常时是否出现余额下跌到0的情况
  2. 可将EBS卷更换为GP3类型，或给dind容器配置专用的emptyDir/持久化卷排除存储问题
• 排查Jenkins Master与Agent的通信问题
  任务在setup阶段就出现卡顿，大概率和Jenkins Master与Agent的通信异常有关：
  1. 检查Jenkins Master所在节点/容器的负载、网络丢包情况，确认是否存在偶发的 Master 响应超时
  2. 升级Jenkins Kubernetes插件到最新稳定版，旧版本插件存在偶发Agent连接中断、心跳超时后自动重试的问题，会导致任务停滞
• 排查节点隐形故障
  配置的Pod强制反亲和可能会把Pod调度到存在隐形问题的节点：
  1. 收集异常Pod所在节点的dmesg日志，查看是否存在内核报错、文件描述符耗尽、TCP连接溢出等问题
  2. 排查节点上运行的DaemonSet进程，是否存在偶发的资源占用过高，抢占了Job Pod的资源
• 排查镜像拉取延迟问题
  确认使用的自定义Ruby镜像、依赖的公共镜像是否存放在跨AZ的镜像仓库，或节点上没有对应镜像缓存，偶发出现镜像拉取耗时过长的情况，可在节点上预缓存常用镜像，或将镜像同步到同区域的ECR仓库降低拉取延迟

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