Jenkins在AKS上的动态Slave反复连接断开如何排查？

核心问题定位 #

从日志和配置看，两个报错里HOME is not set和Pod启动配置错误是根因，Node was deleted, computer is null是启动失败后的连锁报错，不是触发循环的根本原因。
当前Pod模板存在明确配置错误：你给jnlp容器自定义了启动命令/bin/sh -c、启动参数cat，这会直接覆盖jenkins/inbound-agent镜像的默认入口，导致jnlp agent进程根本不会启动，Pod只会常驻cat命令等待输入，永远不会向Jenkins Master发起注册，Master等待注册超时就会删除Pod触发重建，这是循环的首要诱因。

排查步骤 #

• 先校验Slave Pod实际运行状态：执行kubectl get pods -n jenkins-test查看Slave Pod的运行状态、重启次数，再执行kubectl logs -f <slave-pod-name> -n jenkins-test -c jnlp查看容器实际输出，会发现容器没有任何agent启动日志，只有cat命令的等待状态，验证启动命令被覆盖的问题。
• 校验环境变量注入情况：执行kubectl exec -it <slave-pod-name> -n jenkins-test -c jnlp -- env查看容器内的环境变量，会发现没有HOME变量，触发Gradle构建扫描插件注入失败，Jenkins判定节点初始化异常直接删除节点。
• 企业代理场景连通性校验：在jenkins-test命名空间下启动一个调试用的curl镜像Pod，分别访问Jenkins Master的8080（Web端口）、50000（jnlp通信端口），确认代理没有阻断两个端口的长连接，同时确认代理放通了容器镜像仓库的地址，不会因为镜像拉取失败导致Pod反复重建。
• 插件版本校验：进入Jenkins插件管理页面，查看Kubernetes插件版本，早于390.v34ca_e30c50b_的版本存在Slave启动竞态问题，会在高并发构建场景下误删正常启动的节点，也会触发同类报错。

修复方案 #

• 修正Pod启动配置：删除jnlp容器自定义的command和args字段，使用镜像默认的启动入口，保证jnlp agent进程正常启动，主动连接Master完成注册。
• 显式注入必要环境变量：在jnlp容器配置中添加环境变量HOME=/home/jenkins，和工作目录/home/jenkins/agent匹配，解决Gradle插件找不到HOME目录的报错；如果集群配置了企业代理，同步把HTTP_PROXY、HTTPS_PROXY、NO_PROXY三个环境变量注入到容器中，保证Slave能正常拉取依赖、连接Master。
• 补全基础运行配置：给jnlp容器配置合理的资源请求与限制，参考值为CPU请求100m、内存请求256Mi，CPU上限2核、内存上限4Gi，避免AKS节点资源不足时驱逐Slave Pod；添加存活探针，检测命令配置为sh -c "pgrep -f jenkins-slave || exit 1"，初始延迟30秒，检测间隔10秒，失败阈值3次，及时识别异常Pod。
• 版本对齐：如果Kubernetes插件版本过低，先升级到经过验证的稳定版，升级完成后重启Jenkins Master再测试构建任务。

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