18

我在 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 解析的任何必要步骤？

非常感谢，丹尼尔

4

6 回答 6

17

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

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

于 2018-12-07T07:41:46.687 回答
10

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

  1. UDP 端口 53 的入口规则
  2. 临时端口上的 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 接收查询还是发回响应。

于 2019-05-22T21:21:42.817 回答
2

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

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

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

于 2021-03-05T01:55:15.907 回答
1

所以我想我已经挣扎了几个小时，忘记了时间，这个问题也是如此。

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

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

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

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

问题链接在这里

谢谢

于 2019-01-01T19:51:49.267 回答
1

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

只是想发布一条关于我们需要做什么来解决我们的问题的说明。注意YMMV和每个人都有不同的环境和分辨率等。

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

参考： Terraform EKS 模块

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 选项集

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

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

于 2019-09-13T18:57:13.663 回答
0

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

事实证明这是由于1.5.4Amazon VPC CNI 版本中的一个错误，更多细节在这里 - https://github.com/aws/amazon-vpc-cni-k8s/issues/641。

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

于 2019-11-14T10:12:26.747 回答