本地Jenkins Controller搭配EKS Agent作业过慢问题排查

首先明确：跨IDC部署场景下，Controller与Agent之间的高RTT导致的通信延迟累加（而非单纯通信流量过大）是这类问题的最高发诱因，即便任务完全不访问外部资源、纯本地计算也会受到明显影响。

具体诱因可以分为几类：

• Controller-Agent通信开销被放大：Jenkins Agent与Controller默认通过Remoting协议通信，任务执行过程中会产生海量高频小包交互，包括单条命令的执行状态同步、控制台日志逐行回传、Pipeline每个step的状态确认、工作区文件元数据校验、插件下发的探针指令等。原本地同机/同机房部署时两端RTT不到1ms，这部分开销几乎可以忽略；但本地IDC到AWS EKS的链路如果走公网或未优化的专线，RTT通常在20_{100ms区间，毫秒级的延迟逐步骤累加，很容易把总耗时拉到原来的2}3倍，步骤拆分越细的Pipeline受影响越明显。
• EKS侧隐性资源限制：仅看Pod声明的4核8G配置无法排除资源问题，几个高频踩坑点：
  • 使用了T系列等突发性能实例：这类实例的基准CPU算力仅为标称值的10%~30%，CPU积分耗尽后会被硬限流，看似分配了4核，实际可用算力可能不足1核
  • K8s资源配置不合理：如果Pod的CPU requests与limits数值不一致，Pod属于Burstable QoS等级，即使节点有空闲CPU也可能被触发节流
  • 存储类型选型错误：如果Agent工作目录挂载的是EFS等分布式网络存储，而非节点本地盘，构建过程中产生的大量临时文件、测试缓存的随机读写IO延迟会比本地物理机高5~10倍，IO密集型测试任务受影响尤其明显
  • 节点资源抢占：如果EKS节点上混部了其他高负载业务Pod，Agent可使用的CPU、内存、IO资源会被抢占，实际可用资源远低于声明值
• 链路额外开销：如果跨网链路两端MTU配置不匹配，会导致数据包分片重传，即使带宽充足也会产生高延迟；如果企业出口防火墙对Jenkins通信流量开启了深度包检测、内容审计，每个小包都要经过拆包校验，也会为单次请求额外增加几十毫秒延迟。
• 插件带来的冗余开销：代码审计、安全扫描、合规校验类插件通常会在每个构建步骤注入额外逻辑，需要多次和Controller交互同步数据，跨网场景下这部分开销会被成倍放大。

按以下顺序排查，可快速锁定根因：

• 对照测试排除变量：在EKS集群同VPC内部署一个临时测试用Jenkins Controller，用相同的Agent镜像、相同资源配置跑同一个纯本地测试任务。如果该场景下耗时恢复到原本地Agent的水平，问题100%出在本地IDC到EKS的跨网链路上；如果耗时仍然翻倍，问题出在EKS侧的计算、存储配置上。
• 网络基线测试：在运行中的EKS Agent Pod内直接ping本地Controller的JNLP服务端口，查看RTT平均值、丢包率；再用64字节小包压测端口转发性能，和本地机房内的测试结果做对比。如果RTT超过20ms且无明显丢包，基本可以判定是RTT过高导致的步骤延迟累加。
• 资源瓶颈排查：
  • 进入Agent Pod查看CPU节流计数：cgroup v1环境执行cat /sys/fs/cgroup/cpu/cpu.stat，查看nr_throttled（节流次数）和throttled_time（节流总时长）数值，如果任务运行期间两个值快速上涨，说明CPU被K8s限流
  • 在Agent工作目录下用fio测试4k随机读写的IOPS和延迟，和原本地Agent的磁盘性能做对比，如果随机读延迟超过10ms，说明存储性能不达标
  • 查看EC2实例监控数据，确认CPU积分余额、网络带宽利用率、磁盘IO队列长度，排除实例规格的突发性能瓶颈
• 任务耗时拆解：打开Jenkins任务的Pipeline Steps视图，逐行对比每个步骤在云Agent和本地Agent上的耗时差：如果echo、ls这类原本毫秒级的小命令步骤，耗时都比本地高几十毫秒，就是通信延迟累加导致的；如果编译、单元测试这类CPU密集步骤耗时翻倍，就是CPU资源限制问题；如果文件读写、缓存解压类步骤耗时明显偏高，就是存储IO问题。

根据定位到的根因对应调整，通用优化方案包括：

• 通信与链路优化
  • 开启Jenkins Remoting协议的NIO传输模式，调整批量传输参数，将多个小通信请求合并发送，减少网络往返次数
  • 优化Pipeline写法，把连续的多条shell命令合并到同一个sh步骤中执行，减少和Controller的交互次数；避免在Pipeline中写大量零散的单命令步骤
  • 调整跨网链路配置：为Jenkins通信流量配置QoS优先级保障，关闭防火墙针对该流量的深度包检测，匹配两端链路MTU值避免数据包分片
  • 长期架构调整：优先将Jenkins Controller迁移到AWS同区域，和EKS集群同VPC部署；短期可在AWS侧部署Jenkins代理节点，尽可能降低跨网交互的流量占比
• EKS资源配置优化
  • 将运行Jenkins Agent的EC2节点替换为固定性能的实例类型（如C系列计算型、M系列通用型实例），不要用T系列突发性能实例跑构建任务
  • Agent Pod的CPU、内存requests和limits设为完全相同的值，让Pod进入Guaranteed QoS等级，从根本上避免CPU节流
  • Agent工作目录使用节点本地SSD盘或gp3类型高性能EBS卷，不要用EFS等分布式网络存储挂载工作目录
  • 为Jenkins Agent配置独立的节点池，不要和在线业务Pod混部，避免资源抢占
• Jenkins侧配置优化
  • 清理不必要的插件，尤其是会在每个构建步骤注入逻辑的监听器类插件，减少冗余通信开销
  • 调整控制台日志配置，开启日志批量回传，不要每产生一行日志就立刻同步到Controller
  • 尽量减少stash/unstash步骤的使用，跨节点文件传输优先用对象存储中转，不要走Jenkins Remoting通道传输文件

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