CoreDNS Pod崩溃疑问：是否需要知晓局域网路由器DNS真实IP？

首先直接给你答案：是的，CoreDNS确实需要能正常访问到你局域网路由器的DNS服务（也就是10.8.191.167），这是正常且必要的——默认情况下，CoreDNS会把集群内部无法解析的域名请求（比如外部公网域名）转发到宿主机系统配置的DNS服务器（也就是你的路由器），如果CoreDNS的Pod连不上这个外部DNS，就会不断出现超时错误，最终导致Pod崩溃重启，也就是你看到的CrashLoopBackOff状态。

从你提供的日志来看，核心问题就是CoreDNS Pod（IP是10.244.1.43，属于Flannel的Pod网络段）无法和路由器的53端口（DNS服务端口）通信，反复出现read udp ... i/o timeout的错误，这是导致Pod崩溃的直接原因。

给你几个具体的排查和解决步骤：

• 先排查Worker节点本身的网络连通性
  你的CoreDNS Pod都跑在thinkpad-x260这个Worker节点上，先登录这个节点，测试它能不能正常访问路由器DNS：

  # 在thinkpad-x260终端执行
  ping 10.8.191.167
  nslookup google.com 10.8.191.167
  

  如果节点本身都ping不通或者DNS查询失败，那问题出在节点的网络配置上——比如路由器有没有限制这个节点的访问，或者节点的防火墙（比如ufw）挡住了53端口的流量，先把节点到路由器的连通性搞定。

• 再测试Pod网络到路由器的连通性
  节点本身没问题的话，再用你已经运行的bash Pod（10.244.1.42）测试Pod网络能不能访问路由器DNS：

  kubectl exec -it bash -- ping 10.8.191.167
  kubectl exec -it bash -- nslookup google.com 10.8.191.167
  

  如果Pod里连不上，那大概率是Flannel网络的转发规则出问题了，比如节点有没有开启IP转发（可以用sysctl net.ipv4.ip_forward检查，应该返回1），或者节点的iptables规则挡住了Pod网络到局域网的流量，需要调整Flannel相关的iptables规则或者重启Flannel Pod试试。

• 临时替换CoreDNS的转发目标（应急方案）
  如果暂时搞不定路由器DNS的连通性，你可以修改CoreDNS的配置，把外部请求转发到公共DNS（比如谷歌的8.8.8.8），这样能先让CoreDNS稳定下来：

  kubectl edit configmap coredns -n kube-system
  

  找到配置里的forward块，把原来的./etc/resolv.conf改成8.8.8.8 8.8.4.4，保存退出后，CoreDNS Pod会自动重载配置，你可以观察它的状态是否恢复正常。

另外，你日志里的[WARNING] plugin/kubernetes: starting server with unsynced Kubernetes API这个警告不用太担心，一般是CoreDNS启动时还没来得及同步K8S API数据，不是导致崩溃的主要原因，先解决DNS超时的问题就行。

备注：内容来源于stack exchange，提问作者watery