DNS 解析如何在具有多个网络的 Kubernetes 上工作？

Question

我有一个 4 节点 Kubernetes 集群、1 个控制器和 3 个工作线程。下面显示了它们如何配置版本。

NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME k8s-ctrl-1 Ready master 1h v1.11.2 192.168.191.100 <none> Ubuntu 18.04.1 LTS 4.15.0-1021-aws docker://18.6.1 turtle-host-01 Ready <none> 1h v1.11.2 192.168.191.53 <none> Ubuntu 18.04.1 LTS 4.15.0-29-generic docker://18.6.1 turtle-host-02 Ready <none> 1h v1.11.2 192.168.191.2 <none> Ubuntu 18.04.1 LTS 4.15.0-34-generic docker://18.6.1 turtle-host-03 Ready <none> 1h v1.11.2 192.168.191.3 <none> Ubuntu 18.04.1 LTS 4.15.0-33-generic docker://18.6.1

每个节点都有两个网络接口，为了论证eth0和eth1。eth1是我想要集群工作的网络。kubeadm init我使用并通过了设置控制器--api-advertise-address 192.168.191.100。然后工作节点使用该地址加入。

最后，在每个节点上，我修改了 kubelet 服务以进行--node-ip设置，以便布局如上所示。

集群似乎工作正常，我可以创建 Pod、部署等。但是我遇到的问题是没有一个 Pod 能够使用该kube-dns服务进行 DNS 解析。

这不是解析的问题，而是机器无法连接到DNS服务进行解析。例如，如果我运行一个busybox容器并访问它来执行，nslookup我会得到以下信息：

/ # nslookup www.google.co.uk nslookup: read: Connection refused nslookup: write to '10.96.0.10': Connection refused

我有一种感觉，这是因为没有使用默认网络，因此我怀疑某些 Iptables 规则不正确，也就是说这些只是猜测。

我已经尝试过法兰绒覆盖层和现在的编织网。Pod CIDR 范围为10.32.0.0/16默认，服务 CIDR 为默认。

我注意到，在 Kubernetes 1.11 中，现在有多个 pod 被称为coredns而不是一个kube-dns。

我希望这是一个提出这个问题的好地方。我确信我错过了一些小但重要的东西，所以如果有人有任何想法，我们将非常欢迎。

更新#1：

我应该说节点并不都在同一个地方。我在它们之间运行了一个 VPN，这就是我想要进行通信的网络。这是我必须尝试拥有分布式节点的想法。

更新#2：

我在 SO 上看到了另一个答案（Kubernetes 中的 DNS 不起作用），建议kubelet需要拥有--cluster-dns并--cluster-domain设置。我在家（在一个网络上）运行的 DEV K8s 集群确实就是这种情况。

然而，这个集群上的情况并非如此，我怀疑这是更新版本的问题。我确实将这两个设置添加到集群中的所有节点，但它并没有使事情正常工作。

更新#3

集群拓扑如下。

• 1 x 控制器位于 AWS 中
• 1 x Worker 位于 Azure 中
• 2 x Worker 是托管数据中心中的物理机器

所有计算机都使用 192.168.191.0/24 网络上的 ZeroTier VPN 相互连接。

我没有配置任何特殊的路由。我同意这可能就是问题所在，但我不能 100% 确定该路由应该是什么。

WRT 到kube-dns和nginx，我没有污染我的控制器，所以nginx不在主控上，不是busybox。nginx和busybox分别位于工人 1 和 2 上。

我曾经netcat测试过连接kube-dns，得到以下结果：

/ # nc -vv 10.96.0.10 53 nc: 10.96.0.10 (10.96.0.10:53): Connection refused sent 0, rcvd 0 / # nc -uvv 10.96.0.10 53 10.96.0.10 (10.96.0.10:53) open

UDP 连接未完成。

我修改了设置，以便可以在控制器上运行容器，因此kube-dns、nginx和busybox都在控制器上，并且我能够连接并解析针对 10.96.0.10 的 DNS 查询。

所以所有这些确实都指向路由或 IPTables 恕我直言，我只需要弄清楚它应该是什么。

更新#4

根据评论，我可以确认以下 ping 测试结果。

Master -> Azure Worker (Internet)  : SUCCESS : Traceroute SUCCESS
Master -> Azure Worker (VPN)       : SUCCESS : Traceroute SUCCESS
Azure Worker -> Master (Internet)  : SUCCESS : Traceroute FAIL (too many hops)
Azure Worker -> Master (VPN)       : SUCCESS : Traceroute SUCCESS

Master -> Colo Worker 1 (Internet) : SUCCESS : Traceroute SUCCESS
Master -> Colo Worker 1 (VPN)      : SUCCESS : Traceroute SUCCESS
Colo Worker 1 -> Master (Internet) : SUCCESS : Traceroute FAIL (too many hops)
Colo Worker 1 -> Master (VPN)      : SUCCESS : Traceroute SUCCESS

更新5

运行上述测试后，我开始考虑路由，我想知道它是否像通过 VPN 为服务 CIDR 范围 ( ) 提供到控制器的路由一样简单10.96.0.0/12。

因此，在不包含在集群中的主机上，我添加了一条路由：

route add -net 10.96.0.0/12 gw 192.168.191.100

然后我可以使用kube-dns服务器地址解析 DNS：

nslookup www.google.co.uk 10.96.0.10

所以我然后添加了一条路由，如上所述，到其中一个工作节点并尝试相同的操作。但它被阻止了，我没有得到回复。鉴于我可以使用来自非 kubernetes 计算机的适当路由通过 VPN 解析 DNS，我只能认为有一个 IPTables 规则需要更新或添加。

我想这已经差不多了，还剩下最后一点需要解决。

我意识到这是错误的，因为它应该kube-proxy在每个主机上进行 DNS 解析。我将其留在这里以供参考。

Answer 1

按照本页的说明，尝试运行以下命令：

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsPolicy: "None"
  dnsConfig:
    nameservers:
      - 1.2.3.4
    searches:
      - ns1.svc.cluster.local
      - my.dns.search.suffix
    options:
      - name: ndots
        value: "2"
      - name: edns0

并查看手动配置是否有效或者您是否存在网络 DNS 问题。