1. 故障現(xiàn)場Pod運(yùn)行一切正常但Service端口就是不通某個(gè)工作日的中午某系統(tǒng)A同事帶著一臉茫然來找我“容器都Running了CPU內(nèi)存也正常沒有任何重啟但業(yè)務(wù)入口一直在超時(shí)。”我登錄集群看了一眼kubectl get pod輸出的確很干凈所有Pod都是Running狀態(tài)READY也是1/1沒有CrashLoopBackOff沒有ImagePullBackOff連Warning事件都沒幾個(gè)。但當(dāng)我嘗試訪問Service暴露的端口時(shí)請求就像打進(jìn)黑洞一樣等來的只有客戶端超時(shí)。這就是我在Kubernetes排障實(shí)戰(zhàn)系列里遇到的相當(dāng)有代表性的一個(gè)場景資源層面完全正常端口層面卻徹底不通。Kubernetes的資源狀態(tài)反映的是生命周期和探針結(jié)果并不代表網(wǎng)絡(luò)路徑真的可達(dá)。尤其是當(dāng)“Invalid Container Port”這類端口聲明與實(shí)際監(jiān)聽不一致的問題出現(xiàn)時(shí)資源看起來正常恰恰是最有迷惑性的。因?yàn)镵ubernetes認(rèn)為這個(gè)Pod是健康的Service也找到了Endpoint所有臺詞都準(zhǔn)備好了可流量就是送不到正確的門牌號上。接手之后我快速整理了四個(gè)排查方向Service的selector是否真的匹配到了目標(biāo)Pod、Pod里的業(yè)務(wù)進(jìn)程是否真的在監(jiān)聽目標(biāo)端口、Service的targetPort和實(shí)際監(jiān)聽端口是否一致、kube-proxy這層轉(zhuǎn)發(fā)鏈路是否正常。當(dāng)時(shí)的直覺是這個(gè)問題大概率出在配置錯(cuò)位上而不是資源或網(wǎng)絡(luò)基礎(chǔ)設(shè)施故障。后面的事實(shí)也證明這就是一個(gè)非常經(jīng)典的“聲明端口”與“實(shí)際監(jiān)聽端口”脫節(jié)的案例只是它偽裝成資源正常的樣子出現(xiàn)在我們面前。1.1 癥狀與初步判斷先說說當(dāng)時(shí)的現(xiàn)場細(xì)節(jié)。出問題的是一個(gè)內(nèi)部Web服務(wù)通過ClusterIP類型的Service對外提供服務(wù)端口配置為8080。訪問鏈路大致是客戶端 → Service ClusterIP:8080 → Pod IP:8080 → 容器內(nèi)業(yè)務(wù)進(jìn)程。按照A同事的描述Pod狀態(tài)看起來一切正常但無論從哪個(gè)客戶端訪問結(jié)果都是連接超時(shí)。我做的第一個(gè)動作是快速核對Service和Endpoint。kubectl get svc輸出顯示Service存在類型ClusterIPCLUSTER-IP有值PORT列顯示8080/TCP。kubectl get endpoints輸出顯示這個(gè)Service后面確實(shí)掛了Pod IPEndpoint列表不是空的。到這里為止最基礎(chǔ)的Kubernetes服務(wù)發(fā)現(xiàn)鏈路是完整的——Service能找到PodPod也在運(yùn)行中。但這里要提醒一句Endpoint存在只說明Pod被成功納入了Service的后端列表絕不代表這個(gè)端口真的能被訪問。Service的Endpoint生成邏輯是selector匹配只要Pod的標(biāo)簽和Service的selector一致無論P(yáng)od里的進(jìn)程到底在監(jiān)聽什么端口Endpoint都會把Pod IP和targetPort填進(jìn)去。所以Endpoint正常只是前提不是結(jié)論。1.2 為什么“資源正常”會誤導(dǎo)排障方向很多人遇到“端口不通”的第一反應(yīng)是看資源狀態(tài)看到Pod Running之后就轉(zhuǎn)向懷疑網(wǎng)絡(luò)插件、節(jié)點(diǎn)網(wǎng)絡(luò)、甚至是公有云的安全組規(guī)則。誠然這些因素確實(shí)可能導(dǎo)致端口不通但“資源正常”只能排除資源類故障剩下的可能性仍然很多?！百Y源正常”和“端口通”之間隔著好幾層邏輯。以Pod為例只要容器沒有被殺掉、沒有探針失敗Pod就會一直顯示Running。但如果容器內(nèi)的應(yīng)用啟動時(shí)因?yàn)榕渲缅e(cuò)誤壓根沒有監(jiān)聽聲明端口Kubernetes的調(diào)度器和kubelet都不會給你任何提示——containerPort只是一個(gè)描述性字段它不會去驗(yàn)證容器內(nèi)是否有進(jìn)程在監(jiān)聽這個(gè)端口也不會在監(jiān)聽失敗時(shí)報(bào)錯(cuò)。這也是“Invalid Container Port”這類問題最難查的地方一切元數(shù)據(jù)都正常但真正干活的進(jìn)程缺位。所以排障一定要從“鏈路”而不是“狀態(tài)”入手。這也是這一期排障實(shí)戰(zhàn)系列想重點(diǎn)分享的思路。2. 排障思路拆解先定位“不通斷在哪一跳”做網(wǎng)絡(luò)類排障最忌諱的就是東敲一下、西敲一下沒有章法。我習(xí)慣把從客戶端到應(yīng)用進(jìn)程的完整鏈路畫出來然后一段一段做連通性驗(yàn)證?！岸丝诓煌ǖY源正常”這種情況下通路段一般在五個(gè)位置Service轉(zhuǎn)發(fā)、kube-proxy規(guī)則、Pod網(wǎng)絡(luò)命名空間、容器內(nèi)進(jìn)程監(jiān)聽、安全策略攔截。只要確定了斷點(diǎn)在第幾跳就自然知道往哪個(gè)方向深挖。2.1 連通性驗(yàn)證的三個(gè)層級我把驗(yàn)證動作分成三層從外到內(nèi)一層層收斂第一層是“Service到后端”。在集群內(nèi)隨便找一個(gè)Pod訪問Service的ClusterIP和端口看能不能通。這層通了就說明Service本身沒問題不通也不代表一切完了還需要繼續(xù)往下切。第二層是“Pod IP直連”。繞過Service直接訪問Endpoint列表里的Pod IP和對應(yīng)端口。注意這里訪問的端口要和Service的targetPort一致而不是和Service的port一致。如果這一層通了說明Pod到Service這段沒問題問題大概率出在Service定義上如果也不通說明問題在Pod自身或者容器網(wǎng)絡(luò)。第三層是“進(jìn)入Pod看真相”。通過kubectl exec進(jìn)入容器內(nèi)部回到進(jìn)程視角直接查看應(yīng)用到底在監(jiān)聽哪個(gè)地址哪個(gè)端口。這里才算真正接觸到問題的本質(zhì)。這個(gè)順序的意義在于每做一步驗(yàn)證都能排除或確認(rèn)一個(gè)層級不會在猜測中反復(fù)橫跳。2.2 動手驗(yàn)證從Service到Pod直連的逐步收斂實(shí)際操作中我用一個(gè)臨時(shí)busybox Pod作為測試客戶端避免在生產(chǎn)Pod里塞命令kubectl run curl-test --imagebusybox:1.36 --rm -it -- sh進(jìn)入測試Pod后先試Service的ClusterIP。假設(shè)ClusterIP是10.96.100.10端口是8080wget -O- --timeout5 http://10.96.100.10:8080/結(jié)果如預(yù)期超時(shí)。接著從Endpoints里找到真實(shí)的Pod IP假設(shè)是10.244.30.7還是用8080端口wget -O- --timeout5 http://10.244.30.7:8080/同樣超時(shí)。這一步非常關(guān)鍵Pod IP直連超時(shí)意味著問題不在Service轉(zhuǎn)發(fā)層而在Pod容器網(wǎng)絡(luò)或應(yīng)用進(jìn)程內(nèi)部。在這個(gè)時(shí)間點(diǎn)我已經(jīng)把排查范圍從“整個(gè)集群網(wǎng)絡(luò)”縮小到了“特定Pod內(nèi)部”。接下來就是進(jìn)入第三層也就是下一章的核心內(nèi)容。3. 深入容器內(nèi)部進(jìn)程監(jiān)聽的端口才是硬事實(shí)3.1 進(jìn)入Pod查看監(jiān)聽端口既然Pod IP:8080不通我需要確認(rèn)8080在容器內(nèi)到底有沒有進(jìn)程在監(jiān)聽。最直接的方式是進(jìn)入Pod的命名空間看端口占用情況kubectl exec -it demo-app-7d8c9f5d6c-abcde -n demo-ns -- sh進(jìn)入容器后第一步自然是查看監(jiān)聽端口。一般的容器鏡像里不一定有netstat但多數(shù)發(fā)行版會帶ss我通常用下面這條命令ss -tlnp如果容器里沒有ss可以通過/proc/net/tcp查看IPv4的監(jiān)聽信息或者臨時(shí)安裝iproute2/net-tools。但要注意生產(chǎn)環(huán)境不建議在容器里隨意安裝軟件能省則省。這次執(zhí)行ss -tlnp后看到的輸出讓我眼前一亮。容器內(nèi)監(jiān)聽列表里只有一行和業(yè)務(wù)相關(guān)的State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 128 0.0.0.0:18080 0.0.0.0:* users:((java,pid7,fd26))8080端口根本沒有進(jìn)程在監(jiān)聽。所有Deployment和Service聲明里寫的是8080但容器里真正被占用的是18080。3.2 根因確認(rèn)端口聲明與應(yīng)用實(shí)際監(jiān)聽錯(cuò)位看到18080這個(gè)端口再回查應(yīng)用啟動方式答案就浮出水面了。這個(gè)應(yīng)用默認(rèn)監(jiān)聽8080但啟動腳本里讀取了一個(gè)環(huán)境變量PORT來覆蓋默認(rèn)端口。查看Deployment定義后發(fā)現(xiàn)env: - name: PORT value: 18080也就是說應(yīng)用啟動時(shí)把PORT18080帶進(jìn)來了于是進(jìn)程乖乖地監(jiān)聽在18080上。而Service的targetPort一直是8080Deployment里的containerPort也一直寫著8080探針如果有的話也在探測8080——但這里更關(guān)鍵的是Kubernetes的containerPort字段只是一個(gè)聲明它不會在容器里幫你創(chuàng)建任何端口也不會驗(yàn)證端口是否真實(shí)存在。應(yīng)用實(shí)際監(jiān)聽哪個(gè)端口完全由進(jìn)程自己決定。這個(gè)時(shí)候標(biāo)題里的“Invalid Container Port”就變得很形象了容器端口聲明是8080但實(shí)際進(jìn)程監(jiān)聽的是18080。從Kubernetes配置看這個(gè)端口聲明是“有效”的可它指向了一個(gè)沒有人應(yīng)門的地址。這就是一類經(jīng)典的配置漂移問題環(huán)境變量、啟動參數(shù)、默認(rèn)值三者之間沒有對齊最終把整個(gè)Service帶進(jìn)了一個(gè)“看起來正常、實(shí)際不通”的僵局。圍繞這個(gè)根因還有兩個(gè)細(xì)節(jié)值得展開說。第一為什么Pod狀態(tài)始終是Running因?yàn)槿绻鸓od沒有配置探針或者探針探測的是業(yè)務(wù)里另一個(gè)健康接口kubelet永遠(yuǎn)不會發(fā)現(xiàn)端口錯(cuò)位。第二為什么沒有收到任何Kubernetes報(bào)錯(cuò)因?yàn)閏ontainerPort不屬于kubelet強(qiáng)制校驗(yàn)的字段它不會主動檢查容器里的端口占用情況。這也解釋了為什么“資源正?！睍蔀橐粋€(gè)坑。4. 交叉復(fù)核kube-proxy、iptables與網(wǎng)絡(luò)策略是否干凈雖然根因已經(jīng)基本鎖定在Pod內(nèi)部但我在給出最終結(jié)論前還是把外層鏈路復(fù)核了一遍。這樣做有兩個(gè)原因一是怕自己漏看二是端口錯(cuò)位雖然能解釋當(dāng)前現(xiàn)象但萬一同時(shí)存在其他網(wǎng)絡(luò)層面的問題修復(fù)完端口還是會翻車。交叉驗(yàn)證是排障的保險(xiǎn)絲。4.1 kube-proxy轉(zhuǎn)發(fā)鏈路的常規(guī)檢查kube-proxy負(fù)責(zé)把Service的ClusterIP流量轉(zhuǎn)發(fā)到后端Pod。在iptables模式下Service、Endpoint和Pod之間的映射關(guān)系最終都會落到NAT規(guī)則里。檢查思路是找一個(gè)節(jié)點(diǎn)登錄上去執(zhí)行iptables -t nat -nL | grep demo-app由于鏈名里帶隨機(jī)字符串用服務(wù)名過濾是最快的。查完之后重點(diǎn)確認(rèn)幾件事這個(gè)Service對應(yīng)的KUBE-SVC-XXXX鏈?zhǔn)欠翊嬖凇㈡溊锸欠癜赶蚝蠖薖od的KUBE-SEP-XXXX規(guī)則、KUBE-SEP規(guī)則里的目標(biāo)地址是否就是Endpoint列表里那幾個(gè)Pod IP。我檢查下來規(guī)則鏈完整轉(zhuǎn)發(fā)邏輯也指向了正確的Pod IP只是目標(biāo)端口自然也是8080。到這里就可以確認(rèn)kube-proxy只是忠實(shí)地按照Service定義去投遞問題不在這一層。順便說一句如果以后遇到規(guī)則的KUBE-SEP鏈里沒有任何規(guī)則那就要優(yōu)先懷疑kube-proxy和API Server之間的同步出了問題可能和節(jié)點(diǎn)上的kube-proxy進(jìn)程、甚至和調(diào)度有關(guān)。4.2 NetworkPolicy與節(jié)點(diǎn)相關(guān)的干擾排除再檢查是否有NetworkPolicy把流量擋在了門外kubectl get networkpolicy -A輸出結(jié)果為空說明集群默認(rèn)沒有啟用網(wǎng)絡(luò)策略限制網(wǎng)絡(luò)策略排除。之后還要考慮一種特殊情況Pod的端口可能被監(jiān)聽在127.0.0.1而不是0.0.0.0。這種“l(fā)ocalhost陷阱”在技術(shù)社區(qū)里非常常見尤其在開發(fā)環(huán)境里跑本地服務(wù)時(shí)開發(fā)者習(xí)慣了綁定回環(huán)地址結(jié)果鏡像打包進(jìn)K8s后忘了改。如果進(jìn)程監(jiān)聽在127.0.0.1:8080那你即使在容器內(nèi)用localhost訪問也是通的但Pod IP和Service的流量一律進(jìn)不來。雖然本案例不是這個(gè)問題但我在排查時(shí)一直把它放在候選根因清單里也是建議大家養(yǎng)成的習(xí)慣——看監(jiān)聽地址時(shí)不要只看端口數(shù)字還要看Local Address那一列的IP到底是0.0.0.0、::還是127.0.0.1。到這里復(fù)核工作全部完成kube-proxy規(guī)則正常、無網(wǎng)絡(luò)策略干擾、安全組也不會影響集群內(nèi)Pod之間的通信。斷點(diǎn)可以百分之百鎖定為容器端口聲明與實(shí)際監(jiān)聽不一致。5. 修復(fù)與加固讓端口聲明真正“有效”根因確認(rèn)后修復(fù)方案其實(shí)有兩條路但兩條路的“長期代價(jià)”完全不同。選哪條取決于團(tuán)隊(duì)對這套服務(wù)的配置管理思路。5.1 兩種修復(fù)路徑與選擇邏輯第一種是最快的直接改Service的targetPort把8080改成18080。這樣Service會發(fā)現(xiàn)Pod在18080端口活著流量馬上就能走通。但我不太推薦把它當(dāng)長期方案因?yàn)樗鼤孌eployment里的containerPort8080和Service里的targetPort18080永遠(yuǎn)處于不一致狀態(tài)。再過幾周你做集群巡檢時(shí)看到這套配置第一反應(yīng)必然是“這又是誰改錯(cuò)了”然后又得花時(shí)間理清楚歷史原因。第二種是改回應(yīng)用啟動參數(shù)把環(huán)境變量PORT改成8080或者直接刪掉讓應(yīng)用回到默認(rèn)端口。這個(gè)方案雖然動的是應(yīng)用配置但它讓“聲明端口”和“實(shí)際端口”重新對齊所有配置都回到同一個(gè)約定上后續(xù)不會埋雷。實(shí)際操作時(shí)我選擇了第二個(gè)方案。先編輯Deploymentkubectl edit deployment demo-app -n demo-ns把PORT18080改成PORT8080保存退出。接著滾動更新kubectl rollout status deployment/demo-app -n demo-ns等新Pod起來后再次用busybox測試Pod IPwget -O- --timeout5 http://10.244.30.7:8080/這次請求立刻有了響應(yīng)。隨后再測Service ClusterIP同樣正常。到這里故障才真正畫上句號。5.2 用命名端口根治“Invalid Container Port”類問題這個(gè)案例給我最深的啟發(fā)是只要端口數(shù)字在兩處以上地方被硬編碼就遲早會出現(xiàn)不一致。Deployment里寫一次containerPortService里寫一次targetPort探針配置里可能還要寫一次應(yīng)用環(huán)境變量里也有一次。任何一個(gè)地方?jīng)]跟上就會陷入這種“資源都正常但端口不通”的困境。Kubernetes其實(shí)早就給出了一種解法命名端口。在Deployment的端口聲明里給端口起個(gè)名字然后Service的targetPort直接引用名字而不是數(shù)字ports: - name: http containerPort: 8080Service定義spec: ports: - name: http port: 80 targetPort: http這樣改完之后如果以后應(yīng)用端口從8080換到18080只需要改Deployment那一處并且保證containerPort和容器內(nèi)實(shí)際監(jiān)聽一致即可。Service不用動探針如果也引用命名端口就更好從這個(gè)角度看命名端口的核心價(jià)值就是“少寫幾處數(shù)字少踩幾個(gè)坑”。另外強(qiáng)烈建議把readinessProbe配置出來探測的路徑或端口要和業(yè)務(wù)實(shí)際端口綁定不要讓“資源正?！背蔀橐粋€(gè)空殼。這樣下次再出現(xiàn)端口錯(cuò)位探針會第一時(shí)間把Pod標(biāo)記為未就緒流量就不會被路由到一個(gè)沒有進(jìn)程監(jiān)聽的端口上問題會從“用戶超時(shí)”提前變成“Pod NotReady”排障難度和影響面都會小很多。6. 排障速查清單與個(gè)人體會6.1 同類現(xiàn)象的快速排查清單把這期排障實(shí)戰(zhàn)的完整過程收攏成一張速查表方便下次遇到“資源正常但端口不通”時(shí)快速套用排查對象驗(yàn)證方式正常結(jié)果異常時(shí)該想什么Servicekubectl get svcClusterIP、端口正常Service沒創(chuàng)建或被誤刪Endpointskubectl get endpoints有Pod IP地址selector不匹配ClusterIP訪問集群內(nèi)wget/curl訪問有響應(yīng)繼續(xù)下一層Pod IP訪問用Endpoint中的IP訪問targetPort有響應(yīng)Service定義有問題容器內(nèi)監(jiān)聽ss -tlnp或netstat -tlnp聲明端口正在監(jiān)聽?wèi)?yīng)用端口被覆蓋/綁定地址錯(cuò)誤應(yīng)用配置查看env、啟動參數(shù)、日志端口和聲明一致配置漂移iptables鏈路iptables -t nat -nL規(guī)則指向正確Podkube-proxy同步問題NetworkPolicykubectl get networkpolicy -A無攔截策略策略放行規(guī)則這個(gè)表建議直接截圖保存遇到同類問題照著過一遍十分鐘內(nèi)基本能定位到斷點(diǎn)。6.2 一些值得分享的排障習(xí)慣最后聊聊我的排障習(xí)慣。第一不要急著重啟Pod。這類“端口聲明與實(shí)際端口不一致”的問題重啟一百次也是同樣的結(jié)果而且重啟會破壞現(xiàn)場。排障的第一步永遠(yuǎn)是把現(xiàn)狀看清楚包括監(jiān)聽端口、進(jìn)程參數(shù)、環(huán)境變量、日志輸出這些都比重啟有價(jià)值得多。第二直接進(jìn)Pod看監(jiān)聽比看任何監(jiān)控面板都靠譜。監(jiān)控面板能告訴你CPU、內(nèi)存、QPS但不會告訴你一個(gè)進(jìn)程到底在哪個(gè)端口上聽命。在Kubernetes排障體系里ss -tlnp是所有人都應(yīng)該熟練掌握的第一條命令。第三發(fā)現(xiàn)問題后順手把“兩層一致性”檢查一遍。所謂兩層第一層是容器內(nèi)進(jìn)程的監(jiān)聽狀態(tài)第二層是Deployment的containerPort、Service的targetPort和探針端口。只要這三處有一處不一致就直接納入風(fēng)險(xiǎn)清單。用命名端口最多解決第二層的部分問題但第一層的“進(jìn)程到底在監(jiān)聽哪個(gè)端口”必須靠習(xí)慣和規(guī)范去兜底。比如以后寫服務(wù)配置時(shí)可以默認(rèn)加上一條團(tuán)隊(duì)約定所有應(yīng)用必須監(jiān)聽0.0.0.0或::數(shù)據(jù)庫、緩存等中間件的端口必須通過ConfigMap統(tǒng)一管理Deployment里的端口聲明必須和HealthCheck路徑在同一個(gè)PR里提交。這些規(guī)則聽著瑣碎卻是減少“Invalid Container Port”類故障最有效的辦法。說實(shí)話這類問題并不難查難的是在“資源全綠”的氛圍里保持懷疑。你越覺得一切正常越要回頭看一眼那句最樸素的話真正在監(jiān)聽的端口才是流量的終點(diǎn)。