Google cloud platform GKE-Kube对VPN网络的DNS解析

刚接触GCloud和GKE，在DNS方面经历了一段令人沮丧的时光

我们的办公室和运行共享VPC的GCloud之间有一个VPN。现有的防火墙规则似乎运行良好。我们可以通过两种方式ping，我们可以成功地ssh到Google

因此，现在在GKE内部，我们需要能够使用DNS在VPN上解析主机名。应该很简单

我编辑了kube dns配置图，并使用指向两个dns服务器的stubDomains添加了我们的内部域名。在重新部署kube dns吊舱之后，我在日志中验证了他们正在获得新的stubDomain部分。但是，我仍然无法解析任何主机，即使是从kube dns容器本身

登录到dnsmasq容器时：

/etc/k8s/dns/dnsmasq-nanny # cat stubDomains
{"internal.domain.com": ["10.85.128.5", "10.85.128.6"]}

/ # nslookup google.com
nslookup: can't resolve '(null)': Name does not resolve

Name:      google.com
Address 1: 108.177.9.138 ox-in-f138.1e100.net
Address 2: 108.177.9.101 ox-in-f101.1e100.net
Address 3: 108.177.9.139 ox-in-f139.1e100.net
Address 4: 108.177.9.100 ox-in-f100.1e100.net
Address 5: 108.177.9.102 ox-in-f102.1e100.net
Address 6: 108.177.9.113 ox-in-f113.1e100.net
Address 7: 2607:f8b0:4003:c13::71 ox-in-x71.1e100.net

/etc/k8s/dns/dnsmasq-nanny # cd /
/ # nslookup rancher.internal.domain.com
nslookup: can't resolve '(null)': Name does not resolve

nslookup: can't resolve 'rancher.internal.domain.com': Name does not resolve

nslookup: can't resolve 'rancher.internal.domain.com': Name does not resolve
/ # nslookup rancher.internal.domain.com 10.85.128.5
Server:    10.85.128.5
Address 1: 10.85.128.5

nslookup: can't resolve 'rancher.internal.domain.com': Name does not resolve

现在据我所知，谷歌的出口应该是对其他任何东西的明确许可

但为了以防万一，我添加了一个出口规则，允许TCP/UDP 53访问服务器。也不走运

---

有什么想法吗？

我在猜测，因为我们没有您的GKE群集配置，但我已经遇到类似的问题，我打赌您没有配置IP别名

一点解释：你不能从另一个vpc访问一个vpc，这意味着如果你在一个vpc中，你不能从另一个项目或你的办公室的共享连接访问托管服务（我想是通过vpn ipsec隧道）。由于GKE是一个托管服务，默认情况下它将位于一个私有网络中，并打开一个指向您的项目的窗口，因此您不能使用很多东西（prometheus用于监视或进行DNS解析，因为集群不知道如何加入您的其他网络）

IP别名是通过在项目网络内创建集群来解决这一问题，这样您就可以访问与项目其余部分相同IP范围内的集群，并使用vpc别名

---

希望它能解决您的问题。

为了让更多的公众了解我们在评论中的讨论：

您可以使用kube DNS configmap添加您的POD将用于名称解析的存根域。更改configmap后，需要重新创建kube dns吊舱，以使更改生效。任何使用默认dns设置（）的pod都将使用kube dns解析

使用dns配置的“默认”设置（根据节点resolv.conf解析）的POD将忽略configmap中配置的域。相反，我们需要更新nodes resolve.conf文件

有两件事需要注意。 1） 每个GCE VM（包括节点）上的resolv.conf文件是。 2） 在群集创建期间，无法通过编程方式附加dns条目

---

要解决此问题，请使用将新的附加名称服务器附加到resolv.conf文件中的，然后，为了确保元数据服务器不会还原该文件，

感谢您的拍摄-不幸的是，在使用共享VPC时，您必须在群集中使用别名IP。我可以在VPC防火墙日志中看到，查询被“允许”通过VPC防火墙，但从未到达我们的VPN。奇怪。如果你有ip别名，你有子网，你为VPN内的群集创建了路由吗？路由在那里，我可以在两个方向成功ping。通过一个普通的GCE实例，我可以成功地进行nslookup，并且可以从另一个网络卷曲集群内的页面，而不会出现问题。问题出在集群内的只有DNS。你能提供kube DNS配置映射吗？所以看起来我让stubDomain为使用kube DNS的容器工作。但是我们也有使用节点IP的容器，节点DNS设置使用Kube DNS，所以现在我们又卡住了。这就解释了，所以您需要更新resolv.conf以包含您的私有名称服务器。问题是，每当DHCP租约续签时，节点resolv.conf就会被元数据服务器替换。我认为我们仍然在寻找稍微错误的树。为了测试，我编辑了resolved.conf，添加了我的上游DNS服务器，但它仍然拒绝解析其他域中的任何主机名。我可以看到查询击中了VPC防火墙，但之后什么也没有发生。明白了。事实证明，我们的VPN隧道运行得非常快，隧道只能从我们的办公室启动，而不能从Gcloud启动。一旦我买下了隧道，通过对resolved.conf所做的更改，一切似乎都在运行。我想我们必须在VPN隧道线路上安装IPSLA。