阿尔卑斯知道库伯内特斯的DNS问题吗？

Question

最近，我们在解决“大”DNS查询(当答案大于512米时)时，遇到了一些基于阿尔卑斯图像(节点:12.18.1-阿尔卑斯)的微服务在EKS上的DNS问题。

所以我试着运行这个脚本来测试DNS解析：

var dns = require('dns');
var w3 = dns.lookup('hugedns.test.dziemba.net', function (err, addresses, family) {
  console.log(addresses);
});

为每个图像提供了两个不同的场景

1. node:12.18.1-alpine

• Running我的笔记本电脑上的图像-解析的successfully
• Running - EKS 1.16上的图像-未能resolve

1. node:12.18.1-slim

• Running在我的笔记本上的图像-解析的successfully
• Running，在EKS 1.16上的图像-解析successfully

据我所见，阿尔卑斯正在使用musl (它不支持DNS使用TCP?)库而不是glibc，因为DNS协议使用的是UDP，只有在查询大于512 m时才尝试返回TCP。因此，我的理论是，这是根本原因，但由于它是对我的工作，而在EKS失败让我想知道问题的接力在哪里.

有什么想法吗？

艾克斯诉1.16核心文件:v1.6.6

顺便说一句，这是我的第一篇文章，如果需要什么信息，请告诉我。

Answer 1

是的，已知阿尔卑斯映像在涉及DNS查询的Kubernetes集群中是有问题的。

即使还不清楚该bug是否已在任何当前版本的阿尔卑斯山中得到有效修复，以下是一些相关链接：

• https://github.com/kubernetes-sigs/kind/issues/442
• https://gitlab.alpinelinux.org/alpine/aports/-/issues/9017
• https://github.com/gliderlabs/docker-alpine/issues/476

我在2021年1月的Kubernetes集群中遇到了这个问题，有最新的高山3.12图片，所以我假设它不是固定的。

核心问题似乎是，如果任何响应都是意外的，musl库将停止在/etc/resolv.conf的search指令中指定的可能域中搜索给定的名称(基本上不能清楚地表明无法找到或已经找到FQDN )。

这与库伯内特斯关于豆荚中的名字解析的策略不太协调。

实际上，可以看到，在/etc/resolv.conf名称空间中，pod的典型的example是：

nameserver 10.3.0.10
search example.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

策略是，名称的解析(例如，my-service或www.google.com )将针对search指令中指定的每个域进行测试:这里的示例是FQDN链my-service.example.svc.cluster.local、my-service.svc.cluster.local、my-service.cluster.local、my-service和www.google.com.example.svc.cluster.local、www.google.com.svc.cluster.local、www.google.com.cluster.local、www.google.com。在这里，正确解析的显然是第一链(my-service.example.svc.cluster.local)的第一个FQDN和第二链的最后一个FQDN (www.google.com)。

我们可以看到，这种策略是为了优化集群内部名称的解析，使my-service、my-service.my-namespace或my-service.my-namespace.svc这样的名称能够得到很好的解决。

ndots指令中的options参数定义了名称中的最小点数，以考虑名称实际上是FQDN，因此应该跳过搜索链，以支持直接的DNS解析尝试。使用ndots:2，www.google.com将被视为FQDN，而my-service.my-namespace将遍历搜索链。

考虑到在3个可能的域上使用search选项，由于ndots:5和阿尔卑斯码头中musl库中搜索循环的中断，任何明显的URL都不会被视为FQDN，所有这些都极大地增加了在Kubernetes中运行的码头阿尔卑斯山的主机解析失败的概率。如果您的主机解析是定期运行的某种循环的一部分，您将遇到许多需要处理的失败。

该怎么办？

https://pracucci.com/kubernetes-dns-resolution-ndots-options-and-why-it-may-affect-application-performances.html)

• you可以为您的图像生成一个入口点脚本，以便根据您的需要相应地修改/etc/resolv.conf，例如，如果您不依赖/etc/host的process

• direct版本中的集群的任何内部名称来向已知的IPH 255>H 156移动Ubi或Debian/Ubuntu图像F 258，则cat /etc/resolv.conf | sed -r "s/^(search.*|options.*)/#\1/" > /tmp/resolv && cat /tmp/resolv > /etc/resolv.conf将删除关于search和options的所有内容。

就我个人而言，我是从阿尔卑斯山开始的，就像我们中的很多人一样，在Docker工业化的早期，因为其他完整的操作系统图像非常大。对于Ubuntu或Debian，甚至以Kubernetes为中心的Ubi等以Ubi为中心的计划来说，这种情况已经不再发生了。这就是为什么我通常选择最后一种选择(远离高山图像)。

Answer 2

对于所有的应用程序/吊舱，您需要在高山上安装绑定工具：

apk update && apk add bind-tools

也可以将其添加到您的Dockerfile中：

RUN apk update && apk add bind-tools

​

​

有关更多信息，请查看以下内容：https://github.com/nodejs/docker-node/issues/339

Answer 3

绑定工具只修复了用于DNS查找的shell工具，我们必须从阿尔卑斯的基本映像到Debian或Ubuntu才能使NodeJS在EKS中工作。