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

Question

我遵循了许多在线教程，以在四个Raspberry Pi 4s上设置Kubernetes集群。我最终使用Flannel作为网络插件，因为这似乎是唯一可以在RPi上实际使用的插件，每个this guide from 2017的Pod网络CIDR为10.244.0.0/16。几乎所有东西都在工作... kube系统 namespace 中的所有基本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的容器中时并执行 curl -H "Host: www.google.com" 142.250.73.206，它会成功返回Google主页HTML。但是如前所述，如果我尝试使用主机名执行我之前的curl命令，那会超时。

Answer 1

创建一个简单的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 Pod是否正在运行

$ 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 Pane 中的错误
以下是健康的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, go1.10.3, 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, go1.10.3, 2e322f6
CoreDNS-1.2.0
linux/amd64, go1.10.3, 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