騰訊雲帳號充值辦理 騰訊雲 TKE Service 設定為 NodePort 卻無法通過公網訪問排查

先弄懂：NodePort 為什麼理論上能訪問

在 TKE 裡把 Service 設成 NodePort，Kubernetes 會把服務暴露到每一台節點的固定端口上。訪問路徑不是「Service 有 IP 就能直接上網」，而是「公網客戶端 → 節點公網 IP → NodePort → kube-proxy 轉發 → Pod」。所以只要其中一環不通，外部就會失敗。很多人一看到 Service 類型是 NodePort，就以為已經對外開放，其實還差得很遠。

默認情況下，NodePort 端口落在 30000 到 32767 之間。你在 YAML 裡寫的是 Service port，真正對外打的是 nodePort。這兩個端口不是一回事，搞混之後，排查會越查越亂。

騰訊雲帳號充值辦理 第一步：先判斷是「配置問題」還是「網路問題」

排查時最重要的是分清現象。不同現象，原因完全不同。

• 打到公網 IP 直接超時：優先看公網 IP、路由、安全組、防火牆。
• 返回 connection refused：多半是節點上的轉發沒生效，或後端 Pod 沒有真正接住請求。
• 能連上但返回 404、503 或業務錯誤：大概率是應用路由、健康檢查、請求頭、端口映射的問題。

這一步很關鍵。只要先把「連不通」和「連上但不對」分開，後面效率會高很多。

先看 Service 和 Endpoints

先確認 Service 本身沒有寫錯：

kubectl get svc -n 命名空間
kubectl describe svc 服務名 -n 命名空間
kubectl get endpoints -n 命名空間

重點看三件事：Service 類型是不是 NodePort，nodePort 是否在預期範圍內，Endpoints 是否有真實 Pod IP。如果 Endpoints 是空的，說明 Service 沒有選中任何就緒 Pod。這時外部訪問失敗不是公網問題，而是後端根本沒接上。

很多人會忽略 selector。Service 的 selector 如果和 Pod label 對不上，Endpoints 就會空。還有一種情況是 Pod 跑著，但 readiness probe 沒通，Pod 被判定為未就緒，也不會進入 Endpoints。

檢查 targetPort 和容器實際監聽端口

Service 轉發的是 targetPort，不是你在 Service 裡看到的 port。假設你的應用實際監聽 8080，但 Service 把 targetPort 寫成 80，外部當然打不進去。還有些應用只監聽 127.0.0.1，這種服務在容器內看似正常，從外部進來卻完全沒回應。容器裡的服務應該綁定 0.0.0.0，這一點很常見，也很容易被忽略。

第二步：確認節點真的有公網入口

NodePort 的名字裡有「Node」，意思就是它依賴節點本身的網路能力。如果你的 TKE 節點只有內網 IP，沒有綁定公網 IP 或 EIP，那麼 NodePort 只能在 VPC 內部訪問，從互聯網一定打不進來。

騰訊雲帳號充值辦理 這是騰訊雲 TKE 上最常見的誤區之一。很多人以為節點只要能出網，就代表也能被公網訪問。其實不是。出網和入網是兩回事。節點能訪問外面，不等於外面能直接訪問節點。

你要確認的不是「節點能不能上網」，而是「節點有沒有可被外部直接路由到的地址」。檢查方式很簡單：

• 在 TKE 控制台看節點是否有公網 IP 或 EIP。
• 如果節點沒有公網 IP，只用內網 IP 測 NodePort，外網訪問必然失敗。
• 如果節點有 EIP，也要確認你訪問的是這個 EIP，而不是集群內網地址。

第三步：安全組通常是罪魁禍首

在騰訊雲環境裡，安全組擋住 NodePort 的情況非常多。Service 已經配置好了，Endpoints 也正常，節點也有公網 IP，但就是超時，十有八九要查安全組。

NodePort 對外暴露的是一段端口，而不是單個端口。默認是 30000 到 32767。如果你修改過 Kubernetes 的 NodePort 範圍，安全組也要同步開放相應端口範圍。很多人只開了 80、443，卻忘了 NodePort 是一個高位端口，結果服務看起來已經暴露，實際上全被安全組攔在外面。

安全組排查要點

• 入方向是否放行 NodePort 端口或端口段。
• 來源地址是否限制得太死，只允許了某個辦公網段。
• 節點綁定的是哪個安全組，是否真的作用在承載 Pod 的工作節點上。
• 如果節點使用了多個網卡或多個安全組，是否存在規則衝突。

實戰裡最有效的判斷方式，是先臨時放開來源地址測試。如果一放開就通了，問題就不在 Service，而在安全組規則。測試完成後再收緊來源，避免把端口長期暴露給全網。

第四步：別忘了節點上的系統防火牆

安全組是雲上邊界，系統防火牆是主機內層邊界。兩者缺一個，NodePort 都可能失敗。尤其是自建節點、混合節點，或者從其他環境遷移過來的機器，firewalld、iptables、nftables 都可能攔住高位端口。

如果你用的是 Linux 節點，可以檢查 firewalld 是否開啟，或是否有明確拒絕 30000 以上端口的規則。這類問題的特點是：同一個節點上，用內網測試也不通，但換到其他節點可能又正常。這時候不要一直盯著 Service，先看主機層。

另外，某些安全加固腳本會改寫 iptables 規則，導致 kube-proxy 寫入的轉發鏈被打亂。表面上看節點還活著，實際上 kube-proxy 已經無法按預期做 NAT。

第五步：看 kube-proxy 和轉發規則有沒有問題

NodePort 的核心不是某個進程在固定端口上監聽，而是 kube-proxy 在節點上建立轉發規則，把打到 NodePort 的流量轉到對應的 Pod。也就是說，你在節點上用 ss -lntp 不一定能看到一個真正的監聽進程，這是正常的。

如果 kube-proxy 異常，或者節點上的轉發規則沒有同步成功，就會出現一種很麻煩的情況：Service 看起來正確，Pod 也就緒，但外部就是進不來。

建議檢查這些項目

• kube-proxy Pod 是否正常運行，是否有重啟、CrashLoopBackOff 或資源不足。
• 騰訊雲帳號充值辦理 節點上的 iptables 規則是否完整，是否存在被其他工具覆蓋的情況。
• 如果集群使用的是 IPVS 模式，是否有對應的 IPVS 規則。
• 節點是否存在網路異常，例如路由表錯誤、網卡抖動、內核參數被修改。

這一類問題通常不會只影響一個 Service，而是會影響多個 NodePort 或 ClusterIP 服務。若你發現不止一個業務一起出問題，就要提高對 kube-proxy 或節點網路層的懷疑程度。

第六步：Pod 就緒不代表應用一定真的可用

很多團隊只看 Pod 是 Running，就認為沒問題。其實還差一步：Pod 要真的能接住流量。

如果 readiness probe 配置錯了，Pod 可能一直不進入就緒，Service 沒有 Endpoints。反過來，如果 readiness probe 寫得太寬鬆，Pod 可能被標記為就緒，但應用內部其實還沒完成初始化，外部打過去就會報錯。

另外，容器執行的是 Web 應用，不代表它一定監聽在你想像的端口上。比如程序啟動參數變了，實際監聽 8081，但 Service 還指向 8080；或者應用只接受特定 Host 頭，外部直連時就回 403。這些都不是 NodePort 本身的問題，而是業務應用與 Service 定義不一致。

第七步：從不同測試結果反推問題位置

排查時最怕憑感覺。最有效的方法，是按照測試結果反推位置。

情況一：VPC 內能訪問，公網不能訪問

這通常說明 Service、kube-proxy、Pod 大概率都沒問題，問題集中在公網入口。優先查節點公網 IP、EIP、安全組和系統防火牆。

情況二：節點內網 IP 能訪問，Pod IP 不能訪問

這一般是應用本身或容器網路問題。要查容器監聽地址、端口、Readiness、NetworkPolicy，以及 Pod 自身是否有異常。

騰訊雲帳號充值辦理 情況三：NodePort 偶爾能通，偶爾不通

這種問題常見於多副本服務，但其中部分 Pod 不穩定，或者節點間網路不一致。也可能是後端 Pod 在滾動升級過程中，Endpoints 不斷變化，而外部流量恰好打到剛被摘除的後端。

情況四：返回 503 或超時，但端口能連上

說明前面的公網入口基本正常，問題更靠近應用層。這時候就別再糾結 NodePort 是否打通了，應該直接看應用日誌、依賴服務和業務邏輯。

騰訊雲帳號充值辦理 第八步：一套實用的排查順序

如果你希望少繞路，可以按下面的順序來。這套順序適合大部分 TKE NodePort 故障。

1. 確認服務類型是 NodePort，並記下真正的 nodePort。
2. 看 Endpoints 是否有值，Pod 是否 Ready。
3. 在集群內或節點上，用內網 IP 訪問 NodePort，確認轉發是否正常。
4. 確認節點是否有公網 IP 或 EIP。
5. 檢查安全組是否放行 NodePort 端口段。
6. 檢查節點防火牆、iptables、kube-proxy 狀態。
7. 最後再看應用本身的端口、監聽地址和日誌。

按照這個順序走，通常很快就能把問題定位到具體層級。不要上來就改 YAML，也不要一口氣重建服務。很多故障其實只是少開了一條安全組規則，或者節點根本沒有公網 IP。

騰訊雲 TKE 裡最容易忽略的幾個細節

除了前面那些通用原因，TKE 還有幾個很容易被忽略的地方。

• 節點池擴容後，新節點可能沒有和舊節點完全一致的安全組。
• 手工替換過節點或綁定過 EIP，常常會出現訪問地址寫錯的情況。
• 如果集群前面還有其他負載均衡、WAF 或 NAT 設備，流量路徑會更長，問題點也更多。
• 有些團隊在測試時用的是內網域名，正式訪問卻改成公網 IP，結果把網路層問題誤判成應用問題。

實際上，NodePort 最適合內測、臨時暴露或配合外層負載均衡使用。若是正式對外服務，通常還是建議配合 CLB、Ingress 或其他入口網關來承接流量。直接把 NodePort 暴露到公網，雖然簡單，但維護成本和風險都更高。

結語：別把 NodePort 當成「自動對外開放」

NodePort 只是 Kubernetes 提供的一種節點級轉發方式，不是公網服務開關。它要真正能被互聯網訪問，至少要同時滿足四個條件：Service 配置正確、Endpoints 存在、節點有公網入口、安全組與防火牆放行。少了任何一個，外部都可能打不進來。

在 TKE 裡排查這類問題，最有效的方法不是猜，而是按層拆解：先看 Service，再看 Pod，再看節點，最後看雲上網路邊界。把每一層都驗證一遍，問題通常很快就會現形。真正麻煩的從來不是 NodePort 本身，而是大家把「能暴露」和「能公網訪問」混為一談。