【问题标题】:GKE - Kube-DNS resolution to VPN networkGKE - 到 VPN 网络的 Kube-DNS 解析
【发布时间】:2018-10-08 19:15:38
【问题描述】:

刚接触 GCloud 和 GKE,对 DNS 感到沮丧。

我们的办公室和运行共享 VPC 的 GCloud 之间有一个 VPN。现有的防火墙规则似乎工作正常。我们可以双向 ping 通,我们可以成功 ssh 到 Google。

所以现在在 GKE 中,我们需要能够使用 DNS 跨 VPN 解析主机名。应该很简单。

我编辑了 kube-dns 配置映射,并使用指向我们两个 DNS 服务器的 stubDomains 添加了我们的内部域名。重新部署 kube-dns pod 后,我在日志中验证了它们正在获取新的 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

现在据我所知,Egress 应该是 Google 对其他任何东西的明确允许。

但以防万一,我添加了一个出口规则以允许 TCP/UDP 53 到服务器。也没有运气。

有什么想法吗?

【问题讨论】:

  • 能否提供kube-dns configmap?
  • 所以看起来我让 stubDomain 为使用 kube-dns 的容器工作。但是我们也有使用节点 IP 的容器,以及使用 Kube-DNS 的节点 DNS 设置,所以现在我们又被卡住了。
  • 这解释了它,因此您需要更新 resolv.conf 以包含您的私有名称服务器。问题是节点 resolv.conf 每当更新 DHCP 租约时都会被元数据服务器替换
  • 我认为我们仍然在寻找稍微错误的树。为了测试我编辑了resolved.conf,添加了我的上游DNS服务器,它仍然拒绝解析其他域中的任何主机名。我可以看到查询命中 VPC 防火墙,但之后没有任何反应。
  • 知道了。事实证明,我们的 VPN 隧道很快就掉线了,隧道只能从我们的办公室启动,而不是 Gcloud。一旦我购买了隧道,并对resolved.conf 进行了更改,一切似乎都在工作。我想我们必须在 VPN 隧道路由上放置一个 IPSLA。

标签: google-cloud-platform google-compute-engine google-kubernetes-engine


【解决方案1】:

为广大公众回顾我们在 cmets 中的讨论:

您可以使用 kube-DNS 配置映射来添加 stubDomain,您的 pod 将使用这些 stubDomain 进行名称解析。更改 configmap 后,需要重新创建 kube-dns pod 才能使更改生效。任何使用默认 dns 设置 (clusterFirst is the default) 的 pod 都将使用 kube-dns 进行解析。

使用 dns 配置的“默认”设置(针对节点 resolv.conf 解析)的 Pod 将忽略 configmap 中配置的 stubDomains。相反,我们需要更新节点的 resolve.conf 文件。

对此有两点需要注意。 1) 每个 GCE VM(包括节点)上的 resolv.conf 文件是overwritten by the metadata server whenever the DHCP lease is renewed。 2) 在集群创建期间无法以编程方式附加 dns 条目。

要解决此问题,请使用 daemonset as a startup script 将新的附加名称服务器附加到 resolv.conf 文件,然后为确保元数据服务器不会恢复文件,make the file immutable

【讨论】:

    【解决方案2】:

    我正在尝试猜测,因为我们没有您的 GKE 集群配置,但我已经遇到过类似的情况,我敢打赌您没有配置 IP Aliasing https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips

    一点解释:您无法从另一个 vpc 对等访问一个 vpc 对等,这意味着如果您在一个 VPC 中,则无法从与另一个项目或您的办公室的共享连接访问托管服务(通过我想是一个 vpn ipsec 隧道)。由于 GKE 是一项托管服务,默认情况下它会存在于一个私有网络中并打开一个与您的项目的连接,因此您不能使用很多东西(prometheus 用于监控或进行 DNS 解析,因为集群不知道如何加入您的其他网络)。

    IP Aliasing 通过在您的项目网络中创建集群来解决这个问题,这样您就可以访问您的集群,与您的项目的其余部分在同一 IP 范围内,并使用 vpc 对等。

    希望它能解决你的问题。

    【讨论】:

    • 感谢您的拍摄 - 不幸的是,在使用共享 VPC 时,您必须在集群中使用别名 IP。我可以在 VPC 防火墙日志中看到查询被“允许”通过 VPC 防火墙,但从未到达我们的 VPN。奇怪。
    • 如果您有 IP 别名,您有子网,您是否在 VPN 内为集群创建了路由?
    • 路由都在那里,我可以双向ping通。从一个普通的 GCE 实例,我可以成功地做一个 nslookup。
    • 我可以毫无问题地从其他网络卷曲集群内的页面。只有集群内的 DNS 才是问题所在。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-07-15
    • 2017-10-17
    • 1970-01-01
    • 2012-06-12
    相关资源
    最近更新 更多