CoreDNS在Kubernetes集群中运行失败

Question

我正在尝试设置Kubernetes集群，但无法运行CoreDNS。我运行了以下命令来启动集群：

sudo swapoff -a
sudo sysctl net.bridge.bridge-nf-call-iptables=1
sudo kubeadm init

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s- version=$(kubectl version | base64 | tr -d '\n')"
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml

为了用kubectl get pods --all-namespaces检查PODs，我得到了

NAMESPACE     NAME                                    READY   STATUS             RESTARTS   AGE
kube-system   coredns-68fb79bcf6-6s5bp                0/1     CrashLoopBackOff   6          10m
kube-system   coredns-68fb79bcf6-hckxq                0/1     CrashLoopBackOff   6          10m
kube-system   etcd-myserver                           1/1     Running            0          79m
kube-system   kube-apiserver-myserver                 1/1     Running            0          79m
kube-system   kube-controller-manager-myserver        1/1     Running            0          79m
kube-system   kube-proxy-9ls64                        1/1     Running            0          80m
kube-system   kube-scheduler-myserver                 1/1     Running            0          79m
kube-system   kubernetes-dashboard-77fd78f978-tqt8m   1/1     Running            0          80m
kube-system   weave-net-zmhwg                         2/2     Running            0          80m

所以CoreDNS一直在崩溃。我能找到的唯一错误消息来自/var/log/syslog

Oct  4 18:06:44 myserver kubelet[16397]: E1004 18:06:44.961409   16397 pod_workers.go:186] Error syncing pod c456a48b-c7c3-11e8-bf23-02426706c77f ("coredns-68fb79bcf6-6s5bp_kube-system(c456a48b-c7c3-11e8-bf23-02426706c77f)"), skipping: failed to "StartContainer" for "coredns" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=coredns pod=coredns-68fb79bcf6-6s5bp_kube-system(c456a48b-c7c3-11e8-bf23-02426706c77f)"

来自kubectl logs coredns-68fb79bcf6-6s5bp -n kube-system

.:53
2018/10/04 11:04:55 [INFO] CoreDNS-1.2.2
2018/10/04 11:04:55 [INFO] linux/amd64, go1.11, eb51e8b
CoreDNS-1.2.2
linux/amd64, go1.11, eb51e8b
2018/10/04 11:04:55 [INFO] plugin/reload: Running configuration MD5 = f65c4821c8a9b7b5eb30fa4fbc167769
2018/10/04 11:04:55 [FATAL] plugin/loop: Seen "HINFO IN 3256902131464476443.1309143030470211725." more than twice, loop detected

我找到的一些解决方案是

kubectl -n kube-system get deployment coredns -o yaml | \
sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
kubectl apply -f -

并将/etc/resolv.conf修改为指向实际的DNS，而不是我也尝试过的localhost。

这个问题在https://kubernetes.io/docs/setup/independent/troubleshooting-kubeadm/#pods-in-runcontainererror-crashloopbackoff-or-error-state中有描述，我尝试了许多不同的Pod Networks，但都没有帮助。

我已经运行过sudo kubeadm reset && rm -rf ~/.kube/ && sudo kubeadm init好几次了。

我运行的是Ubuntu 16.04，Kubernetes 1.12和Docker 17.03。有什么想法吗？

Answer 1

我也有同样的问题。

我已经解决了这个问题，删除了核心数cm内的插件“循环”。但我不知道这个云是否还存在其他问题。

1系统kubectl edit cm coredns -n kube-、

2个、delete ‘loop’ ,save and exit

3、重启核心pods的方式：kubectl delete pod coredns.... -n kube-system

Answer 2

通过使用下面的方法解决了一些问题：

1. 打开并编辑核心的配置映射。kubectl edit cm coredns -n kube-system

1. “将proxy . /etc/resolv.conf替换为上游DNS的ip地址，例如proxy .8.8.8.8。”根据核心(在本页的末尾)，删除保存和exit.
2. kubectl get pods -n kube-

-oname |grep

1. |xargs kubectl the link in the output of the coredns log -n kube-system

问题的原因在link中进行了解释。您可以在此cmd的输出中找到此链接

kubectl日志核心-7d9cd4f75b-cpwxp -n kube-系统

此链接位于CoreDNS-1.2.4的输出中。

我使用此命令升级CoreDNS

cpu kubectl补丁部署-n=kube-系统核心-p‘{“规格”：{“模板”：{"spec":{"containers":{"image":"k8s.gcr.io/coredns:1.2.4"，“名称”：“核心”，“资源”：{“限制”：{“内存”：“1Gi”}，“请求”：{“cpu”：“100M”，“内存”：“70Mi”}’

Answer 3

我认为简单地从Kubernetes中删除loop函数并不是一个干净的方法。CoreDNS Github实际上为解决这个问题提供了一些指导。

他们在他们的指南中提出了3种方法

• 将以下内容添加到kubelet：--resolv-conf。您的“真正”resolv.conf包含上游服务器的实际is地址，而不包含本地/环回地址。这个标志告诉kubelet将一个备用resolv.conf传递给Pods。对于使用systemd解析的系统，/run/systemd/resolve/resolv.conf通常是“真正的”resolv.conf的位置，不过根据您的发行版的不同，这个位置可能会有所不同。
• 禁用主机节点上的本地DNS缓存，并将/etc/resolv.conf恢复到原始状态。
• 一个快速而肮脏的修复方法是编辑您的核心文件，替换代理。/etc/resolv.conf和您的上游DNS的ip地址，例如proxy。8.8.8.8。但这只解决了CoreDNS的问题，kubelet将继续将无效的resolv.conf转发到所有默认的dnsPolicy Pod，使它们无法解析DNS。