我觉得我必须给予这个问题一个合适的答案，因为这个问题是我连续10个小时调试的答案。正如@丹尼尔在他的评论中所说，我发现的问题是我的ACL阻止了UDP端口53上的出站流量，显然Kubernetes使用该端口来解析DNS记录。
这个过程对我来说尤其令人困惑，因为我的一个豆荚工作了，实际上从那以后一直工作（我想？）它恰好与kubernetes DNS解析器在同一个区域。

要详细说明@丹尼尔的评论，您需要：

1. UDP端口53的入口规则
   1.临时端口上的UDP的入口规则（例如，（电话：1025-65535）
   我没有添加（2），并且看到CoreDNS接收请求并试图响应，但响应没有返回到请求者。
   对于其他人处理这类问题的一些提示，通过将log配置添加到configmap来打开CoreDNS日志记录，我可以使用kubectl edit configmap -n kube-system coredns来完成。请参阅CoreDNS文档https://github.com/coredns/coredns/blob/master/README.md#examples这可以帮助您确定问题是CoreDNS接收查询还是发送回响应。

我也碰到了这个。我有多个节点组，每个都是从CloudFormation模板创建的。CloudFormation模板为每个节点组创建了一个安全组，允许该组中的节点相互通信。
DNS错误是由于Pod在与CoreDNS Pod不同的节点组中运行，因此Pod无法访问CoreDNS（仅允许在节点组内进行网络通信）。我将为节点安全组创建一个新的CloudFormation模板，以便集群中的所有节点组都可以共享同一个安全组。
我现在通过允许每个节点组安全组的端口53上的入站UDP流量解决了这个问题。

所以我一直在挣扎了几个小时，我想，失去了时间的轨道，与这个问题。
由于我使用的是默认VPC，但工作节点位于私有子网内，因此无法正常工作。
我通过amazon-vpc-cni-k8s找到了解决方案。
我们必须sff aws-node daemonset AWS_VPC_K8S_CNI_EXTERNALSNAT=true的环境变量。
您可以获取新的yaml并应用，或者通过 Jmeter 板修复它。但是，要使其工作，您必须重新启动工作节点示例，以便刷新IP路由表。
问题链接为here
滕克兹

Re：AWS EKS Kube集群和Route 53内部/私有Route 53从Pod查询

只是想贴一张便条，说明我们需要做些什么来解决我们的问题。注意到YMMV和每个人都有不同的环境和分辨率等。
免责声明：我们使用社区terraform eks模块来部署/管理vpc和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
}

...

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

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

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

ref：AWS DHCP选项集

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

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

我们遇到了一个类似的问题，DNS解析在一些Pod上超时，但是重新创建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

和其他人一样，我已经和这个bug斗争了几个小时。
在我的例子中，问题是这个bug https://github.com/awslabs/amazon-eks-ami/issues/636，当你指定端点和证书而不是证书时，它基本上设置了一个不正确的DNS。
要确认，请检查

• 您具有允许TCP和UDP上的DNS的连接（NACL和安全组）。对我来说，更好的方法是ssh到集群中，看看它是否解析（nslookup）。如果无法解析（很可能是NACL或SG），请检查节点中的DNS名称服务器是否配置良好。
• 如果您可以在节点中获得名称解析，但不能在pod中获得，请检查/etc/resolv.conf中的名称服务器是否指向您的服务网络中的IP（如果您看到172.20.0.10，则您的服务网络应该是172.20.0.0/24左右）

我也在这类问题上苦苦思索了好几天。
具体来说，我的问题是，我可以VPN到我的私有子网和解决我的管理端点 * 一次 *。也就是说，在星期一（例如）从办公室我可以第一次设置我的VPN并使用kubectl来满足我的需求，但在星期二在家里我可以连接到VPN，但当我运行任何kubectl交互时，我会感到厌烦：

Unable to connect to the server: dial tcp: lookup XXXXX.eks.amazonaws.com on 127.0.0.53:53: read udp 127.0.0.1:39491->127.0.0.53:53: i/o timeout

我想它又能工作了（但我还没有看到它明天是否能在办公室工作）;我所做的更改是Client VPN endpoints->Autorization rules。我添加了一个规则来授权访问包含DNS服务器（VPC CIDR +2）的目标网络，我还明确地将其称为客户端VPN Enpoint本身的DNS服务器。