Question

我在VPC中有一个EKS群集设置。工作程序节点在专用子网中启动。我可以成功部署Pod和服务。

但是，我无法从Pod内执行DNS解析。（它在容器外部的工作节点上工作正常。）

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

服务器：172.20.0.10 地址1：172.20.0.10

nslookup：无法解析“ kubernetes.default”

当我在所有公共VPC中启动群集时，我没有这个问题。我是否从私有子网中缺少DNS解析的任何必要步骤？

非常感谢，丹尼尔

Answer 1

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

这个过程对我来说尤其令人困惑，因为我的一个Pod实际上一直在工作，因为（我认为？）它恰好与kubernetes DNS解析器位于同一区域。

Answer 2

要详细说明@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接收查询还是将响应发送回。

Answer 3

关于：来自Pod的AWS EKS Kube集群和Route53内部/私有Route53查询

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

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

参考： Terraform EKS module

CoreDNS更改：我们有一个用于内部专用的DNS中继，因此我们需要修改coredns configmap并添加dns中继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"]

ref：AWS DHCP Option Sets

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

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

Answer 4

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

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

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

Answer 5

所以我想了几个小时，因为时间的流逝以及这个问题。

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

我经历了amazon-vpc-cni-k8s并找到了解决方案。

我们必须对aws-node守护程序集AWS_VPC_K8S_CNI_EXTERNALSNAT=true的环境变量进行设置。

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

问题链接为here

谢谢

Answer 6

我们遇到了类似的问题，其中某些吊舱的DNS解析超时，但是重新创建吊舱几次可以解决该问题。同样，不是给定节点上的每个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

在专用子网中运行时，AWS EKS上的DNS问题

6 个答案: