问题描述

客户k8s环境，客户的应用访问clusterIP类型的svc比较慢，所以客户直接将svc的类型改成了NodePort，这样会很快。需要解决clusterIP类型时访问慢的问题。

chatGPT的回答

当使用 ClusterIP 访问时，请求会经过 Kubernetes 集群的网络层，然后被转发到相应的 Pod 上。而使用 NodePort 访问时，请求直接通过节点的 IP 地址和指定的端口转发到对应的 Pod 上。因此，NodePort 访问相对于 ClusterIP 访问来说，少了一层网络转发，所以速度会更快一些。如果 ClusterIP 访问速度较慢，可能有以下几个原因需要排查：

网络延迟：检查集群的网络配置，确保网络连接正常，没有丢包或延迟过高的情况。

资源限制：检查 Pod 的资源限制，确保 Pod 分配的 CPU 和内存资源足够满足请求的需求。

负载均衡：检查负载均衡器的配置，确保负载均衡器正常工作，并且后端 Pod 的负载均衡策略合理。

应用性能：检查应用本身的性能，可能是应用代码或数据库查询等操作导致的延迟。

建议按照以上步骤逐一排查，找出导致 ClusterIP 访问慢的具体原因，并进行相应的优化和调整。

所以这就解释了为什么客户使用NodePort非常快的原因了。

排查

找到客户的命名空间的pod，登录pod内部，使用curl测试访问，例如：

time curl app1.devops.svc.cluster.local:8080 

时间确实很慢，需要4秒左右，客户的web应用访问也提现出慢4秒左右。

看到客户的svc名称都包含.svc.cluster.local，怀疑是这个导致寻址慢，直接测试：

time curl app1.devops:8080 

速度很快，故障原因找到。

测试

我在自己的测试环境也进行了测试：

结果确实如图所示，不加.svc.cluster.local的速度最快。

解决

于是我们建议客户不需要添加.svc.cluster.local，问题解决。

无效的排查

1、检查网络插件状态、coredns状态
2、检查coredns的域名解析配置（configmap），正常
3、重启coredns pod，并按客户使用svc的资源数量调整coredns pod的副本数量
4、curl一次ClusterIP，查看coredns日志，发现有[ERBOR] plugin/errors:报错

CC版权： 本篇博文采用《CC 协议》，转载必须注明作者和本文链接