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