AWS國際帳號代理 AWS EKS負載平衡配置錯誤排查

引言：錯誤不會憑空出現

在 EKS 上做負載平衡，最容易踩的坑往往不是「元件壞了」，而是「配置之間沒有對齊」。你以為自己已經把 Service 指定好了、也加了 Ingress，結果外部流量卻進不來；或者能通，但偶發 502/504；又或者負載在不同節點之間分佈很怪。這些表面現象，看似問題很多，其實背後通常只圍繞幾條主線：流量從哪裡進來、怎麼路由到 Pod、誰在判斷目標是否健康、以及安全層是否允許。

下面的文章會用「排查思路」串起整個過程：先判斷問題屬於哪一段鏈路，再逐步收斂。你不需要先熟悉所有 AWS 細節，也能用文中的檢查順序把問題定位到原因。

第一章：先分辨症狀，決定你該查哪裡

排錯最怕直接開查一堆指令，結果越查越散。你可以先把現象歸類，選擇對應的檢查路線。

1. 外部看得到 Load Balancer，但打不通

常見情況是：ALB/NLB 有建立，但外部 DNS 解析到地址後連不上，或連上立刻重置。這通常和 Listener/Rule、目標群組與健康檢查、以及安全群組/網路 ACL 有關。

AWS國際帳號代理 2. 能連上，但回傳 502/504

這種「半通」往往意味著：負載設備把流量轉發了，但後端服務不可用或被判為不健康。你需要優先看 Target 健檢失敗、Pod 實際是否在正確端口啟動、以及 Readiness/Liveness 影響。

3. 只在某些請求或某些路徑失敗

可能是 Ingress 的 Path/Host 規則與實際需求不一致，或是多條規則的優先順序導致匹配到錯誤的目標組。也可能是重寫規則不正確（例如路徑被截斷）。

4. 流量進來了，但 Pod 幾乎不接收

這常見於 selector 錯誤、Service 沒選到目標 Pod、或 Deployment/ReplicaSet 沒有真正就緒。還有一種常見情況是：Service 的 port 與 targetPort 對不準。

第二章：建立一張「流量走向圖」

你不用真畫圖，但要在心裡把鏈路拆開。對於典型 AWS EKS 負載平衡流程，可以簡化成下面幾段：

• 外部使用者 → ALB/NLB（Listener/Rules）
• ALB/NLB → Target Group（健康檢查判斷）
• Target Group → Node 或 Pod（依設定而定）
• Pod → 應用服務（端口/路徑/回應）
• 安全群組 → 規則是否允許流量穿透

只要你確認每段的「輸入與輸出」是否符合，就能快速鎖定出問題的環節。下面逐段講。

第三章：Service 檢查：先確認「選對人」和「對上端口」

很多負載平衡錯誤，追根究底是 Service 沒選到正確的 Pod，或端口映射錯誤。先把這層打穩，後面才談 ALB/NLB。

1. 檢查 selector 與 Pod labels 是否一致

Service 通常透過 selector 找到 Pod。你可以先查 Service 的 selector：

kubectl get svc -n <ns> <svc> -o yaml

然後檢查目標 Deployment 的 labels：

kubectl get deploy -n <ns> <deploy> -o yaml

重點在兩個方向：Service 的 selector 是否能匹配到 Pod 的 labels；以及 Pod 是否真的存在。你也可以直接看 endpoints 是否有填充：

kubectl get endpoints -n <ns> <svc>

如果 endpoints 是空的，外部負載再怎麼配置都沒有用。

2. 檢查 port / targetPort / protocol

Service 的 port 是給集群外部或負載設備使用的端口；targetPort 才是 Pod 上真正接收流量的端口。常見錯誤是：

• port 配對了 80，但容器其實在 8080
• targetPort 寫成了錯誤名字或錯誤數字
• protocol（TCP/UDP）與應用不一致

你可以查看 Pod 的容器端口：

kubectl get pod -n <ns> <pod> -o yaml | grep -A3 -B2 ports

若你使用了 readinessProbe，也要確認探測的是正確端口和路徑，因為「就緒」不代表「容器啟動」，但負載在某些情境會依就緒狀態判斷能不能接流量。

3. 確認 Service 類型與預期一致

常見路線是：

• Service 設為 ClusterIP，由 Ingress 或 AWS Load Balancer Controller 接手
• 或使用 LoadBalancer 讓 AWS 自動建立 LB（但在 EKS 上你也要注意建立方式是否符合預期）

如果你預計用 ALB/NLB Controller 管，卻把 Service 配錯類型或 annotation，結果可能導致「看似有資源、但實際沒有連到你要的目標」。

第四章：Ingress/Controller 層：規則匹配與註解是高頻雷點

當你使用 Ingress（配合 AWS Load Balancer Controller 或 ALB 方案）時，錯誤通常出在兩件事：規則沒有匹配、以及註解把你引到錯的資源行為。

AWS國際帳號代理 1. Host / Path 是否真能匹配

很多人只測了其中一種路徑或某個 Host，結果實際使用時 Host 不同就匹配不到。你可以直接看 Ingress：

kubectl get ingress -n <ns> <ing> -o yaml

確認：

• 規則的 host 是否包含你實際訪問的網域
• pathType 是否符合你的路徑期望（例如 Prefix vs Exact）
• 是否有多條規則互相競爭

若你看到 ALB 的 Listener Rule 只是一組看起來合理但不對的條件，就要回到 Ingress 規則檢查。

2. 註解（annotations）是否一致且版本兼容

ALB/NLB Controller 常靠 annotation 控制行為，例如：

• 選擇是 internet-facing 還是 internal
• 指定 target-type（instance 或 ip）
• 設定安全群組、子網路
• 設定健檢協定與路徑

常見錯誤是：annotation 寫了，但 Controller 版本不支援該鍵，導致你以為生效但其實沒有。另一種錯誤是：你在某個地方改了註解，卻沒有觸發更新或資源替換，造成 ALB 仍沿用舊設定。

3. Ingress 類型與預期要對上

例如你期望是 ALB，卻使用了某些導致配置走向不同 LB 類型的方案；或你在 Ingress class 的指定上不一致，讓流量沒有交由正確 Controller 處理。這類錯誤通常不會讓資源消失，但會讓「你以為的規則」沒有落實到 AWS。

第五章：ALB/NLB 與 Target Group：健康檢查是判斷核心

只要你記住一句話就夠：負載器不把流量送到不健康的目標。因此，你要把時間花在 Target Group 的狀態，而不是一直盯著 Pod 日誌。

1. Target 類型：instance 還是 ip

這是排查負載平衡錯誤時最關鍵的分歧之一。若 target-type 設為：

• instance：目標是 Node，健檢與轉發會以節點層面為基礎；這要求節點上的對應端口/路徑符合預期，且安全群組允許。
• ip：目標直接是 Pod IP，健檢與轉發更精準，但也更要求網路與安全群組設定到位。

若你在兩者間混用（例如期待 ip，但實際是 instance），你會看到健康狀態始終不通，或部分路徑可用但其他不可用。

2. 健檢路徑與端口是否存在

Target Group 的健康檢查會頻繁失敗，常見原因：

• 健檢路徑寫錯（例如應用實際是 /healthz，但你配置 /health）
• 健檢 port 對不上容器端口或 Service targetPort
• 應用需要特定 Header 或路徑前綴（簡單健檢卻返回 404/403）

AWS國際帳號代理 你可以把健檢行為落地測試：確保從 Pod 內部能打到健檢路徑，並回應 200/預期碼。很多人只看應用能正常跑，卻忘了健檢要求是「穩定且固定」，不是「有時候能通」。

3. 健檢的期望回應碼

有的應用健康檢查返回 204 或 302，你卻把 Target Group 的 matcher 設為只接受 200。結果就是永遠不健康。這類問題尤其常見於你自己改過應用回應碼後，忘了同步更新 LB 健檢設定。

4. 權重與多目標組：不要只看可用性，還要看分配

當你有多個目標群組（例如藍綠部署或多環境），權重和路由規則會影響你實際打到哪一組 Pod。你可能會覺得「負載平衡壞了」，其實是規則把流量導向你尚未就緒的那組。

第六章：安全群組與網路：通不通常在這裡

AWS國際帳號代理 即使所有 Kubernetes 與 Ingress 都正確，只要安全群組（SG）或網路規則不允許，流量仍會卡住。AWS 上排錯，常常是「應用是好的，但網路沒放行」。

1. ALB/NLB 的安全群組是否允許入站

外部流量進來時，ALB/NLB 的入站需要允許你用戶使用的端口（通常是 80/443）。若你設定 internal，來源也要對上 VPC 內流量來源與路由。

2. 目標端口（Node 或 Pod）是否被允許

如果 target-type 是 instance，你要允許的是 Node 對應的端口；如果是 ip，你要允許的是 Pod 所在網路對應的端口。很多人只看 ALB 的 SG，卻忽略了目標端安全群組需要接受來自 ALB SG 的流量。

3. 子網路與路由表

負載器選擇子網路時也有影響。ALB 通常需要跨至少兩個可用區（AZ）才能穩定。若你的子網路標籤或註解選到不包含期望資源的子網，你會遇到奇怪的可用性或健檢失敗。

4. 如果使用了 NetworkPolicy

某些團隊會在 Kubernetes 層使用 NetworkPolicy 控制 Pod 間流量。若健檢或代理連線被策略擋掉，會造成 LB 看起來「不健康」。排錯時要確認 NetworkPolicy 是否同時允許 LB 相關流量來源。

第七章：用一套「從快到慢」的排查流程收斂問題

下面給你一個實戰順序。你每一步都做到「要麼確認無誤，要麼立刻發現矛盾」，避免盲查。

步驟 1：確認外部是否真的命中負載器

先從使用者端或你自己的測試環境驗證：

• DNS 是否解析正確
• AWS國際帳號代理 連線是否到達 ALB（可以看連線是否超時還是回傳 4xx/5xx）

如果連線超時，多半是網路或 ALB 設定問題；如果能連上但 502/504，就優先看 Target health。

步驟 2：檢查 Ingress/Listener Rule 是否存在且匹配

在 AWS 控制台或通過描述資源，找到 Listener 與 Rule。核對：

• Host / Path 是否與 Ingress 一致
• Forward 指向的 target group 是否正確

如果 Rule 指向錯的 target group，你在 Kubernetes 端看再多都沒用，應該先改 Ingress 規則或註解。

步驟 3：進入 Target Group 看健康狀態

AWS國際帳號代理 這一步要「看狀態 + 看原因」。健康檢查失敗通常會有更具體的指示（例如連線失敗、超時、回應碼不符合）。你可以據此：

• 調整健檢路徑/端口/協議
• 檢查應用是否真的能在該路徑回應
• 檢查安全群組是否允許

步驟 4：回到 Kubernetes 確認 Pod 真的就緒且端口正確

檢查：

• Pod 是否 Running 且 Ready
• 容器端口與 Service targetPort 對得上
• readinessProbe 與健檢路徑是否一致（或至少能保證 LB 所需路徑可用）

如果 Pod Ready 其實正常，但 LB 仍不健康，通常是健檢與應用路徑或安全群組層不同步。

步驟 5：最後才檢查 selector、endpoints 與 Service 行為

如果你一路看下來發現 target group 其實有目標，但端口轉發不到，那可能是 endpoints 不正確或端口對不上。這一步通常最容易被忽略，卻能一次性解釋很多「看似配置正確但仍不通」的情況。

第八章：四個典型案例與修復策略

AWS國際帳號代理 下面用四個常見案例，把上面的原理落到具體修復。

案例一：Target group 永遠 Healthy = false

現象：ALB 正常建立，Listener 也 forward 到正確 target group，但 target 顯示不健康，外部回 502。你檢查 Target Group 的健檢設定，發現路徑是 /health，但應用實際是 /healthz。健檢回 404，因此被判定失敗。

修復策略：

• 更新健檢路徑到應用實際路徑
• 或調整應用回應，使健檢路徑返回符合預期碼
• 同步確認安全群組允許健檢端口流量

AWS國際帳號代理 案例二：只在 HTTPS 正常，HTTP 不通

現象：你訪問 https:// 能成功，http:// 超時或 403。這多半是 ALB Listener 設定或安全群組僅開了 443，沒有開 80。也可能是 Ingress 規則只對 443 配置或 HTTP 被重導向錯誤。

修復策略：

• 確認 ALB Listener 是否同時包含 80/443 或 HTTP 重導向是否正確
• 調整安全群組入站允許 80（如你要支援 HTTP）
• 如果要強制 HTTPS，確保重導向規則指向正確

案例三：部署後部分流量導向舊版，導致 504

現象：你發現新版本 Pod 還沒就緒或健檢未通，但規則已把部分權重導給新 target group；導致部分請求卡住。這是「流量切換與就緒條件不同步」造成。

AWS國際帳號代理 修復策略：

• 在切流前確認新版本 target group 已 Healthy
• 調整權重或先使用更保守的路由策略
• 確認 readinessProbe 與實際可服務狀態一致，避免假就緒

案例四：端點有但服務仍不通（selector 對不上）

現象：你以為部署有 Pod，但 endpoints 其實是空的或只剩部分。外部回 502。檢查 Service selector 後發現 Deployment 的 labels 變更了，例如原本是 app=web，現在變成 app.kubernetes.io/name=web，但 Service 還停留在舊 selector。

修復策略：

• 更新 Service selector 或重新標注 Pod labels
• 確認 endpoints 正確填充
• 重新觀察 target group health 狀態是否同步改善

第九章：常見誤區與你可以避免的事

排查過程中，最容易浪費時間的是「以為查錯方向」。以下是幾個常見誤區：

• 只看 Pod 日誌，不看 Target health：LB 是否送流量往往由健康狀態決定，日誌不會直接告訴你原因。
• 忽略端口對應：port 與 targetPort 寫錯，會造成健檢或轉發都失敗。
• 把健檢視為形式：健檢路徑、回應碼、超時時間這些參數在現實中非常敏感。
• 改了註解沒觀察資源更新：Controller 有更新節奏，你需要確認 AWS 端真的落地。
• 預設安全群組不需要管：EKS 的網路權限很多時候比應用邏輯更先擋住你。

結語：把排錯變成可重複的流程

AWS EKS 負載平衡配置錯誤的排查，本質上是「把鏈路拆開」並逐段驗證。你不必猜，也不必一次性把所有參數都背起來。只要遵循：先確定外部是否命中負載器，再檢查 Listener 規則與 target group，最後回到 Kubernetes 端確認 Pod、Service 端口與 selector，安全群組則作為跨層的最後確認。當你把這套順序固定下來，排錯的時間會明顯縮短，錯誤也更容易被預防而不是被修補。

如果你願意再進一步，我建議你在團隊內建立一張「對照表」：你們常用的 Ingress 註解、target-type、健檢路徑、Service 端口映射、以及應用回應碼要求。下一次遇到類似問題，就不是臨場猜測，而是快速比對與精準修復。