解决k8s集群内部应用使用clusterIP类型的service域名访问慢的问题

分类:笔记 日期:2024-01-29 作者:caocaofff 浏览:592

问题描述

客户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 

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

测试

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

Dingtalk_20240130083548.jpg

结果确实如图所示,不加.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 协议》,转载必须注明作者和本文链接

评论 (暂无评论)

发表评论

昵称:  
邮箱:  
网址: