Kubernetes环境中Jenkins Slave Pod的JNLP容器DNS解析异常求助

我之前碰到过几乎一模一样的场景——Jenkins Master的DNS一切正常，但Slave Pod里的JNLP容器死活解析不了内外域名，折腾了好一阵才搞定，咱们一步步来排查：

1. 先扒清楚Slave Pod的DNS配置细节 #

首先进到Slave的JNLP容器里，先看看最核心的DNS配置文件：

kubectl exec -it <你的Slave Pod名称> -c jnlp -- cat /etc/resolv.conf

把这个内容和Master Pod里的/etc/resolv.conf对比一下，重点看nameserver是不是集群DNS的地址（通常是10.96.0.10，或者你集群里CoreDNS/kube-dns的ClusterIP），还有search域是不是正确的集群域名后缀。如果Slave的文件里没有这些，那问题大概率出在DNS策略上。

顺手检查下Slave Pod的DNS策略配置，看看YAML里的dnsPolicy字段：默认应该是ClusterFirst，如果被改成了Default或者其他值，就会导致Pod用节点的DNS而不是集群DNS，手动改回来就行：

spec:
  dnsPolicy: ClusterFirst

2. 测试Slave能不能连到集群DNS服务 #

光看配置还不够，得实际测一下连通性：

# 先ping集群DNS地址，看能不能通
kubectl exec -it <你的Slave Pod名称> -c jnlp -- ping 10.96.0.10
# 再用nslookup试试解析集群内部域名（比如kubernetes服务）
kubectl exec -it <你的Slave Pod名称> -c jnlp -- nslookup kubernetes.default.svc.cluster.local

如果连DNS服务都ping不通，那十有八九是网络策略（NetworkPolicy）把Slave Pod的出站流量给限制了，或者你的CNI插件（比如Calico、Flannel）配置了阻止Pod到DNS服务的规则，得去检查这些网络层面的配置。

3. 查Jenkins Slave模板的坑 #

Jenkins创建Slave Pod的时候，很容易因为模板配置覆盖了默认网络设置：

• 看看模板里有没有开hostNetwork: true？如果开了主机网络，Pod会用节点的DNS配置，和集群DNS大概率不兼容，关掉就行。
• 有没有加自定义的dnsConfig？如果配置了错误的nameserver，直接就废了，删掉或者改成正确的集群DNS地址。
• 试试把Slave的JNLP镜像换成和Master一样的jenkins/jenkins:lts，有时候自定义的Slave镜像可能偷偷改了DNS配置，或者连nslookup这类工具都没装，先排除镜像本身的问题。

4. 顺便检查下Service Account #

这个情况比较少见，但万一呢？看看Slave Pod用的Service Account是不是和Master一样，有没有设置automountServiceAccountToken: false——虽然DNS解析本身不依赖这个，但如果禁用了自动挂载，有时候会影响Pod和集群的交互，先开着试试。

5. 对比Busybox容器的情况 #

你提到Slave Pod里还有Busybox容器，先测测Busybox能不能正常解析？如果Busybox没问题，那肯定是JNLP容器自己的问题——比如镜像里的DNS设置被修改了，或者启动时加了奇怪的环境变量（比如DNS_SERVER这类）覆盖了集群配置，得去检查镜像的Dockerfile或者Jenkins启动参数。

6. 终极临时方案：强制指定DNS #

如果上面的排查都没找到根因，可以先在Slave Pod模板里硬编码DNS配置救急：

spec:
  dnsConfig:
    nameservers:
      - 10.96.0.10  # 换成你集群的DNS地址
    searches:
      - default.svc.cluster.local
      - svc.cluster.local
      - cluster.local

重新启动Slave Pod，应该就能正常解析了，之后再慢慢找根本原因。

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