1.k8s中的網絡(luo)通信(xin)類型

K8s中的(de)網絡是非常重要(yao)的(de)，整個k8s集群(qun)的(de)通(tong)信調度都(dou)是通(tong)過(guo)網(wang)絡插(cha)件實現的(de)。

網絡通(tong)信主要有以下幾(ji)種(zhong):

1).容器間的通信： 同一個pod內(nei)的(de)多個容器(qi)間的(de)通信。

2).pod通(tong)信: 從一(yi)個pod的ip到另一個pod的ip。

3).pod與service通信： pod的ip到cluster ip。

4).外部通(tong)信(xin): service與集群外部客戶端的通信。

2.k8s中(zhong)的網絡插件和各自特點

1).常用的網絡插(cha)件：calico、flannel

(1).calico 既能夠提(ti)供ip,又能夠(gou)配置網絡(luo)策(ce)略

提(ti)供ip: 給pod提供(gong)ip地址

配置網絡策略：指定某一個pod允許哪一個網(wang)段(duan)的ip訪問，限制哪個網段能訪問,哪個不能.

(2).flannel： 也能夠(gou)提供ip，但不能(neng)配置網絡策略。

2).網絡插件哪個性能(neng)好(hao)？

calico和flannel的性能差(cha)不多，因為flannel支持很多種后(hou)端模(mo)式，默認(ren)是vxlan疊加的(de)網絡模式，還(huan)有(you)一個Director routing（直接路由模式）、host-gw（以宿主機充(chong)當網(wang)關）模式,

calico的優勢在于能(neng)配(pei)置網絡策略。如果論(lun)性能(neng)，flannel的直(zhi)接路由(you)模式和calico性能(neng)差不多。

3.pod網(wang)絡連接超時的幾(ji)種情況(kuang)和排查思路

1).pod網(wang)絡連接超時(shi)的幾種(zhong)情(qing)況：

(1).pod和pod連接(jie)超時

(2).pod和虛擬主機上的服務器連接超時

(3).pod和云(yun)主機或外網連接超時

2).排查思路：

(1).pod和pod連(lian)接超時：

查看(kan)calico或flannel是否是running狀(zhuang)態，查(cha)看日志提取重要信息。（網絡層(ceng)面）

(2).pod和(he)虛(xu)擬(ni)主(zhu)機上的服(fu)務器連(lian)接超時：

檢查pod網絡(luo)，測試pod是否可(ke)以ping通同網段(duan)其他(ta)pod的ip。（pod層面）

(3).pod和外網連接(jie)超(chao)時:

檢查物(wu)理網絡，測試ping www.baidu.com或其他pod的ip,可以抓(zhua)包測試(shi)有(you)無異常(chang),通(tong)過抓包修改內核參數（物理機(ji)層面）

當(dang)pod內部ping不通外網,如(ru)：www.baidu.com

解題思路(lu): centos系統中

查看(kan)/etc/sys/net/bridge/bridge-nf-call-iptables的值是(shi)不是(shi)1，若不是則修(xiu)改成1.(開啟橋接模式)

當pod中連接集群之(zhi)外(wai)的數據庫超時：

解題思路(lu)：

(1).檢查pod配置數(shu)據(ju)庫地(di)址是(shi)否正(zheng)確(que)

(2).檢查網絡(luo)狀態(tai)，進(jin)入(ru)到容器對數據(ju)庫ip地址telnet測(ce)試端(duan)口

(3).檢查數據庫是不是拒(ju)絕(jue)pod網段ip訪(fang)問，是否已經開放(fang)了訪(fang)問權限

(4).檢查(cha)是否出現慢查(cha)詢和數據庫連接數問題

4.訪問pod的ip:端口(kou)或(huo)者service時(shi)候顯示超時(shi)的故障(zhang)排查

處理思路和(he)故障現(xian)象:

用tcpdump在相應(ying)宿(su)主機上抓包(bao),可以顯(xian)示發送了大量重復的SYN數據(ju)包,但是沒有收到ack.

診斷: 檢(jian)查ipv4是(shi)否開啟. #vim /etc/sysctl.conf 添加或(huo)修改: net.ipv4.ip_forward=1,sysctl -p生效

5.pod的生(sheng)命周期階段狀態(tai)劃(hua)分

(1).pending: 掛起狀態，表示(shi)pod已經(jing)開始創建，內(nei)部的(de)容器(qi)正在創建，包括(kuo)拉取鏡(jing)像、調度到node節點、可能需要一段時間(jian)。

(2).Running： 運行狀態,pod成(cheng)功創建(jian)并且正常調度(du)到node節點,里面的容器已經被創建了(le)。

(3).Teminated: 終止狀態。

6.Pod的狀態是(shi)running，但是容器已經退出的幾種情況

1).pod是(shi)running，容(rong)器成功(gong)exit.

2).pod是running, 容器OOM退出(內存泄(xie)露的退出),容器(qi)自啟(qi)拉取,pod持(chi)續保持(chi)running.

7.coredns或者kube-dns經常重啟和報(bao)錯的故障(zhang)

1).故障現象:

在k8s中部署服務(wu)(wu)，服務(wu)(wu)之間無法(fa)通過dns解析，coredns一直處(chu)于(yu)CrashLoopBackOff狀態，查看日(ri)志，報錯如(ru)下: Loop (127.0.0.1:44222 -> :53) detected for zone。

2).解決思(si)路：

coredns主(zhu)要和相(xiang)關node節點的宿主機(ji)上dns文件resolv.conf打交(jiao)道，會(hui)讀(du)取宿主機的/etc/resolv.conf中的nameserver內容,查詢resolv.conf文件，如(ru)果(guo)里面存在本地回(hui)環(huan)，如(ru):127.0.0.1或127.0.0.53，那么(me)就容易造成死循環。

3).解(jie)決步(bu)驟:

(1).修改相關node節點(dian)宿主機的resolv.conf文(wen)件，將(jiang)nameserver臨時改成114.114.114.114;

(2).之后(hou),編(bian)輯coredns相關的(de)deployment的yaml文件，將(jiang)副本數(shu)改為0,停止已經啟動(dong)的coredns 的pod。

(3).再編輯coredns相關的deployment的yaml文件，將副本數(shu)改(gai)為2或原(yuan)來的數量,這樣會觸(chu)發coredns重新讀取系(xi)統(tong)配置(zhi)，此時(shi)服務的狀態為running

上述一般能解決該問(wen)題(ti)。

總結:先將宿主機的dns文(wen)件/etc/resolv.conf的(de)dns修改，然后重建coredns的pod，新(xin)建的pod就會重新讀取宿(su)主機上的/etc/resolv.conf文件(jian)。

8.k8s中calico或(huo)flannel網絡插(cha)件(jian)的pod會掛載相應(ying)node節點宿主(zhu)機本地dns文件案例(li)

網絡(luo)插件(jian)pod和coredns的pod里會掛(gua)載宿主機的dns文件，應用(yong)pod不會。

#cat /etc/resolv.conf #查看宿主機本地的(de)dns文件

#Generated by NetworkManager

nameserver 192.168.5.200

#kubectl get pod -n kube-system -o wide |grep calico #查看(kan)calico網絡的pod（也(ye)可flannel）

calico-kube-controllers-84445dd79f-7wjlk 1/1 Running 3 182d 100.80.33.27 dev-core-master-6-51

calico-node-6rx6m 1/1 Running 10 132d 192.168.6.76 dev-core-node-6-76

calico-node-84hbx 1/1 Running 6 286d 192.168.6.51 dev-core-master-6-51

calico-node-8mcv7 1/1 Running 7 286d 192.168.6.52 dev-core-master-6-52

…

#kubectl exec -it calico-node-84hbx bash -n kube-system – cat /etc/resolv.conf #查看網絡插件pod的dns文(wen)件

nameserver 192.168.5.200

#kubectl get pod -n dev00-th-ffm -o wide |grep wms-boss

wms-boss-api-5b547957fc-hpdcv 1/1 Running 0 27h 100.105.200.204 dev-ard-node-7-93

wms-boss-ui-b85d49595-7h27c 1/1 Running 0 27h 100.105.200.226 dev-ard-node-7-93

#kubectl exec -it wms-boss-api-5b547957fc-hpdcv -n dev00-th-ffm – cat /etc/resolv.conf |grep nameserver #普通pod

nameserver 10.96.0.10

#kubectl exec -it wms-boss-ui-b85d49595-7h27c -n dev00-th-ffm – cat /etc/resolv.conf |grep nameserver

nameserver 10.96.0.10

coredns的pod也會掛載本地的/etc/resolv.conf文(wen)件，看看這個(ge)文(wen)件里的nameserver是不是114.114.114.114

9.pod之間，跨主機通信中斷的故障

k8s中pod有調(diao)度(du)到(dao)node1節點，有(you)調(diao)度到node2節點，pod之(zhi)間跨主機通信中斷的錯(cuo)誤.

1).故(gu)障(zhang)現象(xiang)：

在k8s集(ji)群(qun)部(bu)署pod后，pod之間無法跨節點(dian)訪問。登錄到一個node節點的pod，ping另(ling)一個node節點(dian)的pod，報錯：無路由，No route to host。

2).排查思路：

查看網絡插件如calico或flannel插件的(de)pod日(ri)志，如(ru)果(guo)發下pod網段和物理機網段重合，則需(xu)要(yao)修改pod網(wang)段的ip地址(zhi),不(bu)能讓pod網段的ip和宿主機網段的(de)ip網段重合。

3).若pod網(wang)段和物理(li)機網(wang)段重合,導(dao)致的網絡(luo)故障(zhang)，解決步驟(zou)如下：

(1).# kubectl get ippool default-ipv4-ippool -o yaml > default-ipv4-ippool.yaml #導出yaml

(上面default-ipv4-ippool是集(ji)群中默認的名字(zi))

(2).# vim default-ipv4-ippool.yaml #修改pod的(de)網(wang)段(duan)為新(xin)的(de)和宿主(zhu)機不(bu)同(tong)的(de)網(wang)段(duan)

………

spec:

blockSize: 26

cidr: 100.64.0.0/10

ipipMode: Always

(3).# kubectl delete -f default-ipv4-ippool.yaml #刪除現(xian)有ip pool

(4).# kubectl apply -f default-ipv4-ippool.yaml #創建新的ip pool

(5)然(ran)后依次(ci)刪(shan)除calico或flannel網絡(luo)pod

10.k8s集群內部域名解析(xi)困難故障

1). k8s的pod容器(qi)內部(bu)無法解析集群外(wai)的域名

安裝coredns后，容(rong)器(qi)內部無法解析集群外的域名。

解決思路(lu)：

查看(kan)coredns是否正常運行(xing)

查(cha)看coredns日志

查(cha)看coredns會(hui)掛(gua)載本地的(de)/etc/resolv.conf文件，看看這個文件里的nameserver是(shi)不是(shi)114.114.114.114

2).公司的k8s的基(ji)礎服務mysql或redis是基(ji)于域名訪問的，但是應用pod訪問基礎服(fu)務的域(yu)名時報(bao)錯dns超時相(xiang)關的故障

解決思路：

(1).出現k8s內部域名解析問(wen)題，最多的(de)就是查看pod內部(bu)resolv.conf文件是否有問題，需(xu)要(yao)先登錄pod查看resolv.conf有(you)沒有(you)問題(ti)。

(2).如果(guo)pod的內(nei)部resov.conf文件沒有問題, 嘗試(shi)ping 基礎服務的全(quan)域名(如：redis.svc.cluster.local)，可能是(shi)跨(kua)命(ming)名空間等，需要用全域名，如果全域名能ping通，在yaml文(wen)件(jian)里配置域名為(wei)全域名地址。