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

一、 原因分析

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

kubectl  get pod -n kube-system 

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

calico-node-c8ht8                              1/1     Running   0               
calico-node-rgr4t                               1/1     Running   0              
calico-node-rjqg4                               0/1     Running   0               
calico-node-vscpn                             1/1     Running   0             
calico-node-zlww6                            1/1     Running   0 

定位是哪台服务的：

kubectl  get pod -n kube-system  -o wide

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

kubectl describe pod calico-node-rjqg4   -n kube-system 

有一段异常信息，如下：

(combined from similar events): Readiness probe failed: calico/node is not ready: BIRD is not ready: BGP not established with ******（服务器ip） 2020-09-28 07:20:34.112 [INFO][63033] health.go 156: Number of node(s) with BGP peering established = 0

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

    - name: CLUSTER_TYPE
      value: k8s,bgp
      ## 添加内容  
    - name: IP_AUTODETECTION_METHOD
      value: "interface=ens.*"
    - name: IP
      value: autodetect

修改之后重新部署calico：

kubectl apply -f calico.yaml

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

二、我的方案

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

Auto-negotiation: off

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

ethtool -s autoneg off

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

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

    - name: CLUSTER_TYPE
      value: k8s,bgp
    ## 添加内容
    - name: IP_AUTODETECTION_METHOD
      value: "interface=ens.*"
    - name: IP
      value: autodetect

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