前端時(shí)間開(kāi)發(fā)和測(cè)試環(huán)境遇到一個(gè)問(wèn)題，k8s內(nèi)部根據(jù)服務(wù)名稱和命名空間訪問(wèn)時(shí)連接超時(shí)。之間介紹過(guò)我們當(dāng)前的項(xiàng)目架構(gòu)，相關(guān)內(nèi)容可以參看我的這兩篇文章:
kubernetes使用Feign實(shí)現(xiàn)服務(wù)間調(diào)用
從一次k8s容器內(nèi)域名解析失敗了解k8s的DNS策略
當(dāng)服務(wù)之間使用Fegin進(jìn)行訪問(wèn)的時(shí)候，我們使用的是service_name.namespace:port進(jìn)行訪問(wèn)的，根據(jù)k8s的DNS策略，找到相關(guān)的服務(wù)并進(jìn)行路由是沒(méi)有問(wèn)題的，但是仍然會(huì)出現(xiàn)的服務(wù)連接超時(shí)的問(wèn)題。最開(kāi)始我只是通過(guò)最簡(jiǎn)單粗暴的方式解決，那就是重啟服務(wù)器，但是這并不能從根本上解決問(wèn)題。
一、 原因分析
在搭建k8s集群之后因?yàn)楹笃谥匦录恿艘慌_(tái)服務(wù)器（服務(wù)器A，后面統(tǒng)一使用服務(wù)器A代指），而這臺(tái)服務(wù)器和其他服務(wù)器的ip網(wǎng)段又不同，所以就懷疑是這臺(tái)服務(wù)器的問(wèn)題，但是服務(wù)間連接超時(shí)的問(wèn)題是偶爾性發(fā)生的，而且在這臺(tái)服務(wù)器上通過(guò)服務(wù)名稱和pod的ip訪問(wèn)是正常的。所以我感覺(jué)還是k8s的網(wǎng)絡(luò)組件有問(wèn)題。
查看相關(guān)的pod
kubectl get pod -n kube-system
這時(shí)候發(fā)現(xiàn)一個(gè)很奇怪的問(wèn)題，就是一個(gè)calico節(jié)點(diǎn)狀態(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
定位是哪臺(tái)服務(wù)的：
kubectl get pod -n kube-system -o wide
發(fā)現(xiàn)確實(shí)是服務(wù)器A上的calico，個(gè)人認(rèn)為重啟應(yīng)該可以解決，所以就刪除了有問(wèn)題的pod，但是重啟之后它的狀態(tài)依然不是Ready。另外一個(gè)情況也引起了我的注意，就是當(dāng)出現(xiàn)服務(wù)間連接超時(shí)的時(shí)候，k8s的coreDNS恰好會(huì)有一個(gè)被調(diào)度在服務(wù)器A上。所以有時(shí)候我也會(huì)直接刪除服務(wù)器A上的coreDNS以便k8s調(diào)度到其他節(jié)點(diǎn)上，來(lái)解決連接超時(shí)的問(wèn)題。
所以基本上可以肯定就是服務(wù)器A部署的網(wǎng)絡(luò)組件問(wèn)題，但是一直沒(méi)時(shí)間就一直沒(méi)有解決這個(gè)問(wèn)題，國(guó)慶前正好手頭沒(méi)什么事情，所以決定徹底解決這個(gè)問(wèn)題。查看下服務(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
因?yàn)樽约簩?duì)k8s了解的也不多，遇到問(wèn)題只能百度，百度了一下基本上都是說(shuō)是沒(méi)有使用真正的網(wǎng)卡的問(wèn)題，需要修改calico.yaml:
這里自己走了彎路后來(lái)自己才想明白是怎么回事，網(wǎng)上說(shuō)的修改calico.yaml文件，是指部署calico時(shí)的那個(gè)文件。
- 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)該就能解決問(wèn)題了。下面說(shuō)下我當(dāng)時(shí)的操作（現(xiàn)在回想感覺(jué)自己SB）。
二、我的方案
因?yàn)楫?dāng)時(shí)k8s上每個(gè)節(jié)點(diǎn)都已經(jīng)部署了calico，所以我一開(kāi)始是想的直接修改服務(wù)器A的calico，所以我登錄到dashboard，去修改服務(wù)器A上的calico（對(duì)，就是編輯pod），但是很遺憾沒(méi)有生效.......服務(wù)A的calico依然不是Ready狀態(tài)。
然后我想網(wǎng)上的方案是不是有問(wèn)題啊，我檢查并對(duì)比了下各個(gè)服務(wù)器的網(wǎng)卡，發(fā)現(xiàn)服務(wù)器A的網(wǎng)卡(ens32)和其他節(jié)點(diǎn)網(wǎng)卡(ens196)不同，并且對(duì)比網(wǎng)卡詳情發(fā)現(xiàn)其他服務(wù)器：
Auto-negotiation: off
即自動(dòng)協(xié)商是關(guān)閉狀態(tài)，所以服務(wù)器A也關(guān)閉自動(dòng)協(xié)商(感覺(jué)自己的膽兒有點(diǎn)肥....)：
ethtool -s autoneg off
但是再次查看服務(wù)器A的網(wǎng)卡詳情沒(méi)有任何變化(我快要放棄了).....
反正解決不了，我就又返回到dashboard頁(yè)面，隨便看了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)。
自己廢了那么大勁，折騰半天原來(lái)問(wèn)題在這里....我個(gè)人的理解網(wǎng)上的方案是沒(méi)有問(wèn)題的，之所以前面修改服務(wù)器A上的calico不生效，個(gè)人猜想會(huì)不會(huì)是因?yàn)?code>calico是以DeamonSets的運(yùn)行(k8s小白表示真的不知道怎么回事)。不管怎么樣問(wèn)題算是解決了，雖然不知道為啥，如果有了解的大佬還請(qǐng)給我解釋一下，萬(wàn)分感謝......
