在私有子网中运行时 AWS EKS 上的 DNS 问题答案

【问题标题】：DNS problem on AWS EKS when running in private subnets在私有子网中运行时 AWS EKS 上的 DNS 问题
【发布时间】：2019-02-15 23:13:46
【问题描述】：

我在 VPC 中设置了 EKS 集群。工作程序节点在私有子网中启动。我可以成功部署 pod 和服务。

但是，我无法从 pod 中执行 DNS 解析。（它在容器外的工作节点上运行良好。）

使用https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/ 进行故障排除会导致 nslookup 出现以下结果（大约一分钟后超时）：

服务器：172.20.0.10 地址一：172.20.0.10

nslookup：无法解析“kubernetes.default”

当我在全公共 VPC 中启动集群时，我没有遇到这个问题。我是否遗漏了从私有子网中进行 DNS 解析的任何必要步骤？

非常感谢，丹尼尔

【问题讨论】：

是kube-dns 还是core-dns？当你输入kubectl get pods -n kube-system 时它会说什么？检查pod中容器中的/etc/resolv.conf，它应该指向kube-dns/core-dns internap IP地址
Rico，kube-dns 已启动并正在运行。不知道如何找到 kube-dns 的内部 IP，但容器中的 resolv.conf 如下所示：nameserver 10.100.0.10 search default.svc.cluster.local svc.cluster.local cluster.local eu-west- 1.compute.internal us-west-2.compute.internal 选项 ndots:5
找到了kube-dns服务的IP，是10.100.0.10，也就是我容器的/etc/resolv.conf中指定的IP。
你是对的！问题在于我们自定义 VPC 中的网络 ACL。必须打开 UDP 流量才能使 kube-dns 正常工作。还没有弄清楚哪些端口，似乎需要多个端口（包括 53）。感谢您的帮助！
@TommyAdamski 只允许我的 ACL 上端口 53 上的出站 UDP 流量对我有用 - 在尝试之前给它几秒钟的时间来更新

标签： kubernetes amazon-vpc amazon-eks

【解决方案1】：

我也遇到过这个。我有多个节点组，每个节点组都是从 CloudFormation 模板创建的。 CloudFormation 模板为每个节点组创建了一个安全组，允许该组中的节点相互通信。

DNS 错误是由于 Pod 在与 CoreDNS Pod 不同的节点组中运行导致的，因此 Pod 无法访问 CoreDNS（仅允许与节点组进行网络通信）。我将为节点安全组创建一个新的 CloudFormation 模板，以便我集群中的所有节点组可以共享同一个安全组。

我现在通过允许每个节点组安全组的端口 53 上的入站 UDP 流量解决了这个问题。

【讨论】：

【解决方案2】：

我们遇到了类似的问题，其中一些 pod 上的 DNS 解析超时，但重新创建 pod 几次可以解决问题。此外，并非给定节点上的每个 pod 都显示问题，只有一些 pod。

原来是由于 Amazon VPC CNI 的 1.5.4 版本中的一个错误，更多详细信息在这里 -- https://github.com/aws/amazon-vpc-cni-k8s/issues/641。

快速解决方案是恢复到推荐版本1.5.3 - https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html

【讨论】：

【解决方案3】：

回复：AWS EKS Kube 集群和来自 pod 的 Route53 内部/私有 Route53 查询

只是想发布一条说明，说明我们需要采取哪些措施来解决我们的问题。注意YMMV和每个人有不同的环境和分辨率等。

免责声明：我们正在使用社区 terraform eks 模块来部署/管理 vpcs 和 eks 集群。我们不需要修改任何安全组。我们正在处理多个集群、区域和 VPC。

参考： Terraform EKS module

CoreDNS 更改：我们有一个私有内部的 DNS 中继，所以我们需要修改 coredns configmap 并添加 dns-relay IP 地址 ...

ec2.internal:53 {
    errors
    cache 30
    forward . 10.1.1.245
}
foo.dev.com:53 {
    errors
    cache 30
    forward . 10.1.1.245
}
foo.stage.com:53 {
    errors
    cache 30
    forward . 10.1.1.245
}

...

VPC DHCP 选项集：如果适用，使用上述中继服务器的 IP 进行更新 - 需要重新生成选项集，因为它们无法修改。

我们的 DHCP 选项集如下所示：

["AmazonProvidedDNS", "10.1.1.245", "169.254.169.253"]

参考：AWS DHCP Option Sets

Route-53 更新：将每个 route53 区域与您需要关联的 VPC-ID 关联（我们的 kube 集群所在的位置，pod 将从中进行查询）。

还有一个 terraform 模块： https://www.terraform.io/docs/providers/aws/r/route53_zone_association.html

【讨论】：

【解决方案4】：

要详细说明@Daniel 的评论，您需要：

UDP 端口 53 的入口规则
临时端口上的 UDP 入口规则（例如 1025–65535）

我没有添加 (2) 并且看到 CoreDNS 接收请求并尝试响应，但响应没有返回给请求者。

为其他处理此类问题的其他人提供一些提示，通过将 log 配置添加到 configmap 来打开 CoreDNS 日志记录，我可以使用 kubectl edit configmap -n kube-system coredns 来做到这一点。请参阅https://github.com/coredns/coredns/blob/master/README.md#examples 上的 CoreDNS 文档，这可以帮助您确定问题是 CoreDNS 接收查询还是发回响应。

【讨论】：

更详细地说，UDP 端口 53 的入口规则 not 需要打开 - 它可以限制为来自 VPC cidr 块的 IP，即 10.0.0.0/16
临时端口同样可以限制为来自 VPC cidr 块的 IP。考虑使用 1024-65535，因为这是 AWS 推荐的。

【解决方案5】：

因此，我想我已经挣扎了几个小时，忘记了时间，还有这个问题。

由于我使用的是默认 VPC，但工作节点位于私有子网中，因此无法正常工作。

我浏览了 amazon-vpc-cni-k8s 并找到了解决方案。

我们必须对 aws-node daemonset AWS_VPC_K8S_CNI_EXTERNALSNAT=true 的环境变量进行 sff。

您可以获取新的 yaml 并应用，也可以通过仪表板进行修复。但是，要使其正常工作，您必须重新启动工作节点实例，以便刷新 ip 路由表。

问题链接是here

谢谢

【讨论】：

这是个好消息，如果必须重新启动一个，我将不得不再次通过 stackoverflow 嗅探 :)

【解决方案6】：

我觉得我必须给出一个正确的答案，因为这个问题是我连续 10 小时调试的答案。正如@Daniel 在他的评论中所说，我发现的问题是我的 ACL 阻止了 UDP 端口 53 上的出站流量，这显然是 kubernetes 用来解析 DNS 记录的。

这个过程让我特别困惑，因为我的一个 Pod 实际上一直在工作，因为（我认为？）它恰好与 kubernetes DNS 解析器位于同一区域。

【讨论】：

嘿，我面临着完全相同的问题。我的 pod 无法解析 dns 或访问互联网。我尝试修复 NACL，但它不起作用我使用的是默认 VPC，工作节点位于私有子网中，而 EKS 中选择的子网也是私有的。你能帮忙吗？
也只是花了太多时间来调试这个。巨大的帮助！并感谢下面的@mattwilber 更明确地说明要进行哪些更改。
我正在经历完全相同的场景，是的，我也有一些 pod 工作得很好，我怀疑它们与 DNS 解析器位于同一区域。问题原来是在 NACL 中完全拒绝了 UDP。向 VPC 开放 UDP 解决了这个问题。