分类:笔记 日期:2024-01-29 作者:caocaofff 浏览:592
客户k8s环境,客户的应用访问clusterIP类型的svc比较慢,所以客户直接将svc的类型改成了NodePort,这样会很快。需要解决clusterIP类型时访问慢的问题。
当使用 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 协议》,转载必须注明作者和本文链接