記：k8s內(nèi)部服務(wù)調(diào)用連接超時

前端時間開發(fā)和測試環(huán)境遇到一個問題，k8s內(nèi)部根據(jù)服務(wù)名稱和命名空間訪問時連接超時怜森。之間介紹過我們當(dāng)前的項目架構(gòu)，相關(guān)內(nèi)容可以參看我的這兩篇文章:
kubernetes使用Feign實現(xiàn)服務(wù)間調(diào)用
 從一次k8s容器內(nèi)域名解析失敗了解k8s的DNS策略
當(dāng)服務(wù)之間使用Fegin進(jìn)行訪問的時候，我們使用的是service_name.namespace:port進(jìn)行訪問的，根據(jù)k8s的DNS策略针余，找到相關(guān)的服務(wù)并進(jìn)行路由是沒有問題的饲鄙，但是仍然會出現(xiàn)的服務(wù)連接超時的問題凄诞。最開始我只是通過最簡單粗暴的方式解決，那就是重啟服務(wù)器忍级，但是這并不能從根本上解決問題帆谍。

一、原因分析

在搭建k8s集群之后因為后期重新加了一臺服務(wù)器（服務(wù)器A轴咱，后面統(tǒng)一使用服務(wù)器A代指）汛蝙，而這臺服務(wù)器和其他服務(wù)器的ip網(wǎng)段又不同烈涮，所以就懷疑是這臺服務(wù)器的問題，但是服務(wù)間連接超時的問題是偶爾性發(fā)生的窖剑，而且在這臺服務(wù)器上通過服務(wù)名稱和pod的ip訪問是正常的坚洽。所以我感覺還是k8s的網(wǎng)絡(luò)組件有問題。
查看相關(guān)的pod

kubectl  get pod -n kube-system

這時候發(fā)現(xiàn)一個很奇怪的問題西土，就是一個calico節(jié)點狀態(tài)不正確讶舰，如下：

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

定位是哪臺服務(wù)的：

kubectl  get pod -n kube-system  -o wide

發(fā)現(xiàn)確實是服務(wù)器A上的calico，個人認(rèn)為重啟應(yīng)該可以解決需了，所以就刪除了有問題的pod跳昼，但是重啟之后它的狀態(tài)依然不是Ready。另外一個情況也引起了我的注意肋乍，就是當(dāng)出現(xiàn)服務(wù)間連接超時的時候鹅颊，k8s的coreDNS恰好會有一個被調(diào)度在服務(wù)器A上。所以有時候我也會直接刪除服務(wù)器A上的coreDNS以便k8s調(diào)度到其他節(jié)點上墓造，來解決連接超時的問題堪伍。
所以基本上可以肯定就是服務(wù)器A部署的網(wǎng)絡(luò)組件問題，但是一直沒時間就一直沒有解決這個問題觅闽，國慶前正好手頭沒什么事情杠娱，所以決定徹底解決這個問題。查看下服務(wù)器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 ******（服務(wù)器ip） 2020-09-28 07:20:34.112 [INFO][63033] health.go 156: Number of node(s) with BGP peering established = 0

因為自己對k8s了解的也不多摊求，遇到問題只能百度，百度了一下基本上都是說是沒有使用真正的網(wǎng)卡的問題刘离，需要修改calico.yaml:
這里自己走了彎路后來自己才想明白是怎么回事室叉，網(wǎng)上說的修改calico.yaml文件，是指部署calico時的那個文件硫惕。

    - name: CLUSTER_TYPE
      value: k8s,bgp
      ## 添加內(nèi)容  
    - name: IP_AUTODETECTION_METHOD
      value: "interface=ens.*"
    - name: IP
      value: autodetect

修改之后重新部署calico：

kubectl apply -f calico.yaml

按照上述方法應(yīng)該就能解決問題了茧痕。下面說下我當(dāng)時的操作（現(xiàn)在回想感覺自己SB）。

二恼除、我的方案

因為當(dāng)時k8s上每個節(jié)點都已經(jīng)部署了calico踪旷，所以我一開始是想的直接修改服務(wù)器A的calico，所以我登錄到dashboard豁辉，去修改服務(wù)器A上的calico（對令野，就是編輯pod），但是很遺憾沒有生效.......服務(wù)A的calico依然不是Ready狀態(tài)徽级。
然后我想網(wǎng)上的方案是不是有問題啊气破，我檢查并對比了下各個服務(wù)器的網(wǎng)卡，發(fā)現(xiàn)服務(wù)器A的網(wǎng)卡(ens32)和其他節(jié)點網(wǎng)卡(ens196)不同餐抢，并且對比網(wǎng)卡詳情發(fā)現(xiàn)其他服務(wù)器：

Auto-negotiation: off

即自動協(xié)商是關(guān)閉狀態(tài)现使，所以服務(wù)器A也關(guān)閉自動協(xié)商(感覺自己的膽兒有點肥....)：

ethtool -s autoneg off

但是再次查看服務(wù)器A的網(wǎng)卡詳情沒有任何變化(我快要放棄了).....

反正解決不了低匙，我就又返回到dashboard頁面，隨便看了kube-system命名空間下的其他信息碳锈，一下就看到了calico-node的DeamonSets顽冶，內(nèi)容和calico.yaml差不多（差不多，就改改吧）售碳，添加內(nèi)容：

    - name: CLUSTER_TYPE
      value: k8s,bgp
    ## 添加內(nèi)容
    - name: IP_AUTODETECTION_METHOD
      value: "interface=ens.*"
    - name: IP
      value: autodetect

更新之后再去看服務(wù)器A的calico居然成了Ready狀態(tài)(我靠...怎么肥死渗稍，懵逼ing)。
自己廢了那么大勁团滥，折騰半天原來問題在這里....我個人的理解網(wǎng)上的方案是沒有問題的竿屹，之所以前面修改服務(wù)器A上的calico不生效，個人猜想會不會是因為calico是以DeamonSets的運行(k8s小白表示真的不知道怎么回事)灸姊。不管怎么樣問題算是解決了拱燃，雖然不知道為啥，如果有了解的大佬還請給我解釋一下力惯，萬分感謝......

記：k8s內(nèi)部服務(wù)調(diào)用連接超時

一、 原因分析

二恼除、我的方案

一、原因分析