K8S故障處理指南：網絡問題排查思路

1. 前言

對于私有化環境，客戶的網絡架構，使用的云平臺存在著各種差異，K8S網絡可能會出現各種問題，此文著重講解遇到此種問題的排查方法和思路，不會涉及相關網絡底層技術描述.

環境說明

由于我們的k8s網絡組件默認使用了flannel,這里描述的集群網絡，均為flannel。但如果你使用了其他CNI組件，依然可以參考此文章的排查思路.

2.?異常場景

如何判斷k8s集群網絡出現異常？

當集群出現pods大量異常，日志顯示dns解析失敗，或者節點間網絡連接失敗等，即可判斷是集群網絡異常

我們可以通過如下幾種方式進行排查。當任何一種方式的結果非預期內，則確認k8s集群網絡出現異常

2. 排查步驟

測試節點互ping

可以按照如下步驟操作

查詢node名稱,podcidr,address并打印

[root@localhost?~]#?kubectl?get?nodes?-o?jsonpath='{range?.items[*]}[name:{.metadata.name}?,?podCIDR:{.spec.podCIDR}?,?ipaddr:{.status.addresses[0].address}]{"\n"}?{end}'
[name:10.28.87.59?,?podCIDR:172.27.1.0/24?,?ipaddr:10.28.87.59]
[name:10.28.87.60?,?podCIDR:172.27.0.0/24?,?ipaddr:10.28.87.60]
[name:10.28.87.61?,?podCIDR:172.27.2.0/24?,?ipaddr:10.28.87.61]
[name:10.28.87.62?,?podCIDR:172.27.4.0/24?,?ipaddr:10.28.87.62]
[name:10.28.87.63?,?podCIDR:172.27.3.0/24?,?ipaddr:10.28.87.63]
[name:10.28.87.64?,?podCIDR:172.27.5.0/24?,?ipaddr:10.28.87.64]

此命令需要在所有節點下執行，可在部署機器上使用ansible調用使用上述命令獲取到的CIDR地址，進行ping操作,seq根據節點數量進行設置

從上面結果可以看到共6個K8S節點，子網分別是172.27.0-172.27.5子網段。

使用下邊shell腳本測試pod子網，通的話打印up

[root@localhost?~]#?for?ip?in?$(seq?0?5);do?ping?-c2?-W1?-q?172.27.$ip.1?2>1?&>/dev/null?&&?echo?"172.27.$ip.1?up"?||?echo?"172.27.$ip.1?down";done
172.27.0.1?up
172.27.1.1?up
172.27.2.1?up
172.27.3.1?up
172.27.4.1?up
172.27.5.1?up

非預期結果: 出現某個節點固定的ping異常，即認為對應節點間vxlan通信異常，檢查對應節點的網絡即可

tcp,udp查詢

需要在所有節點上執行，可在一臺機器上使用ansible調用

ping操作屬于三層操作，由于某些環境會禁ping,因此我們可以使用如下命令進行確認

使用http請求訪問coredns metrics接口，狀態碼為200時正常,狀態碼000代表網絡異常不通

[root@CentOS76?~]#?kubectl?get?pods?-n?kube-system?-o?wide?|?grep?coredns?|?awk?'{print?$6}'?|?xargs?-i??curl?--connect-timeout?2?-o?/dev/null?-s?-w?"%{http_code}\n"?http://{}:9153/metrics
200
200
200
200
200
200

使用dns查詢kubernetes.default地址。有返回則代表正常

[root@localhost?~]#?kubectl?get?pods?-n?kube-system?-o?wide?|?grep?coredns?|?awk?'{print?$6}'?|?xargs?-l?nslookup?-type=a?kubernetes.default.svc.cluster.local
Server:?????????172.27.2.23
Address:????????172.27.2.23#53Name:???kubernetes.default.svc.cluster.local
Address:?172.26.0.1
---------
Server:?????????172.27.1.131
Address:????????172.27.1.131#53Name:???kubernetes.default.svc.cluster.local
Address:?172.26.0.1
---------
Server:?????????172.27.3.57
Address:????????172.27.3.57#53Name:???kubernetes.default.svc.cluster.local
Address:?172.26.0.1
---------
Server:?????????172.27.0.29
Address:????????172.27.0.29#53Name:???kubernetes.default.svc.cluster.local
Address:?172.26.0.1
---------
Server:?????????172.27.5.53
Address:????????172.27.5.53#53Name:???kubernetes.default.svc.cluster.local
Address:?172.26.0.1
---------
Server:?????????172.27.4.65
Address:????????172.27.4.65#53Name:???kubernetes.default.svc.cluster.local
Address:?172.26.0.1
---------

非預期結果:dns查詢報connection timed out; no servers could be reached, curl報000，都代表網絡可能存在異常

3. 異常場景

當我們通過上述方式，確認集群節點存在異常時，可以使用如下思路進行逐一排查

ip_forward內核被重置為0
flannel通信異常
啟用了firewalld防火墻
啟用了安全軟件

ip_forward

名詞解釋：ip_forward代表了路由轉發特性，為0時不開啟，設置為1時代表啟用。由于vxlan的跨三層特性, 集群節點需要轉發目標主機非自己的數據包.
影響范圍: 如果此值設為0，會導致跨節點通信異常.

出現原因: 在部署時,會向/etc/sysctl.conf里邊添加net.ipv4.ip_forward=1,來保證永久生效。

問題定位: 出現在集群重啟后，發現pods異常，網絡不通. 通過tcmdump抓包發現flannel流量正常。

處理方式

查詢本機內核參數, 在所有節點上執行，可在部署機上使用ansible調用，為讀操作，可放心執行

[root@localhost?~]#?sysctl?-n?net.ipv4.ip_forward
0

打印sysctl加載鏈，會變更相關內核參數，生產環境禁用使用(如果出現ip_forward為0則可使用)

[root@localhost?~]#?sysctl?--system
*?Applying?/usr/lib/sysctl.d/00-system.conf?...
......
*?Applying?/usr/lib/sysctl.d/10-default-yama-scope.conf?...
.....
*?Applying?/usr/lib/sysctl.d/50-default.conf?...
.......
*?Applying?/etc/sysctl.d/99-sysctl.conf?...
.......
*?Applying?/etc/sysctl.conf?...
.......

找到具體是哪個文件修改了ip_forward為0，則修改此文件，并重載內核參數。無異常禁止使用

[root@localhost?~]#?sysctl?-p

flannel通信異常

名詞說明: vxlan是vlan的拓展協議，為overlay網絡，可以穿透三層網絡對二層進行擴展，即大二層網絡。flannel我們默認使用了vxlan做為封裝協議，端口為8472
影響范圍: 跨節點通信異常
問題定位: 對udp 8472端口抓發，發現只有出站流量，未有入站流量，即可認定為flannel vxlan通信異常
出現原因: 安全組封禁，vxlan端口沖突，網卡異常等。由于flannel異常的原因多種多樣，此次僅針對常見情況進行描述。建議具體問題具體分析。
問題處理:?使用nc等相關命令進行測試，如果抓包仍未發現入站流量，且其他udp端口正常，則可使用修改port的方式

添加Port字段，將通信端口修改為8475

[root@localhost?~]#?kubectl?edit?cm?-n?kube-system?kube-flannel-cfg
net-conf.json:?|{"Network":?"172.27.0.0/16","Backend":?{"Type":?"vxlan","Port":?8475}}

修改后需要重啟相關daemonset pods

[root@localhost ~]# kubectl get pods -n kube-system | grep flannel | xargs kubectl delete pods -n kube-system

修改port不生效，可使用host-gw 如果內網各節點二層互通，可使用host-gw模式，此模式兼容性好，網絡效率高.

[root@localhost?~]#?kubectl?edit?cm?-n?kube-system?kube-flannel-cfg
net-conf.json:?|{"Network":?"172.27.0.0/16","Backend":?{"Type":?"host-gw",}

如果無法定位問題，可以通過抓包的方式來判斷

例如：當時coredns網絡不通時，通過curl測試

curl?-I?10.187.1.24:9153/metrics

然后再開一個窗口抓包

tcpdump?-nn?-i?flannel.1?host?10.187.1.24?and?port?9153?-vv

防火墻排查

名詞解釋: 此處的防火墻指Linux的軟件防火墻，在Cenots上叫firewalld, 在UOS下叫UFW. 默認的軟件防火墻會導致相關數據庫被攔截
影響范圍: 特定服務訪問異常，集群節點互通異常
問題定位: 對iptables表鏈進行分析，發現有非預期的規則出現，則代表存在其他防火墻規則
出現原因: 客戶安裝安全軟件，或者是非預期的軟件行為導致
問題排查:

一般看到ufw, public, zone這種，都可能是默認的系統防火墻

[root@localhost?~]#?iptables-save?|?egrep??"^:"?|?egrep?-v?"KUBE|CNI|DOCKER"
:FORWARD_IN_ZONES?-?[0:0]
:FORWARD_IN_ZONES_SOURCE?-?[0:0]
:FORWARD_OUT_ZONES?-?[0:0]
:FORWARD_OUT_ZONES_SOURCE?-?[0:0]

發現后手動關閉,以centos7為例

[root@localhost?~]#?systemctl?stop?firewalld

iptables FORWARD轉發鏈添加了REJECT規則，該規則在ACCEPT之上

刪除規則后正常

iptables?-D?FORWARD?-j?REJECT?--reject-with?icmp-host-prohibited

常見安全軟件排查

qaxsafed??#?奇安信，
sangfor_watchdog?#?深信服安全軟件
YDservice??#qcloud安全軟件，影響pod和docker橋接網絡
Symantec?#賽門鐵克的安全軟件
start360su_safed??#360安全軟件
gov_defence_service
gov_defence_guard??????#??ps?aux?|?grep?defence?
wsssr_defence_daemon???#?奇安信服務器安全加固軟件
wsssr_defence_service
wsssr_defence_agent???#影響pod網絡
kesl?#卡巴斯基安全軟件，影響容器通信?

名詞解釋: 和在windows環境下是一樣的，xc背景下，linux的各類安全軟件也非常多，如奇安信,深信服等
影響范圍: 特定服務訪問異常
問題定位: 以上所有排查方式都嘗試過，則可往此方面排查
出現原因: 客戶安全軟件在內核網絡層hook了對應函數，相關規則過濾了特定的應用數據庫，導致異常