Openshift/Kubernates kube dns 最佳实践 (ndots = 5)
Openshift/Kubernates kube dns best practise (ndots = 5)
我使用Openshift/Kubernates有一段时间了，这是我的理解。
用于服务间通信
- 如果它们在同一命名空间下，则使用
${service-name} 的 DNS 名称
- 如果它们来自不同的命名空间（已加入网络），则使用
${service-name}.${namespace}.svc.cluster.local 的 DNS 名称
最近有人介绍我的主题是“我们应该在 svc.cluster.local 之后添加一个点以使其成为 FQDN，以获得更好的 DNS 查找速度”。做了一些测试，确实使用点进行查找要快得多。 （~100ms 没有点，10ms 有点）
经过一番研究，这是由 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的情况下，本地搜索将是这样的
${service-name}.${namespace}.svc.cluster.local + ${namespace}.svc.cluster.local // 查找失败${service-name}.${namespace}.svc.cluster.local + svc.cluster.local // 查找失败${service-name}.${namespace}.svc.cluster.local + cluster.local // 查找失败${service-name}.${namespace}.svc.cluster.local // 成功查找
对于${service-name}.${namespace}.svc.cluster.local.，本地搜索也是如此
${service-name}.${namespace}.svc.cluster.local // 成功查找
参考资料
问题：
- 既然
ndots = 5是kubernetes的默认设置，为什么官方没有记录${service-name}.${namespace}.svc.cluster.local.？
- 我们是否应该将所有服务调用更改为
${service-name}.${namespace}.svc.cluster.local.？有什么潜在的缺点吗？
Since the ndots = 5 is the default setting for kubernetes, why
${service-name}.${namespace}.svc.cluster.local. is not documented on
the official side ?
好吧，这是一个非常好的问题。我搜索了官方文档，看起来这不是一个记录的功能。出于这个原因，发布您的疑问和改进文档的请求更好的地方是 Kubernetes DNSKubernetes DNSGitHub 的官方网站 Kubernetes DNS.
Should we change all service call to
${service-name}.${namespace}.svc.cluster.local. ? any potential
downsides ?
如果它适合您并且确实提高了性能，我会说 - 为什么不呢？ 我在这里看不到任何潜在的缺点。通过添加最后一个点，如果您以 ${service-name}.${namespace}.svc.cluster.local
的形式使用 Service 域名，那么您只是省略了那些注定要失败的前 3 个查找
从你描述的查找过程和你的测试推断，我猜如果你只使用${service-name}（当然只在同一个namespace内），dns查找也应该更快更接近那些 10ms 你在使用 ${namespace}.svc.cluster.local svc.cluster.local cluster.local. 时观察到的，因为它在第一次迭代中就匹配了。
根据最新文档here，它声明我们应该使用${service}.${namespace}从不同的命名空间调用服务并期望在第二次尝试时解析
我使用Openshift/Kubernates有一段时间了，这是我的理解。 用于服务间通信
- 如果它们在同一命名空间下，则使用
${service-name}的 DNS 名称 - 如果它们来自不同的命名空间（已加入网络），则使用
${service-name}.${namespace}.svc.cluster.local的 DNS 名称
最近有人介绍我的主题是“我们应该在 svc.cluster.local 之后添加一个点以使其成为 FQDN，以获得更好的 DNS 查找速度”。做了一些测试，确实使用点进行查找要快得多。 （~100ms 没有点，10ms 有点）
经过一番研究，这是由 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的情况下，本地搜索将是这样的
${service-name}.${namespace}.svc.cluster.local+${namespace}.svc.cluster.local// 查找失败${service-name}.${namespace}.svc.cluster.local+svc.cluster.local// 查找失败${service-name}.${namespace}.svc.cluster.local+cluster.local// 查找失败${service-name}.${namespace}.svc.cluster.local// 成功查找
对于${service-name}.${namespace}.svc.cluster.local.，本地搜索也是如此
${service-name}.${namespace}.svc.cluster.local// 成功查找
参考资料
问题：
- 既然
ndots = 5是kubernetes的默认设置，为什么官方没有记录${service-name}.${namespace}.svc.cluster.local.？ - 我们是否应该将所有服务调用更改为
${service-name}.${namespace}.svc.cluster.local.？有什么潜在的缺点吗？
Since the
ndots = 5is the default setting for kubernetes, why${service-name}.${namespace}.svc.cluster.local.is not documented on the official side ?
好吧，这是一个非常好的问题。我搜索了官方文档，看起来这不是一个记录的功能。出于这个原因，发布您的疑问和改进文档的请求更好的地方是 Kubernetes DNSKubernetes DNSGitHub 的官方网站 Kubernetes DNS.
Should we change all service call to
${service-name}.${namespace}.svc.cluster.local.? any potential downsides ?
如果它适合您并且确实提高了性能，我会说 - 为什么不呢？ 我在这里看不到任何潜在的缺点。通过添加最后一个点，如果您以 ${service-name}.${namespace}.svc.cluster.local
Service 域名，那么您只是省略了那些注定要失败的前 3 个查找
从你描述的查找过程和你的测试推断，我猜如果你只使用${service-name}（当然只在同一个namespace内），dns查找也应该更快更接近那些 10ms 你在使用 ${namespace}.svc.cluster.local svc.cluster.local cluster.local. 时观察到的，因为它在第一次迭代中就匹配了。
根据最新文档here，它声明我们应该使用${service}.${namespace}从不同的命名空间调用服务并期望在第二次尝试时解析