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

时间：2018-09-11 16:45:07

标签： kubernetes kube-dns

我有一个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，以使布局看起来像上图。

集群似乎正常工作，我可以创建容器，部署等。但是，我遇到的问题是，没有一个容器能够使用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规则不正确，因为这些只是猜测。

我已经尝试了Flannel覆盖层和现在的Weave网。 Pod CIDR范围是10.32.0.0/16，服务CIDR是默认设置。

我注意到，在Kubernetes 1.11中，现在有名为coredns的Pod，而不是一个kube-dns。

我希望这是一个问这个问题的好地方。我确信我缺少一些小而重要的东西，所以如果有人有什么想法是最受欢迎的。

更新＃1：

我应该说节点不在同一位置。我在所有人之间都运行有VPN，这是我希望事物进行通信的网络。这是我必须尝试并具有分布式节点的想法。

更新＃2：

我在SO（DNS in Kubernetes not working）上看到了另一个答案，表明kubelet需要设置--cluster-dns和--cluster-domain。我在家里（在一个网络上）运行的DEV K8s群集上确实是这种情况。

但是，在该群集上不是这种情况，我怀疑这是因为它是最新版本。我确实将这两个设置添加到了群集中的所有节点，但是并没有使事情正常。

更新＃3

集群的拓扑如下。

  • 1个Controller在AWS中
  • 1 x Worker在Azure中
  • 2 x Worker是colo数据中心中的物理机器

所有计算机都通过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都在控制器上，并且我能够连接并解析DNS针对10.96.0.10的查询。

所以所有这些都指向路由或IPTables IMHO，我只需要弄清楚应该是什么。

更新＃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解析。我将其留在此处以供参考。

2 个答案:

答案 0 :(得分：1)

按照此page上的说明，尝试运行此命令：

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问题。

答案 1 :(得分：1)

听起来像您正在AWS上运行。我怀疑您的AWS安全组不允许DNS通信通过。您可以尝试允许所有流量进入所有主节点和节点所在的安全组，以查看是否存在问题。

sg

您还可以检查所有主节点和节点都允许路由：

cat /proc/sys/net/ipv4/ip_forward

如果不是

echo 1 > /proc/sys/net/ipv4/ip_forward

希望有帮助。

相关问题
最新问题