Openshift/Kubernates kube dns最佳实践(ndots = 5)

Question

我使用Openshift/Kubernates已经有一段时间了，这是我的理解。用于服务到服务通信

• 如果${service-name}位于相同的命名空间中，则使用DNS名称
• 如果来自不同的名称空间(网络连接)，则使用${service-name}.${namespace}.svc.cluster.local的DNS名称。

最近，我被介绍为“我们应该在svc.cluster.local之后添加一个点，使其成为FQDN，以提高DNS查找速度”。做了一些测试，实际上，用点查找要快得多。(~100 dot无点，10 dot有点)

经过一些研究，这是由kubernates的默认dns设置引起的。

sh-4.2$ cat /etc/resolv.conf
search ${namespace}.svc.cluster.local svc.cluster.local cluster.local
nameserver X.X.X.X
options ndots:5

如果dns名称不包含5个点，那么ndots =5将执行本地搜索(顺序)。对于${service-name}.${namespace}.svc.cluster.local，本地搜索将是这样的

1. ${service-name}.${namespace}.svc.cluster.local + ${namespace}.svc.cluster.local //查找失败
2. ${service-name}.${namespace}.svc.cluster.local + svc.cluster.local //查找失败
3. ${service-name}.${namespace}.svc.cluster.local + cluster.local //查找失败
4. ${service-name}.${namespace}.svc.cluster.local //成功查找

对于${service-name}.${namespace}.svc.cluster.local.，本地搜索将是这样的

1. ${service-name}.${namespace}.svc.cluster.local //成功查找

参考文献

1. 链接
2. 如何调试

问题：

1. 既然ndots = 5是kubernetes的默认设置，那么为什么官方没有记录${service-name}.${namespace}.svc.cluster.local.呢？
2. 我们是否应该将所有服务呼叫更改为${service-name}.${namespace}.svc.cluster.local.？有什么潜在的缺点吗？

Answer 1

基于最新的文档这里，它指出我们应该使用${service}.${namespace}从不同的命名空间调用服务，并期望在第二次尝试时解决。

Answer 2

既然ndots = 5是kubernetes的默认设置，那么为什么官方没有记录${service-name}.${namespace}.svc.cluster.local.呢？

这是个很好的问题。我搜索了官方文档，看起来这不是一个有记录的特性。由于这个原因，您可以更好地发布您的怀疑，也可以请求改进文档，这是官方的GitHub Kubernetes DNS站点。

我们是否应该将所有服务呼叫更改为${service-name}.${namespace}.svc.cluster.local.？有什么潜在的缺点吗？

如果它对你很好，而且肯定会提高你的表现，我会说-为什么不呢？我看不出这里有什么潜在的坏处。通过添加最后一个点，您只需省略前面的3次查找，如果您在Service域名中使用${service-name}.${namespace}.svc.cluster.local，那么这些查找无论如何都注定会失败。

根据您描述的查找过程和测试，我想如果您只使用${service-name} (当然只在相同的namespace中使用)，那么dns查找也应该更快、更接近您在使用${namespace}.svc.cluster.local svc.cluster.local cluster.local.时观察到的那些10ms，因为在第一次迭代中它是匹配的。