K3S集群中无法为CoreDNS添加A记录，Pod无法访问外部Git服务器

看起来你已经尝试通过配置coredns-custom ConfigMap来给你的Git服务器（gitea.local）添加A记录了，但Pod还是没法访问对吧？我来帮你一步步排查和解决这个问题。

首先复盘下你当前的操作：你在kube-system命名空间下创建了coredns-custom ConfigMap，通过default.server定义了gitea.local的hosts规则，指向192.168.56.41。接下来我们从几个关键点入手排查：

1. 确认自定义配置是否被CoreDNS正确加载 #

K3S的CoreDNS默认会自动导入coredns-custom里的规则，但还是要做下确认：

• 先检查ConfigMap是否正常创建：

  kubectl get configmap coredns-custom -n kube-system
  

  确保它存在，并且data字段里的default.server内容和你编写的完全一致。
• 查看CoreDNS Pod的日志，检查有没有加载自定义配置的记录，或者语法错误：

  kubectl logs -n kube-system -l k8s-app=kube-dns
  

  如果看到类似“Loaded custom config from coredns-custom”的日志，说明加载成功；如果有语法错误（比如括号不匹配、指令写错），这里会直接报错，你可以根据错误提示修正配置。

2. 检查CoreDNS主配置是否导入了自定义规则 #

有时候K3S的默认CoreDNS配置可能没开启自定义规则的导入，你需要检查coredns ConfigMap：

kubectl get configmap coredns -n kube-system -o yaml

找到Corefile部分，确认里面有一行import custom/*.server，如果没有的话，手动添加这行：

.:53 {
    errors
    health
    # 其他原有配置...
    import custom/*.server # 新增这行导入自定义规则
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    # 其他原有配置...
}

修改完成后，重启CoreDNS Pod让配置生效：

kubectl rollout restart deployment coredns -n kube-system

3. 优化你的自定义配置细节 #

你的default.server配置本身没大问题，但有几个小细节可以调整，让规则更清晰可靠：

• 把default.server改成gitea.local.server，这样CoreDNS会更精准地加载这个域名的规则，避免和其他自定义规则冲突：

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: coredns-custom
    namespace: kube-system
  data:
    gitea.local.server: |
      gitea.local {
          hosts {
                192.168.56.41 gitea.local
                fallthrough
          }
          log # 加上log指令，方便在CoreDNS日志里查看解析请求
      }
  

• 确保192.168.56.41这个IP是集群节点能直接访问的，先在节点上测试连通性：

  ping 192.168.56.41
  

  如果节点都ping不通这个IP，那Pod肯定也访问不了，这时候要先排查虚拟机之间的网络配置（比如VirtualBox的网卡模式、子网设置）。

4. 用测试Pod验证解析 #

用你提到的infoblox/dnstools镜像创建测试Pod，验证解析是否生效：

kubectl run -it --rm --restart=Never --image=infoblox/dnstools:latest dnstest

进入容器后，执行解析命令：

nslookup gitea.local

或者

dig gitea.local

如果返回的IP是192.168.56.41，说明配置已经生效；如果还是解析失败，要检查Pod的dnsPolicy是不是默认的ClusterFirst——如果Pod的dnsPolicy设为Default，会使用节点的DNS而不是CoreDNS，这时候需要调整Pod的DNS策略。

备选方案：直接修改CoreDNS主配置的hosts插件 #

如果自定义ConfigMap的方式始终有问题，你可以直接在CoreDNS的主配置里添加A记录，这种方式更直接，但注意K3S升级可能会覆盖这个配置：
修改coredns ConfigMap的Corefile部分：

.:53 {
    errors
    health
    hosts {
        192.168.56.41 gitea.local # 直接添加这行A记录
        fallthrough
    }
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    # 其他原有配置...
}

修改后同样需要重启CoreDNS Pod。

备注：内容来源于stack exchange，提问作者Nikola-Milovic