我在我的GKE集群中发现了一个奇怪的问题，名称空间间的API调用花费了更长的时间。
- 假设我有两个名称空间
ns-1和ns-2。 - 我在
ns-1中部署了一个API，我们将其命名为api-service - 如果我从X1 M5 N1 X中部署的任何其他应用程序/Pod调用X1 M4 N1 X，大约需要5毫秒。
- 如果我从部署在
ns-2中的应用程序/pod调用api-service，需要大约40毫秒。要从另一个命名空间调用，我使用FQDN -api-service.ns-1.svc.cluster.local - 当我尝试从ns-1
also, using the FQDN -api-service.ns-1.svc.cluster.local '调用api-service时，又需要大约25- 40毫秒。
初看起来像是名称空间之间的通信，或者当您使用FQDN时会增加延迟。
我试着检查文档中的相同内容，但找不到任何提到相同内容的内容。
通常这不应该发生，但我现在一无所知。
任何关于相同的帮助将不胜感激。
注：
- 我正在从两个Pod进行相同的API调用
- 不同pod的响应时间：
//calling from the same namespace (ns-1)
# curl -X POST "http://api-service:8080/hello" -w %{time_connect}:%{time_starttransfer}:%{time_total}
0.004539:0.007073:0.007096
//calling from the same namespace (ns-1)
# curl -X POST "http://api-service.ns1.svc.cluster.local:8080/hello" -w %{time_connect}:%{time_starttransfer}:%{time_total}
0.028735:0.030097:0.030158
//calling from a different namespace (ns-2)
# curl -X POST "http://api-service.ns1.svc.cluster.local:8080/hello" -w %{time_connect}:%{time_starttransfer}:%{time_total}
0.125594:0.163450:0.163519
0.028722:0.030159:0.030221或者是否有人可以为我指出正确的文档。
1条答案
按热度按时间rjee0c151#
根据您的问题，似乎有一个延迟问题，由于名称空间之间的通信，或当您使用FQDN增加延迟。
您是否可以尝试以下过程，这可能有助于减少延迟：
1.如何减少名称空间间通信延迟：
来自k8的DNSCache和来自GCP的DNSCache可能增加了2.5倍，这意味着如果您想减少延迟，它肯定更好。
尝试以下不同配置：
a.启用节点本地DNSCache，如官方k8s documentation中所述。
B.添加DNSCache，如GCP官方documentation中所述。
c.不使用任何DNSCache，仅本机kube-dns
2.如何缩短FQDN延迟：
如果您能够配置应用程序对带有尾随点的主机名进行DNS查询（例如，google.com。）。添加尾随点的原因是，ndots现在应该是默认值，即设置为5。这意味着任何少于5个点的主机名都不会被视为FQDN，并会导致生成更多DNS查询（每个DNS查询大约6个，FQDN包含的点少于5个，因为它将附加搜索域.. svc.cluster.local、.svc.cluster.local、.cluster.local、. c.. internal、和. google. internal.，然后再尝试主机名本身）。如果您没有“无法配置应用程序以进行更改，我们可以尝试的另一个选项是基于每个部署实施特定的DNS配置：
上面将创建一个
ndot值设置为1的resolve.conf。因此，任何主机名中至少有一个圆点将被视为FQDN。这应该会减轻KubeDNS和Node Local DNSCache的压力。