第1个回答 2022-07-29
前端时间开发和测试环境遇到一个问题，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小白表示真的不知道怎么回事)。不管怎么样问题算是解决了，虽然不知道为啥，如果有了解的大佬还请给我解释一下，万分感谢......