如何解决如何让CoreDNS在我的Raspberry Pi Kubernetes群集上解析?
我已经遵循了许多在线教程,以在四个RaspBerry Pi 4s上设置Kubernetes集群。我最终使用Flannel作为网络插件,因为这似乎是唯一可以在RPi上实际使用的插件,每个this guide from 2017的Pod网络CIDR为10.244.0.0/16。几乎所有东西都在工作... kube系统名称空间中的所有基本pod都在运行/运行状况良好,我可以提取图像并启动新容器。最初我无法获取任何Pod日志,但是通过在每个节点上打开端口10250可以很快解决。
但是DNS解析似乎仍然有问题。我应该澄清一下,主机上的DNS解析显然可以正常工作,因为群集可以下载我指定的任何容器映像。但是,一旦容器运行,它就无法“拨出”任何东西。作为测试,我正在容器中运行arm32v7/buildpack-deps:latest
容器。它可以很好地从Docker集线器中提取映像。但是,当我将其装入其中并只需键入curl https://www.google.com
时,它便会挂起,直到最终超时。对于我启动的任何需要与外部Internet交互的Pod来说,情况都是如此:它们挂起,挂起并挂起。
以下是我已经在每个节点上运行的所有与网络相关的命令:
sudo iptables -P FORWARD ACCEPT
sudo iptables -A FORWARD -i cni0 -j ACCEPT
sudo iptables -A FORWARD -o cni0 -j ACCEPT
sudo ufw allow ssh
sudo ufw allow 443 # can't remember why i ran this one
sudo ufw allow 6443
sudo ufw allow 8080 # this one might not be strictly necessary,either
sudo ufw allow 10250
sudo ufw default allow routed
sudo ufw enable
我不完全确定最后两个iptables
命令有什么作用;我从the comment section of that guide I linked to earlier抓起了它们。我知道该指南假定其中一个正在使用kube-dns,但是它已经使用了3年,所以我改用(较新的)默认值coredns。
我想念什么?我感觉我已经接近使该群集完全正常运行,但是显然我需要运行DNS!
更新:我知道这是DNS问题,而不是一般的Internet连接,其原因有两个:(1)群集本身可以拉下我从dockerhub指定的任何映像,以及(2)当我将其装入运行中的容器时具有卷曲并执行curl -H "Host: www.google.com" 142.250.73.206
的文件,它将成功返回Google主页HTML。但是如前所述,如果我尝试使用主机名执行以前的curl命令,则会超时。
解决方法
- 创建一个简单的Pod用作DNS诊断的测试环境:
apiVersion: v1
kind: Pod
metadata:
name: dnsutils
namespace: default
spec:
containers:
- name: dnsutils
image: gcr.io/kubernetes-e2e-test-images/dnsutils:1.3
command:
- sleep
- "3600"
imagePullPolicy: IfNotPresent
restartPolicy: Always
kubectl apply -f dnsutils.yaml
- 检查Pod的状态
$ kubectl get pods dnsutils
NAME READY STATUS RESTARTS AGE
dnsutils 1/1 Running 0 <some-time>
运行Pod后,您可以在该环境中执行nslookup。如果您看到类似以下的内容,则说明DNS正常工作。
$ kubectl exec -i -t dnsutils -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10
Name: kubernetes.default
Address 1: 10.0.0.1
如果nslookup命令失败,请检查以下内容:
- 看看resolv.conf文件内部。
kubectl exec -ti dnsutils -- cat /etc/resolv.conf
验证是否按照以下方式设置了搜索路径和名称服务器(请注意,搜索路径可能会因不同的云提供商而有所不同):
search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
nameserver 10.0.0.10
options ndots:5
以下错误表明CoreDNS(或kube-dns)附加组件或相关服务存在问题
$ kubectl exec -i -t dnsutils -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10
nslookup: can't resolve 'kubernetes.default'
OR
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
nslookup: can't resolve 'kubernetes.default'
- 检查DNS窗格是否正在运行
$ kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
NAME READY STATUS RESTARTS AGE
...
coredns-7b96bf9f76-5hsxb 1/1 Running 0 1h
coredns-7b96bf9f76-mvmmt 1/1 Running 0 1h
...
- 检查DNS窗格中的错误 这是健康的CoreDNS日志的示例:
$ kubectl logs --namespace=kube-system -l k8s-app=kube-dns
.:53
2018/08/15 14:37:17 [INFO] CoreDNS-1.2.2
2018/08/15 14:37:17 [INFO] linux/amd64,go1.10.3,2e322f6
CoreDNS-1.2.2
linux/amd64,2e322f6
2018/08/15 14:37:17 [INFO] plugin/reload: Running configuration MD5 = 24e6c59e83ce706f07bcc82c31b1ea1c
- 使用kubectl get service命令验证DNS服务已启动。
$ kubectl get svc --namespace=kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
...
kube-dns ClusterIP 10.0.0.10 <none> 53/UDP,53/TCP 1h
...
- 您可以使用kubectl get endpoints命令验证DNS终结点是否公开。
$ kubectl get endpoints kube-dns --namespace=kube-system
NAME ENDPOINTS AGE
kube-dns 10.180.3.17:53,10.180.3.17:53 1h
- 您可以通过将日志插件添加到CoreDNS配置(也称为Corefile)来验证CoreDNS是否正在接收查询。 CoreDNS Corefile保存在名为coredns的ConfigMap中。要对其进行编辑,请使用以下命令:
$ kubectl -n kube-system edit configmap coredns
然后按照以下示例在Corefile部分中添加日志:
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
log
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
upstream
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
保存更改后,Kubernetes最多可能需要一两分钟才能将这些更改传播到CoreDNS Pod。 接下来,按照本文档上面的部分进行一些查询并查看日志。如果CoreDNS Pod正在接收查询,则应在日志中看到它们。
以下是日志中的查询示例:
.:53
2018/08/15 14:37:15 [INFO] CoreDNS-1.2.0
2018/08/15 14:37:15 [INFO] linux/amd64,2e322f6
CoreDNS-1.2.0
linux/amd64,2e322f6
2018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f
2018/09/07 15:29:04 [INFO] Reloading complete
172.17.0.18:41675 - [07/Sep/2018:15:29:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s
,
如评论中所指出:kubeadm
的配置似乎很好。
您的广告连播具有正确的/etc/resolv.conf
,它们应该可以正常工作。
很难确定问题所在-这里可能发生许多事情。
我的猜测:ufw
有点不对劲。
您可以轻松地证明这一点:在所有节点上禁用ufw
(使用ufw disable
)。
我不确定百分百需要哪个端口。我在单个节点k8上使用iptables
,开始时遇到了FORWARD
和INPUT
规则的许多问题。在docker中,所有端口都被转发。
因此,我想FORWARD
-规则和/或dns端口(53/udp
和53/tcp
)出了问题。
祝你好运。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。