1.k8s中service訪問異常的常見問題

1).service沒有正確(que)匹配到后(hou)端的(de)pod標簽

(1).service匹配的label標簽沒(mei)有匹配上(shang)后(hou)面的pod（導致(zhi)訪問不到界(jie)面）

(2).service匹(pi)配(pei)的label標(biao)簽匹(pi)配到后面(mian)其他錯誤的(de)pod（導(dao)致訪問的(de)別的(de)界(jie)面）

2).kube-proxy服務故障導致service無法提供服(fu)務

kube-proxy是什么:

Service為一組相同的pod提供了統一(yi)的入口(kou)，起到負載均衡的效果。Service具(ju)有這樣的功(gong)能，真是kube-proxy的功(gong)勞，kube-proxy是一個代理，安裝在每一個k8s節(jie)點，當我們暴露(lu)一個service的時候，kube-proxy會在iptables中追加一些規(gui)則，為我們實現路由與(yu)負載均衡的功能。

kube-proxy的(de)兩種轉發規則: iptables(DNAT規則轉(zhuan)發到后臺pod)和(he)ipvs

故障現象：

service的標簽選擇器正常(chang)，pod也正常(chang)，但是訪(fang)問service的ip時(shi)，還是代理不到pod，就需要(yao)檢(jian)查kube-proxy組件。

解決(jue)思路：

(1).查(cha)看相應node節點(dian)kube-proxy服(fu)務(wu)是否(fou)正常。

(2).查看相應node節(jie)點上kube-proxy相關日(ri)志，有(you)(you)沒有(you)(you)報錯，資源(yuan)不足，如:cpu/內存/磁(ci)盤

(3)查看相應node節(jie)點(dian)上(shang)系統日志中(zhong)有沒(mei)有關(guan)于kube-proxy的日志(zhi)報錯.

#cat /var/log/messages[kube-proxy] |grep kube-proxy或(huo) kubectl logs pod名 |grep kube-proxy

解決(jue)方(fang)法：

(1).擴容節點(dian)資源，增加服務器(qi)或者(zhe)虛(xu)擬機的cpu和(he)內存。

(2).修改(gai)kube-proxy的yaml中(zhong)的(de)limit資源限制，限制可使用的cpu和內存。

2.k8s中pod刪除(chu)失敗的解決

故(gu)障現象：在k8s中，可(ke)能(neng)會產生很(hen)多垃圾pod，也就是(shi)有些pod雖然是running狀(zhuang)態，可是其所調(diao)度到(dao)的k8s的node節點(dian)已經從k8s集群(qun)刪除(chu)了，但(dan)是pod還(huan)是在這個node上，沒有(you)被驅逐，針對這(zhe)種情況就需(xu)要把(ba)pod刪除。

故障問題(ti)：刪除pod時(shi)候，pod一直處于terminate狀態(tai)，很(hen)長時(shi)間無法刪除。

解決方案：

可以通過如下(xia)方(fang)法添加參數強(qiang)制刪除pod，–force --grace-period=0, grace-period表示(shi)過渡存(cun)活期，默認(ren)30s，在刪(shan)除pod之前運行pod慢慢終(zhong)止(zhi)其上的容(rong)器進程(cheng)，從而優雅(ya)退出，0表示立(li)即終止pod.

#kubectl delete pod pod名 --force --grace-period=0

3.k8s中命(ming)名(ming)空間(jian)的強制刪除(chu)

雖然pod可(ke)以強制刪除(chu)，但是可(ke)能命名空間還是處于terminate狀態，無法刪除。

解決方法：

(1).強制刪除命名空間

#kubectl delete ns 命名空(kong)間(jian) --force --grace-period=0

(2).獲取namespace的json文件，刪除相關(guan)內容

#kubectl get ns 命名(ming)空間 -o json > /root/xx.json

#vim /root/xx.json

刪除spec下的”finalizers”:[ 和”kubernetes” 內容

調用(yong)api-server接口進行刪除：

打開(kai)一(yi)個新(xin)的終(zhong)端，或者(zhe)把下面(mian)的命令放(fang)到(dao)后臺執行(xing): # kubectl proxy --port=8081

調用接口刪除：

#curl -k -H “Content-Type: application/json” -X PUT --data-binary @xx.json

127.0.0.1:8081/api/v1/namespaces/命(ming)名(ming)空間名(ming)/finalize

如(ru)果kubectl get ns 命名空間 -o json的結果中(zhong)”spec”:{}中為空(kong)了，但(dan)是metadata部分還有finalizers字段，需要將里面相關(guan)finalizers的內容(rong)也刪除(chu)。

#kubectl edit ns 命名(ming)空(kong)間

進去后，直(zhi)接刪除相關finalizers的(de)內容即可，保存退出(chu)后，出(chu)入Terminating狀態的ns便沒有了。

4.k8s中跨主(zhu)機連接不通（pod和(he)pod）

1).pause容器(qi)概(gai)念：

Pause容(rong)器(qi)，又叫Infra容(rong)器，Pause容(rong)器對應的鏡像屬于(yu)k8s平臺的一部分，除了pause容器，每個(ge)pod還包含一個(ge)或者(zhe)多個(ge)緊密相關的用戶(hu)業務容器。

2).pause容器的作用(yong)：

(1).pod里的多個(ge)業務容器共(gong)享pause容(rong)器的(de)ip，共享pause容器掛載(zai)的(de)volume，這樣(yang)簡化了(le)業務容器(qi)(qi)之(zhi)(zhi)間(jian)的(de)通信(xin)問題，也解決了(le)容器(qi)(qi)之(zhi)(zhi)間(jian)的(de)問題件共享(xiang)問題。

(2).pod中的(de)容器共享同一個ip地址。故同一個pod中container可(ke)以做到(dao)直接通過(guo)localhost直接通(tong)信。

3).同一(yi)個(ge)節點(dian)多個(ge)pod通信機制(zhi)：

pause容(rong)器(qi)啟動之前，會為容(rong)器(qi)創(chuang)建虛(xu)擬一對ethernet接口，一(yi)個保留在(zai)宿(su)主機vethxxx（插在(zai)網橋上），一個保留在(zai)容器網絡命名(ming)空(kong)間內(nei)，并重命名(ming)為(wei)eth0。兩(liang)個(ge)虛擬接口的兩(liang)端(duan)(duan)，從(cong)一端(duan)(duan)進(jin)入，從(cong)另一端(duan)(duan)出(chu)來。任何pod連接到該(gai)網橋的pod都可以收發數據。

4).跨節點(dian)pod通信機制：

跨(kua)節點pod通信，相(xiang)當于(yu)創(chuang)建一(yi)個(ge)整個(ge)集群公用的 [網橋] ，然后把(ba)集(ji)群中(zhong)所(suo)有的pod連接起來，就(jiu)可(ke)以(yi)通(tong)信(xin)了。

5).跨(kua)主機連接不(bu)通（pod和pod）的故(gu)障排查方(fang)法：

(1).排(pai)查宿主機網絡是否正常(chang)，在宿主機上ping baidu.com,或tcpdump抓(zhua)包看是否丟包.

(2).查看k8s中的網絡插(cha)件(jian)(jian)是(shi)否正(zheng)常，查(cha)看(kan)網絡組件(jian)(jian)calico或(huo)flannel的日志。