我已经设置了一个Kubernets集群，其中有一个主服务器（kube-master）和两个从属服务器（kube-node-01和kube-node-02）
在debian Stretch扩展之后，现在一切运行良好...->破坏升级后，由于某些原因，我的coredns pod因CrashLoopBackOff而失败。
我做了一个kubectl describe，错误是Readiness probe failed: HTTP probe failed with statuscode: 503
对我来说，就绪URL似乎可疑http-get http://:8080/health delay=0s timeout=1s period=10s #success=1 #failure=3 ...没有主机名！？正确吗？
Liveness属性也没有主机名。
所有虚拟机都可以相互ping通。
有什么想法吗？
答案 0 :(得分：1)
将主机升级到使用systemd-resolved作为DNS服务器的ubuntu 18.04时，遇到了类似的问题。 /etc/resolv.conf中的nameserver字段正在使用本地IP地址127.0.0.53，这将导致coreDNS无法启动。
您可以通过以下链接查看详细信息。 https://github.com/coredns/coredns/blob/master/plugin/loop/README.md#troubleshooting-loops-in-kubernetes-clusters
答案 1 :(得分：0)
我将通过在主节点和工作节点上进行kubelet代理验证来开始故障排除，以便在其余核心运行时Pod启动并运行时排除群集节点内的任何互通问题，因为kubelet是主要贡献者
Liveness和Readiness探测。
systemctl status kubelet -l
journalctl -u kubelet
在健康检查URL中提及的问题很好，因为它们是根据每个设计在CoreDNS部署中预定义的。
确保CNI插件Pod正常运行，并且集群覆盖网络拦截Pod到Pod通信的请求，因为CoreDNS对与整个集群网络相关的任何问题都非常敏感。
除了@Hang Du关于CoreDNS pods环回问题的答案外，我鼓励您在官方的k8s调试documentation中获得有关CoreDNS问题调查的更多信息。
答案 2 :(得分：0)
我自己碰到了这个问题。显然，运行状况检查网址中缺少主机名是可以的。
让我领先的是
microk8s.inspect
输出表明iptables转发存在问题。由于我的系统已设置防火墙，因此我暂时将其禁用
systemctl stop firewalld
然后在microk8s中禁用dns，然后再次启用它（由于某些未知原因，dns pod不能自行启动）
microk8s.disable dns
microk8s.enable dns
开始时没有任何问题。