如何让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）出了问题。

祝你好运。

coredns kubernetes ufw

如何让CoreDNS在我的Raspberry Pi Kubernetes群集上解析？

问题描述

解决方法

相关问答