記一次 Kubernetes 網(wǎng)絡(luò)故障深度追蹤

作者：駱冰利 2021-05-26 11:06:06
云計(jì)算 某天晚上，客戶碰到了 Kubernetes 集群一直擴(kuò)容失敗，所有的節(jié)點(diǎn)都無(wú)法正常加入集群。在經(jīng)過多番折騰無(wú)解后，反饋到我們這里進(jìn)行技術(shù)支持。這個(gè)問題的整個(gè)排查過程比較有意思，所以對(duì)其中的排查思路和用到的方法進(jìn)行整理分享。

網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、小程序定制開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了惠濟(jì)免費(fèi)建站歡迎大家使用！

某天晚上，客戶碰到了 Kubernetes 集群一直擴(kuò)容失敗，所有的節(jié)點(diǎn)都無(wú)法正常加入集群。在經(jīng)過多番折騰無(wú)解后，反饋到我們這里進(jìn)行技術(shù)支持。這個(gè)問題的整個(gè)排查過程比較有意思，所以對(duì)其中的排查思路和用到的方法進(jìn)行整理分享。

問題現(xiàn)象

運(yùn)維同學(xué)在對(duì)客戶的 Kubernetes 集群進(jìn)行節(jié)點(diǎn)擴(kuò)容時(shí)，發(fā)現(xiàn)新增的節(jié)點(diǎn)一直添加失敗。該同學(xué)進(jìn)行了初步的排查如下：

• 在新增節(jié)點(diǎn)上，訪問 Kubernetes master service vip 網(wǎng)絡(luò)不通
• 在新增節(jié)點(diǎn)上，直接訪問 Kubernetes master hostIP + 6443 網(wǎng)絡(luò)正常
• 在新增節(jié)點(diǎn)上，訪問其他節(jié)點(diǎn)的容器 IP 可以正常 ping 通
• 在新增節(jié)點(diǎn)上，訪問 coredns service vip 網(wǎng)絡(luò)正常

該客戶使用的 Kubernetes 版本是 1.13.10，宿主機(jī)的內(nèi)核版本是 4.18(CentOS 8.2)。

問題排查過程

收到該一線同事的反饋，我們已經(jīng)初步懷疑是 IPVS 的問題。根據(jù)以往網(wǎng)絡(luò)問題排查的經(jīng)驗(yàn)，先對(duì)現(xiàn)場(chǎng)做了些常規(guī)排查：

• 確認(rèn)內(nèi)核模塊 ip_tables 是否加載(正常)
• 確認(rèn) iptable forward 是否默認(rèn) accpet (正常)
• 確認(rèn)宿主機(jī)網(wǎng)絡(luò)是否正常(正常)
• 確認(rèn)容器網(wǎng)絡(luò)是否正常(正常)
• ……

排除了常規(guī)的問題之后，基本可以縮小范圍，再繼續(xù)基于 IPVS 相關(guān)層面進(jìn)行排查。

通過 ipvsadm 命令排查

10.96.0.1 是客戶集群 Kubernetes master service vip。

可以發(fā)現(xiàn)有異常連接，處于 SYN_RECV 的狀態(tài)，并且可以觀察到，啟動(dòng)時(shí) kubelet + kube-proxy 是有正常建連的，說明是在啟動(dòng)之后，Kubernetes service 網(wǎng)絡(luò)出現(xiàn)異常。

tcpdump 抓包分析

兩端進(jìn)行抓包，并通過 telnet 10.96.0.1 443 命令進(jìn)行確認(rèn)。

結(jié)論：發(fā)現(xiàn) SYN 包在本機(jī)沒有發(fā)送出去。

初步總結(jié)

通過上面的排查，可以再次縮小范圍，問題基本就在 kube-proxy 身上。我們采用了 IPVS 模式，也會(huì)依賴了 iptables 配置實(shí)現(xiàn)一些網(wǎng)絡(luò)的轉(zhuǎn)發(fā)、SNAT、drop 等等。

根據(jù)上面的排查過程，我們又縮小了范圍，開始分析懷疑對(duì)象 kube-proxy。

查看 kube-proxy 日志

發(fā)現(xiàn)異常日志，iptables-restore 命令執(zhí)行異常。通過 Google、社區(qū)查看，確認(rèn)問題。

繼續(xù)深入

通過代碼查看(1.13.10 版本 pkg/proxy/ipvs/proxier.go:1427)，可以發(fā)現(xiàn)該版本確實(shí)沒有判斷 KUBE-MARK-DROP 是否存在并創(chuàng)建的邏輯。當(dāng)出現(xiàn)該鏈不存在時(shí)，會(huì)出現(xiàn)邏輯缺陷，導(dǎo)致 iptable 命令執(zhí)行失敗。

Kubernetes master service vip 不通，但是實(shí)際容器相關(guān)的 IP 是通的原因，與下面這條 iptable 規(guī)則有關(guān)：

  
 
 
 

   
  
  
  
iptable -t nat -A KUBE-SERVICES ! -s 9.0.0.0/8 -m comment --comment "Kubernetes service cluster ip + port for masquerade purpose" -m set --match-set KUBE-CLUSTER-IP dst,dst -j KUBE-MARK-MASQ 
  
 
 
 

根因探究

前面我們已經(jīng)知道了 kube-proxy 1.13.10 版本存在缺陷，在沒有創(chuàng)建 KUBE-MARK-DROP 鏈的情況下，執(zhí)行 iptables-restore 命令配置規(guī)則。但是為何 Kubernetes 1.13.10 版本跑在 CentOS 8.2 4.18 內(nèi)核的操作系統(tǒng)上會(huì)報(bào)錯(cuò)，跑在 CentOS 7.6 3.10 內(nèi)核的操作系統(tǒng)上卻正常呢?

查看下 kube-proxy 的源碼，可以發(fā)現(xiàn) kube-proxy 其實(shí)也就是執(zhí)行 iptables 命令進(jìn)行規(guī)則配置。那既然 kube-proxy 報(bào)錯(cuò) iptables-restore 命令失敗，我們就找一臺(tái) 4.18 內(nèi)核的機(jī)器，進(jìn)入 kube-proxy 容器看下情況。

到容器內(nèi)執(zhí)行下 iptables-save 命令，可以發(fā)現(xiàn) kube-proxy 容器內(nèi)確實(shí)沒有創(chuàng)建 KUBE-MARK-DROP 鏈(符合代碼預(yù)期)。繼續(xù)在宿主機(jī)上執(zhí)行下 iptables-save 命令，卻發(fā)現(xiàn)是有 KUBE-MARK-DROP 鏈。

這里有兩個(gè)疑問：

• 為何 4.18 內(nèi)核宿主機(jī)的 iptables 有 KUBE-MARK-DROP 鏈?
• 為何 4.18 內(nèi)核宿主機(jī)的 iptables 規(guī)則和 kube-proxy 容器內(nèi)的規(guī)則不一致?

第一個(gè)疑惑，憑感覺懷疑除了 kube-proxy，還會(huì)有別的程序在操作 iptables，繼續(xù)擼下 Kubernetes 代碼。

結(jié)論：發(fā)現(xiàn)確實(shí)除了 kube-proxy，還有 kubelet 也會(huì)修改 iptables 規(guī)則。具體代碼可以查看 pkg/kubelet/kubelet_network_linux.go

第二個(gè)疑惑，繼續(xù)憑感覺吧。Google 一發(fā)撈一下為何 kube-proxy 容器掛載了宿主機(jī) /run/xtables.lock 文件的情況下，宿主機(jī)和容器 iptables 查看的規(guī)則不一致。

結(jié)論：CentOS 8 在網(wǎng)絡(luò)方面摒棄 iptables 采用 nftables 框架作為默認(rèn)的網(wǎng)絡(luò)包過濾工具。

至此，所有的謎團(tuán)都解開了。

團(tuán)隊(duì)完成過大量的客戶項(xiàng)目交付，還是有些問題可以再解答下：

• 問題一：為何這么多客戶環(huán)境第一次碰到該情況?因?yàn)樾枰?Kubernetes 1.13.10 + centos 8.2 的操作系統(tǒng)，這個(gè)組合罕見，且問題是必現(xiàn)。升級(jí) Kubernetes 1.16.0+ 就不會(huì)有該問題。
• 問題二：為何使用 Kubernetes 1.13.10 + 5.5 內(nèi)核卻沒有該問題?

因?yàn)槟鞘桥c CentOS 8 操作系統(tǒng)有關(guān)，我們手動(dòng)升級(jí) 5.5 版本后，默認(rèn)還是使用的 iptables 框架。

可以通過 iptables -v 命令來(lái)確認(rèn)，是否使用了 nftables。

nftables 是何方神圣?比 iptables 好么?這是另一個(gè)值得進(jìn)一步學(xué)習(xí)的點(diǎn)，這里就不再深入了。

解決方法

針對(duì)以上的排查問題，我們總結(jié)下解決方法：

• 調(diào)整內(nèi)核版本到 3.10(CentOS 7.6+)，或者手動(dòng)升級(jí)內(nèi)核版本到 5.0 +;
• 升級(jí) Kubernetes 版本，當(dāng)前確認(rèn) 1.16.10+ 版本沒有該問題。

網(wǎng)站名稱：記一次Kubernetes網(wǎng)絡(luò)故障深度追蹤
本文來(lái)源：http://www.dlmjj.cn/article/dpdscdd.html