记：k8s内部服务调用连接超时

Posted 2023-04-23

参考技术A 前端时间开发和测试环境遇到一个问题，k8s内部根据服务名称和命名空间访问时连接超时。之间介绍过我们当前的项目架构，相关内容可以参看我的这两篇文章:
kubernetes使用Feign实现服务间调用
从一次k8s容器内域名解析失败了解k8s的DNS策略
当服务之间使用 Fegin 进行访问的时候，我们使用的是 service_name . namespace:port 进行访问的，根据k8s的DNS策略，找到相关的服务并进行路由是没有问题的，但是仍然会出现的服务连接超时的问题。最开始我只是通过最简单粗暴的方式解决，那就是重启服务器，但是这并不能从根本上解决问题。

在搭建k8s集群之后因为后期重新加了一台服务器（服务器A，后面统一使用服务器A代指），而这台服务器和其他服务器的ip网段又不同，所以就怀疑是这台服务器的问题，但是服务间连接超时的问题是偶尔性发生的，而且在这台服务器上通过服务名称和 pod 的ip访问是正常的。所以我感觉还是k8s的网络组件有问题。
查看相关的 pod

这时候发现一个很奇怪的问题，就是一个 calico 节点状态不正确，如下：

定位是哪台服务的：

发现确实是服务器A上的 calico ，个人认为重启应该可以解决，所以就删除了有问题的 pod ，但是重启之后它的状态依然不是 Ready 。另外一个情况也引起了我的注意，就是当出现服务间连接超时的时候，k8s的 coreDNS 恰好会有一个被调度在服务器A上。所以有时候我也会直接删除服务器A上的 coreDNS 以便k8s调度到其他节点上，来解决连接超时的问题。
所以基本上可以肯定就是服务器A部署的网络组件问题，但是一直没时间就一直没有解决这个问题，国庆前正好手头没什么事情，所以决定彻底解决这个问题。查看下服务器A的 calico 日志：

有一段异常信息，如下：

因为自己对k8s了解的也不多，遇到问题只能百度，百度了一下基本上都是说是没有使用真正的网卡的问题，需要修改 calico.yaml :
这里自己走了弯路后来自己才想明白是怎么回事，网上说的修改 calico.yaml 文件，是指部署 calico 时的那个文件。

修改之后重新部署 calico ：

按照上述方法应该就能解决问题了。下面说下我当时的操作（现在回想感觉自己SB）。

因为当时k8s上每个节点都已经部署了 calico ，所以我一开始是想的直接修改服务器A的 calico ，所以我登录到 dashboard ，去修改服务器A上的 calico （对，就是编辑 pod ），但是很遗憾没有生效.......服务A的 calico 依然不是 Ready 状态。
然后我想网上的方案是不是有问题啊，我检查并对比了下各个服务器的网卡，发现服务器A的网卡(ens32)和其他节点网卡(ens196)不同，并且对比网卡详情发现其他服务器：

即自动协商是关闭状态，所以服务器A也关闭自动协商(感觉自己的胆儿有点肥....)：

但是再次查看服务器A的网卡详情没有任何变化(我快要放弃了).....

反正解决不了，我就又返回到 dashboard 页面，随便看了 kube-system 命名空间下的其他信息，一下就看到了 calico-node 的 DeamonSets ，内容和 calico.yaml 差不多（差不多，就改改吧），添加内容：

更新之后再去看服务器A的 calico 居然成了 Ready 状态(我靠...怎么肥死，懵逼ing)。
自己废了那么大劲，折腾半天原来问题在这里....我个人的理解网上的方案是没有问题的，之所以前面修改服务器A上的 calico 不生效，个人猜想会不会是因为 calico 是以 DeamonSets 的运行(k8s小白表示真的不知道怎么回事)。不管怎么样问题算是解决了，虽然不知道为啥，如果有了解的大佬还请给我解释一下，万分感谢......

《Spring Cloud 》Eureka服务调用服务超时重试机制

参考技术A 问题根源有二：
1）：业务耗时时间比较长，超过服务调用超时时间配置，由于Spring Cloud 服务调用超时重试机制默认开启，所以会导致服务被调用了两次。
2）：服务端未做幂等性，导致重复的业务处理。

增大配置超时时间
ribbon.ReadTimeout=10000
ribbon.ConnectTimeout=10000

eureka服务调用重试开关的配置属性:

默认开启。

重试机制：对于连接超时的异常，feign都会触发重试机制，对于读取超时，会根据请求类型判断，如果是GET异常，触发重试；其他异常，不会触发重试。

服务响应超时时间，默认5s，连接的超时时间为2s。

同一实例最大重试次数为1

负载均衡的其他实例的重试次数为2

对所有操作请求都进行重试，默认false，建议不要开启。