问题描述
我已经设置了一个Kubernetes集群，其中包含一个主服务器(kube-master)和2个从属服务器(kube-node-01和kube-node-02)
I have setup a Kubernetes cluster with one master (kube-master) and 2 slaves (kube-node-01 and kube-node-02)
在debian拉伸后，一切运行良好……现在->破坏升级由于某种原因，我的coredns Pod因CrashLoopBackOff失败.
All was running fine ... now after debian stretch -> buster upgrade my coredns pods are failing with CrashLoopBackOff for some reason.
我做了一个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 ...没有主机名！?正确吗?
The Readiness url looks suspicious to me http-get http://:8080/health delay=0s timeout=1s period=10s #success=1 #failure=3 ... there is no hostname !? is that correct?
Liveness属性也没有主机名.
所有vm都可以彼此ping通.
All vm's are pingable from each other.
有什么想法吗?
推荐答案
将主机升级到使用systemd-resolved作为DNS服务器的ubuntu 18.04时，我遇到了类似的问题. /etc/resolv.conf中的nameserver字段正在使用本地IP地址127.0.0.53，这将导致coreDNS无法启动.
I met similar issue when upgrade my host machine to ubuntu 18.04 which uses systemd-resolved as DNS server. The nameserver field in /etc/resolv.conf is using a local IP address 127.0.0.53 which would cause coreDNS failed to start.
您可以通过以下链接查看详细信息. https://github.com/coredns/coredns/blob/master/plugin/loop/README.md#troubleshooting-loops-in-kubernetes-clusters
You can take a look at the details from the following link.https://github.com/coredns/coredns/blob/master/plugin/loop/README.md#troubleshooting-loops-in-kubernetes-clusters
这篇关于Kubernetes Coredns准备就绪调查失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！