凌晨三點(diǎn)的告警電話我接過(guò)太多次了但每一次還是讓人瞬間清醒。業(yè)務(wù)同學(xué)在群里說(shuō)“某某服務(wù)超時(shí)率飆升趕緊看看”我打開監(jiān)控面板翻了半天Pod 全是 RunningCPU、內(nèi)存曲線平得像一條直線連日志都沒(méi)有報(bào)錯(cuò)。可服務(wù)就是訪問(wèn)不通。當(dāng)時(shí)的第一反應(yīng)是檢查網(wǎng)絡(luò)插件、防火墻、安全組折騰了一大圈最后才發(fā)現(xiàn)問(wèn)題出在一個(gè)不起眼的地方——Invalid Container Port。這個(gè)場(chǎng)景在 Kubernetes 里非常典型資源都正常、Pod 也活著、網(wǎng)絡(luò)看起來(lái)也沒(méi)問(wèn)題但流量就是到不了應(yīng)用。這篇排障手記我就把“端口不通但資源都正?！边@一類問(wèn)題的完整排查思路、根因分析和實(shí)操步驟整理出來(lái)尤其適合正在做 Kubernetes 運(yùn)維、DevOps 或者后端開發(fā)的朋友遇到同類故障時(shí)可以直接照著抄。1. 癥狀與初始定位明明一切正常為什么就是連不上1.1 這類問(wèn)題最容易讓人誤判的三個(gè)方向先說(shuō)說(shuō)我那次踩坑的經(jīng)歷。業(yè)務(wù)服務(wù)通過(guò) Service 對(duì)外暴露監(jiān)控顯示異常之后我先后懷疑過(guò)三件事。第一個(gè)懷疑的是 CNI 網(wǎng)絡(luò)插件。因?yàn)?Kubernetes 的 Pod 網(wǎng)絡(luò)是靠 Calico、Flannel、Cilium 這類組件來(lái)維護(hù)的一旦網(wǎng)絡(luò)插件出問(wèn)題最常見的表象就是端口不通。我當(dāng)時(shí)先看了網(wǎng)絡(luò)插件的 Pod 狀態(tài)全部正常又看了節(jié)點(diǎn)上的網(wǎng)絡(luò)策略也沒(méi)有異常。這一輪排查純屬浪費(fèi)時(shí)間。第二個(gè)懷疑的是云平臺(tái)的安全組和防火墻。因?yàn)樵谠骗h(huán)境里安全組規(guī)則確實(shí)會(huì)影響 NodePort 和 LoadBalancer 類型的訪問(wèn)。我把安全組規(guī)則翻了又翻發(fā)現(xiàn)規(guī)則都是對(duì)的放行的端口也沒(méi)問(wèn)題。后來(lái)證明這個(gè)方向也是錯(cuò)的。第三個(gè)懷疑的是 Service 的 selector 沒(méi)有匹配上 Pod。這個(gè)方向?qū)α艘话搿獑?wèn)題確實(shí)和 Service 有關(guān)但我當(dāng)時(shí)只看了一眼 selector發(fā)現(xiàn)標(biāo)簽?zāi)芷ヅ渖?Pod就以為 Service 配置沒(méi)問(wèn)題。實(shí)際上問(wèn)題出在更隱蔽的 targetPort 上。現(xiàn)在回頭看這類問(wèn)題之所以容易繞彎路是因?yàn)樗耐庠诒憩F(xiàn)太像“網(wǎng)絡(luò)不通”但資源指標(biāo)又太像“一切正?！?。Pod 沒(méi)重啟、內(nèi)存沒(méi)飆升、CPU 也沒(méi)打滿任何人第一反應(yīng)都不會(huì)是配置問(wèn)題。但恰恰是這種“看著一切正?！钡谋硐笞钊菀鬃屓撕雎宰罨A(chǔ)的配置檢查。1.2 先理清流量路徑再動(dòng)手吃了一次虧之后我養(yǎng)成了一個(gè)習(xí)慣遇到端口不通先不碰網(wǎng)絡(luò)插件也不碰防火墻而是先理清楚流量走的哪條路徑。Kubernetes 里訪問(wèn)一個(gè)應(yīng)用的路徑通常有幾種直接訪問(wèn) Pod IP這個(gè)路徑最底層繞過(guò)了 Service、kube-proxy、DNS 轉(zhuǎn)發(fā)直接打到容器網(wǎng)卡。通過(guò) ClusterIP 訪問(wèn) Service這是最常用的路徑流量經(jīng)過(guò) kube-proxy 轉(zhuǎn)發(fā)的 iptables 或 IPVS 規(guī)則再到達(dá)后端 Pod。通過(guò) NodePort 或 LoadBalancer 訪問(wèn)在 ClusterIP 的基礎(chǔ)上多了一層節(jié)點(diǎn)端口映射。通過(guò) Ingress 訪問(wèn)多一層七層轉(zhuǎn)發(fā)。排查的時(shí)候要一步一步收縮范圍。我的做法是先用kubectl run臨時(shí)起一個(gè)調(diào)試 Pod里面放 curl 或 wget分別測(cè)試這幾條路徑kubectl run debug --imagenicolaka/netshoot --rm -it --restartNever -- /bin/bash進(jìn)去之后先直連 Pod IPcurl http://Pod-IP:port如果直連 Pod IP 能通說(shuō)明容器里的進(jìn)程本身在監(jiān)聽、端口沒(méi)問(wèn)題那問(wèn)題就出在 Service 層。如果直連都不通問(wèn)題大概率在容器內(nèi)部比如進(jìn)程沒(méi)監(jiān)聽、監(jiān)聽地址綁錯(cuò)了、或者協(xié)議不匹配。這個(gè)順序至關(guān)重要。先確認(rèn)底層通不通再往上層查效率至少提高一倍。我見過(guò)不少同事一上來(lái)就去翻 kube-proxy 日志或 iptables 規(guī)則翻了半天才發(fā)現(xiàn)容器里監(jiān)聽的端口跟 Service 配的 targetPort 根本不是同一個(gè)數(shù)。基礎(chǔ)層沒(méi)確認(rèn)上層查得再深都是白搭。2. Invalid Container Port 到底是誰(shuí)在“判定無(wú)效”2.1 containerPort 只是“說(shuō)明書”不是“開關(guān)”Kubernetes 里有個(gè)非常容易被誤解的概念Pod 的containerPort字段。很多新手以為寫了這個(gè)字段Kubernetes 就會(huì)幫你在容器里打開某個(gè)端口。實(shí)際上完全不是這么回事。containerPort不是一個(gè)“開關(guān)”K8s 不會(huì)去監(jiān)聽這個(gè)端口也管不了容器進(jìn)程到底有沒(méi)有在這個(gè)端口上做監(jiān)聽。它只是一份“說(shuō)明書”把信息寫在 Pod 的定義里告訴別人“這個(gè)容器預(yù)期會(huì)使用這樣的端口”。真正把端口打開并監(jiān)聽的是容器里的業(yè)務(wù)進(jìn)程本身。我習(xí)慣用一個(gè)生活化的比喻來(lái)解釋這件事containerPort相當(dāng)于你家門口貼的門牌號(hào)寫的是“302室”。Kubernetes 的 Service 就像快遞員按照門牌號(hào)去送包裹。但如果 302 房間里面根本沒(méi)有人在聽門鈴——也就是說(shuō)容器進(jìn)程根本沒(méi)有監(jiān)聽這個(gè)端口——快遞員按了半天門鈴沒(méi)人開門包裹就只能被退回。此時(shí)快遞員會(huì)報(bào)告“這個(gè)門鈴無(wú)效”這就是我們看到的 Invalid Container Port 現(xiàn)象。理解了這一點(diǎn)你就明白為什么“資源都正?！眳s“端口不通”了容器里的進(jìn)程確實(shí)在跑內(nèi)存、CPU 都正常但它要么沒(méi)有監(jiān)聽 Service 指向的那個(gè)端口要么監(jiān)聽地址不對(duì)要么 Service 引用了一個(gè)根本不存在于 Pod 定義里的端口名。Pod 本身活著但流量沒(méi)人接。2.2 五種常見成因逐個(gè)拆解根據(jù)我處理過(guò)的真實(shí)故障Invalid Container Port 這類問(wèn)題可以歸納成下面五種典型成因。第一種也是最常見的一種targetPort使用了命名端口但在 Pod 里找不到同名的containerPort或者大小寫不一致。Kubernetes 的targetPort支持兩種寫法數(shù)字端口和命名端口。當(dāng)targetPort寫的是數(shù)字時(shí)控制面會(huì)直接把流量轉(zhuǎn)發(fā)到 Pod IP 的對(duì)應(yīng)數(shù)字端口這個(gè)場(chǎng)景下即使containerPort沒(méi)有聲明也能通。但當(dāng)targetPort寫成命名端口時(shí)控制面就必須去 Pod 的 spec 里找名字完全一致的containerPort。注意名字是完全區(qū)分大小寫的HTTP和http是兩個(gè)完全不同的名字。我踩過(guò)最經(jīng)典的一個(gè)坑是Service 里寫的是targetPort: HTTPPod 里聲明的是containerPort: 80, name: http。服務(wù)控制面找不到HTTP這個(gè)名字于是把 endpoint 置空表現(xiàn)就是端口完全不通但 Pod 一切正常。第二種targetPort配的數(shù)字端口跟容器進(jìn)程實(shí)際監(jiān)聽的端口不是同一個(gè)。這種情況不需要命名端口匹配endpoints 也是能生成出來(lái)的Service 的底層規(guī)則也正常但流量到容器門口時(shí)容器里沒(méi)有進(jìn)程在對(duì)應(yīng)端口監(jiān)聽。比如業(yè)務(wù)進(jìn)程監(jiān)聽的是 8080Service 的targetPort寫成 80結(jié)果就是訪問(wèn)超時(shí)或連接拒絕。問(wèn)題的根源在于K8s 不會(huì)因?yàn)槟阏f(shuō)了 80 就去調(diào)用進(jìn)程切換端口它只是原樣把流量送過(guò)去。第三種多容器場(chǎng)景下端口名定義在了錯(cuò)誤的容器上。一個(gè) Pod 里可能跑多個(gè)容器比如業(yè)務(wù)容器加 sidecar 容器。如果targetPort的命名端口匹配到了 sidecar 容器而業(yè)務(wù)進(jìn)程實(shí)際在另一個(gè)容器里監(jiān)聽就會(huì)發(fā)生“端口聲明有但實(shí)際沒(méi)人處理業(yè)務(wù)流量”的情況。這種問(wèn)題檢查起來(lái)特別費(fèi)勁因?yàn)槊謱?duì)得上、endpoints 也正常就是不通。第四種協(xié)議不匹配。Service 定義端口的時(shí)候可以指定protocol默認(rèn)是 TCP。如果容器里業(yè)務(wù)進(jìn)程實(shí)際監(jiān)聽的是通過(guò) UDP 通信的服務(wù)而 Service 定義的protocol: TCP同樣會(huì)出現(xiàn)端口不通。反過(guò)來(lái)也是同樣的問(wèn)題。這種問(wèn)題在日志里最不明顯因?yàn)?TCP 和 UDP 都是同一個(gè)端口號(hào)肉眼很難發(fā)現(xiàn)。第五種業(yè)務(wù)進(jìn)程監(jiān)聽的地址不對(duì)。這不是 Kubernetes 的配置問(wèn)題但很容易被誤認(rèn)為 K8s 問(wèn)題。比如很多 Node 應(yīng)用默認(rèn)只在127.0.0.1上監(jiān)聽這個(gè)地址在容器里只有自己能看到外部流量從 eth0 進(jìn)來(lái)自然連不上。查看監(jiān)聽狀態(tài)時(shí)一定要確認(rèn)監(jiān)聽地址是0.0.0.0或至少是 Pod 的網(wǎng)卡地址。2.3 事件日志里的有效線索遇到這類問(wèn)題一定要會(huì)看事件日志。kubectl describe svc的輸出里會(huì)直接告訴我們關(guān)鍵線索。kubectl describe svc demo-svc正常情況下輸出里會(huì)顯示Endpoints字段帶有實(shí)際的 Pod IP如果端口聲明有問(wèn)題Endpoints會(huì)顯示none。與此同時(shí)Service 的TargetPort字段會(huì)顯示你配置的值比如HTTP/TCP這時(shí)候你去對(duì) Pod 里的containerPort一眼就能發(fā)現(xiàn)大小寫不一致的問(wèn)題。在比較新的 Kubernetes 版本里EndpointSlice Controller 還會(huì)在事件里輸出類似 “invalid container port” 的警告信息直接告訴你目標(biāo)端口在 Pod 里找不到對(duì)應(yīng)項(xiàng)。不同版本的具體文案可能不一樣但排查思路完全一致事件里只要提到invalid container port或failed to build model for service十有八九就是targetPort引用出了問(wèn)題。3. 完整排查流程從 Pod 命令到抓包驗(yàn)證下面這段是我現(xiàn)在遇到“端口不通但資源都正?！鳖悊?wèn)題時(shí)實(shí)際執(zhí)行的標(biāo)準(zhǔn)流程每一步都有對(duì)應(yīng)的命令和判斷邏輯你可以直接拿來(lái)當(dāng)模板用。3.1 第一步確認(rèn)端口是“假活”還是“真活”第一個(gè)動(dòng)作永遠(yuǎn)不是查網(wǎng)絡(luò)插件而是進(jìn)到 Pod 里看進(jìn)程到底監(jiān)聽了什么。這一步的目的是回答最基礎(chǔ)的問(wèn)題容器里到底有沒(méi)有進(jìn)程在監(jiān)聽對(duì)應(yīng)的端口kubectl exec -it pod-name -n namespace -- netstat -tulpn如果 Pod 里有多個(gè)容器記得加-c container-name指定容器kubectl exec -it pod-name -n namespace -c container-name -- netstat -tulpn有些基礎(chǔ)鏡像里沒(méi)有netstat可以用ss命令kubectl exec -it pod-name -n namespace -- ss -tlnp判斷邏輯很簡(jiǎn)單如果看到目標(biāo)端口有進(jìn)程在監(jiān)聽而且監(jiān)聽地址是0.0.0.0或::那容器這一層沒(méi)問(wèn)題。如果端口根本沒(méi)有監(jiān)聽記錄說(shuō)明業(yè)務(wù)進(jìn)程沒(méi)起來(lái)或者起來(lái)了但監(jiān)聽的不是這個(gè)端口。這時(shí)候去容器里看進(jìn)程列表確認(rèn)進(jìn)程是否活著。如果監(jiān)聽了但監(jiān)聽地址是127.0.0.1那流量從外部進(jìn)不來(lái)需要改應(yīng)用的監(jiān)聽配置讓它監(jiān)聽0.0.0.0。這個(gè)步驟能快速把問(wèn)題縮小到“應(yīng)用問(wèn)題”還是“Kubernetes 配置問(wèn)題”。我在這一步至少救回過(guò)三次誤判都是因?yàn)橄热霝橹饔X得資源正常進(jìn)程就一定健康結(jié)果發(fā)現(xiàn)業(yè)務(wù)進(jìn)程其實(shí)已經(jīng)悄然退出了容器靠 init 進(jìn)程活著看著是 Running 但業(yè)務(wù)早已不服務(wù)。3.2 第二步Service 與 Endpoints 的關(guān)聯(lián)排查如果容器里監(jiān)聽正常下一步就看 Service 層。先看 Service 配置kubectl get svc service-name -n namespace -o yaml重點(diǎn)看三個(gè)字段selector、ports[].port、ports[].targetPort。然后把 selector 選中的 Pod 標(biāo)簽對(duì)比一下確認(rèn)匹配關(guān)系kubectl get pod -n namespace --show-labels再查看 endpoinds。老版本里這個(gè)對(duì)象叫 Endpoints新版本切到了 EndpointSlice但kubectl get endpoints依然能看到聚合結(jié)果排查思路是一樣的kubectl get endpoints service-name -n namespace這里會(huì)出現(xiàn)三種結(jié)果第一Endpoints顯示none說(shuō)明后端的地址列表沒(méi)有生成。此時(shí)有兩種可能selector 沒(méi)匹配到任何 Pod或者targetPort引用的命名端口在 Pod 里找不到。區(qū)分方法很簡(jiǎn)單看kubectl describe svc的輸出如果 selector 匹配了 Pod但Endpoints還是空那幾乎可以斷定是targetPort的問(wèn)題。第二Endpoints顯示了 Pod IP用kubectl get endpoints能看到類似10.244.1.5:8080這樣的記錄。這說(shuō)明 Service 層正常endpoint 已經(jīng)生成。如果這時(shí)候再?gòu)募簝?nèi)訪問(wèn) ClusterIP 不通問(wèn)題就出在 kube-proxy 轉(zhuǎn)發(fā)這一層。第三Endpoints顯示 Pod IP 和端口但端口號(hào)跟你預(yù)期的不一樣。這通常也是targetPort的問(wèn)題——你寫成命名端口匹配到了 Pod 里另一個(gè)容器的端口。這一步是最關(guān)鍵的一步。一個(gè)空 Endpoints 直接說(shuō)明問(wèn)題在 Service 引用上不用再去翻網(wǎng)絡(luò)插件。3.3 第三步kube-proxy 規(guī)則層面的驗(yàn)證如果前兩步都正常Service 和 endpoints 都有內(nèi)容但通過(guò) ClusterIP 訪問(wèn)還是不通這時(shí)候再來(lái)看節(jié)點(diǎn)上的轉(zhuǎn)發(fā)規(guī)則。先確認(rèn) kube-proxy 使用的模式?，F(xiàn)在大多數(shù)集群默認(rèn) IPVS 模式有些還是 iptables?？梢杂孟旅娴拿畲_認(rèn)kubectl logs -n kube-system kube-proxy-pod | grep Using如果是 iptables 模式在 Service 對(duì)應(yīng)的節(jié)點(diǎn)上查一下 nat 表規(guī)則iptables -t nat -S | grep service-name如果是 IPVS 模式ipvsadm -L -n | grep ClusterIP要特別提醒的是這一步不要放在排查的第一步去做。原因很簡(jiǎn)單iptables 和 IPVS 規(guī)則非常多在沒(méi)確認(rèn) endpoints 正常之前去看規(guī)則等于大海撈針。而且 kube-proxy 的規(guī)則本身就是根據(jù) endpoints 生成的endpoints 是空的規(guī)則自然也是空的endpoints 正常規(guī)則大多也正常。在這一步你還可以做一個(gè)快速的連通性測(cè)試。找一個(gè)集群節(jié)點(diǎn)直接 curl Service 的 ClusterIPcurl http://ClusterIP:port如果這個(gè)都不通而直連 Pod IP 又是通的再考慮是不是 kube-proxy 的問(wèn)題。有一種比較少見但真實(shí)存在的情況endpoints 變化后kube-proxy 規(guī)則刷新有延遲或者卡住了。這時(shí)候解決辦法通常是刪除并重建一個(gè) Pod強(qiáng)制觸發(fā) endpoint 刷新極端情況下重啟 kube-proxy 也能解決。3.4 修復(fù)操作兩種典型場(chǎng)景的改法定位到根因之后修改通常很簡(jiǎn)單但操作過(guò)程中有一些細(xì)節(jié)需要注意。場(chǎng)景一命名端口大小寫不一致。Service 里寫的是spec: ports: - port: 8080 targetPort: HTTP而 Pod 里聲明的是ports: - containerPort: 80 name: http解決辦法是把 Service 的targetPort改成http或者把 Pod 里的端口名改成HTTP。修改 Service 是動(dòng)態(tài)生效的改完之后 endpoint 會(huì)立刻重建不用重啟任何 Pod。場(chǎng)景二targetPort 寫的是數(shù)字端口但和容器實(shí)際監(jiān)聽端口不一致。Service 里spec: ports: - port: 8080 targetPort: 8080容器實(shí)際監(jiān)聽的是 80 端口ports: - containerPort: 80這種情況要改 Service 的targetPort為 80或者改容器監(jiān)聽的端口為 8080取決于業(yè)務(wù)約定。如果改 Pod 配置記得是修改 Deployment 的模板然后滾動(dòng)更新而不是直接改運(yùn)行中的 Pod否則 Pod 重建后配置就沒(méi)了。我個(gè)人的一個(gè)建議是能用數(shù)字端口就用數(shù)字端口簡(jiǎn)單直接不依賴containerPort的聲明如果團(tuán)隊(duì)規(guī)范要求解耦就必須使用命名端口并且把命名規(guī)則寫進(jìn)規(guī)范避免“HTTP”和“http”這種低級(jí)問(wèn)題反復(fù)出現(xiàn)。4. 常見問(wèn)題速查表與避坑經(jīng)驗(yàn)4.1 癥狀-根因-解法速查表實(shí)戰(zhàn)里遇到的情況多種多樣我整理了一張速查表做二次排障的時(shí)候?qū)χ匆谎勰苁〔簧贂r(shí)間。癥狀最可能根因快速確認(rèn)方法解法資源正常SVC訪問(wèn)不通Endpoints為空targetPort是命名端口但Pod里無(wú)同名端口或大小寫不一致describe svc對(duì)比TargetPort與Pod端口名修正端口名或改用數(shù)字端口Endpoints有IP但訪問(wèn)不通直連PodIP也不通容器進(jìn)程沒(méi)監(jiān)聽對(duì)應(yīng)端口或監(jiān)聽地址為127.0.0.1exec進(jìn)Pod執(zhí)行netstat/ss改應(yīng)用監(jiān)聽0.0.0.0改containerPort聲明Endpoints有IP直連PodIP通ClusterIP不通kube-proxy規(guī)則刷新異常或延遲節(jié)點(diǎn)上curl ClusterIP檢查iptables/ipvs刪掉重建Pod觸發(fā)endpoint刷新必要時(shí)重啟kube-proxy只有NodePort不通ClusterIP正常節(jié)點(diǎn)端口被占用或安全組未放行檢查nodePort占用檢查安全組調(diào)整nodePort端口配置安全組放行headless Service訪問(wèn)不通繞過(guò)了kube-proxy直接走Pod IPdig解析域名直連解析出的Pod IP按Pod IP不通的方向排查多容器場(chǎng)景下命名端口聲明在錯(cuò)誤容器targetPort匹配到了sidecar容器端口查看Pod內(nèi)多個(gè)容器端口名將containerPort聲明調(diào)整到正確的容器Service的protocol和業(yè)務(wù)實(shí)際協(xié)議不一致TCP/UDP不匹配確認(rèn)業(yè)務(wù)實(shí)際使用的協(xié)議修改Service的protocol字段4.2 讓這類問(wèn)題少發(fā)生的幾條工程習(xí)慣排查是事了但反復(fù)踩同一個(gè)坑就是工程管理的問(wèn)題了。我歸納了幾條實(shí)際操作中驗(yàn)證過(guò)的經(jīng)驗(yàn)。第一嚴(yán)格約定端口命名規(guī)則。如果團(tuán)隊(duì)決定使用命名端口就一定要在小寫、短橫線分隔的規(guī)范上達(dá)成一致。寫 Service 的人、改 Pod 模板的人、負(fù)責(zé)評(píng)審的人都要清楚targetPort是大小寫敏感的。這個(gè)問(wèn)題在 CI/CD 流程里很容易被忽視因?yàn)?YAML 校驗(yàn)通常只檢查語(yǔ)法不檢查端口名是否真的存在。第二區(qū)分“Pod 狀態(tài)正?！焙汀皯?yīng)用可用”是兩碼事。Kubernetes 里的 Running 只說(shuō)明容器起來(lái)了不代表業(yè)務(wù)就緒。排查端口不通問(wèn)題時(shí)先看kubectl get pod輸出的 READY 列確認(rèn)前面的數(shù)字和容器數(shù)一致。如果Running 但 0/1 Ready說(shuō)明探針沒(méi)通過(guò)endpoint 也不會(huì)掛到 Service 上這同樣會(huì)表現(xiàn)為“資源正常但端口不通”。第三做好端口連通性監(jiān)控。Kubernetes 平臺(tái)自己有健康檢查還不夠最好在集群外部加一層黑盒監(jiān)控比如定時(shí)從測(cè)試機(jī)去撥測(cè) Service 的端口或者用 Prometheus Blackbox Exporter 做 TCP 探測(cè)。只有業(yè)務(wù)視角的監(jiān)控才能在你睡覺的時(shí)候幫你從“Pod 還活著但服務(wù)掛了”的假象里醒過(guò)來(lái)。第四排障順序固化下來(lái)。我現(xiàn)在遇到端口不通心里默認(rèn)走的流程是先看 READY 列再 exec 到 Pod 里確認(rèn)監(jiān)聽再查 Endpoints再查 Service 的 targetPort最后才考慮 kube-proxy 和網(wǎng)絡(luò)插件。這套順序能把 90% 的“端口不通但資源正?！眴?wèn)題在十分鐘內(nèi)定位。4.3 一個(gè)容易被忽略的“假端口”陷阱最后單獨(dú)提一個(gè)小眾但真實(shí)發(fā)生過(guò)的場(chǎng)景有些業(yè)務(wù)進(jìn)程監(jiān)聽的端口是 IPv6 地址比如監(jiān)聽在[::]:8080而 Kubernetes 的網(wǎng)絡(luò)路徑走的是 IPv4。從 IPv4 角度看去這個(gè)端口是“不存在”的因?yàn)?netstat 里可能看到tcp6而不是tcp。某些語(yǔ)言或框架默認(rèn)綁定到 IPv6 時(shí)會(huì)同時(shí)支持 v4-mapped 地址但并非所有框架都會(huì)這樣做。真遇到這種情況去容器里執(zhí)行cat /proc/net/tcp /proc/net/tcp6對(duì)比 IPv4 和 IPv6 的監(jiān)聽情況很快能找到答案。解決辦法是改應(yīng)用的監(jiān)聽配置明確綁定到0.0.0.0。我個(gè)人在實(shí)際操作中的體會(huì)是這類“端口不通但資源都正?！钡膯?wèn)題最大的困難從來(lái)不是技術(shù)本身而是心理上的“它看起來(lái)沒(méi)事”帶來(lái)的迷惑感。資源指標(biāo)正常、Pod 沒(méi)崩、日志干凈太容易讓人把注意力引向網(wǎng)絡(luò)層。但只要耐住性子按“Pod 內(nèi)監(jiān)聽 → Endpoints → Service targetPort → kube-proxy 轉(zhuǎn)發(fā)”的順序一步步排除幾乎都能在十分鐘內(nèi)把根因揪出來(lái)。最后再分享一個(gè)小技巧我寫 Service 時(shí)習(xí)慣在targetPort上直接使用命名端口并且把 Pod 的containerPort名字寫進(jìn)注釋里。這個(gè)習(xí)慣看起來(lái)不起眼但配合代碼評(píng)審能從源頭攔住一大批大小寫不一致、端口名對(duì)不上的問(wèn)題。如果你現(xiàn)在正被端口不通的問(wèn)題折磨先別急著重啟 Pod花兩分鐘看一眼kubectl get endpoints很多時(shí)候答案就擺在那里。