AWS國際實名帳號 AWS EKS Ingress 建立後 ALB 未生成？AWS Load Balancer Controller 日誌排查

先看結果，不要先猜原因

在 EKS 裡建立 Ingress 之後，最讓人抓狂的不是報錯，而是「看起來一切都成功了，卻一直沒有 ALB 出現」。Ingress 物件存在、Service 也正常、Pod 狀態看起來沒問題，但 AWS 上就是沒有新的負載平衡器。這種情況通常不是單一問題，而是 AWS Load Balancer Controller 在某個步驟被卡住了，只是表面上沒有直接把錯誤丟給你。

AWS國際實名帳號 要解這種問題，第一個原則很簡單：不要只盯著 Ingress YAML，看控制器日誌、Ingress 事件、AWS 資源標籤，三者一起對。只要 ALB 沒生成，背後一定有一個或多個條件沒有滿足。控制器不會憑空幫你把 ALB 建起來，它需要能識別 Ingress、能操作 AWS API、能找到合適子網，也要能建立目標群組與安全組規則。任何一步不通，最後都會停住。

先確認控制器真的有在工作

很多人第一時間會改 Ingress 註解，或反覆刪除重建資源，但其實應該先確認 AWS Load Balancer Controller 本身有沒有正常運作。如果控制器都沒起來，Ingress 再乾淨也沒用。

kubectl get pods -n kube-system | grep load-balancer
kubectl logs -n kube-system deployment/aws-load-balancer-controller

如果 Pod 不在 Running，或日誌裡一直重啟，先處理部署問題。常見狀況包括映像版本不相容、Webhook 失敗、IRSA 綁定錯誤，甚至是控制器根本沒有成功連到 Kubernetes API。控制器不健康時，Ingress 事件通常只會很安靜，或延遲很久才顯示異常。

接著看 Ingress 本身的事件，這一步非常關鍵，因為 Kubernetes 常常會把最直接的錯誤放在事件裡。

kubectl describe ingress -n <namespace> <ingress-name>

你要找的不是是否有建立成功的字樣，而是 Warning、FailedBuildModel、FailedDeployModel、Reconciler error 這類訊息。只要這裡出現錯誤，通常就能把排查方向縮小很多。

最常見的第一關：Ingress Class 沒對上

現在的 AWS Load Balancer Controller 通常是靠 ingressClassName 或舊式註解來判斷由誰接手。如果你建立的 Ingress 沒有被控制器認領，它就會像沒看到一樣，自然不會生成 ALB。

你可以先檢查 Ingress 是否指定了正確的 class。很多團隊會在叢集中同時存在多個 Ingress Controller，例如 NGINX、ALB、甚至舊版本的 AWS ALB Ingress Controller。如果 class 名稱沒對齊，資源就會被錯的控制器忽略。

kubectl get ingressclass
kubectl describe ingress -n <namespace> <ingress-name>

如果日誌裡看到類似「ignoring ingress because class does not match」或「no matching ingress class」，問題就很明確了。修正方式是統一 ingressClassName，不要一邊用註解、一邊用新欄位，結果互相打架。若你的版本支援，建議直接使用 ingressClassName，可讀性也更好。

日誌裡最值錢的訊息：權限、子網、標籤

如果 Ingress 已經被接手，但 ALB 還是沒出來，下一步看控制器日誌。大多數真正有價值的線索，都藏在這裡。常見卡點可以分成三類：IAM 權限不足、找不到合適子網、資源標籤不符合規則。

1. IAM 或 IRSA 權限不足

AWS Load Balancer Controller 需要呼叫 ELB、EC2、IAM 等 AWS API。如果它使用的 IAM Role 權限不完整，就會在建立 ALB、Target Group、Security Group rule 時失敗。這種錯誤通常會在日誌中看到 AccessDenied、UnauthorizedOperation、not authorized to perform 之類的字樣。

很多人以為裝上官方文件裡的政策就夠了，但實務上最常出問題的是 IRSA 綁錯 ServiceAccount、Namespace 不對、Role 信任關係設定錯誤，導致控制器拿不到預期的身份。你應該確認兩件事：Pod 真的用到那個 ServiceAccount，IAM Role 的 trust policy 也真的允許該 ServiceAccount 扮演。

kubectl get sa -n kube-system aws-load-balancer-controller -o yaml

如果角色沒綁上，控制器在日誌裡常會直接寫出取得憑證失敗，或 AWS API 回應 AccessDenied。這一類錯誤不會因為你重建 Ingress 而消失，必須先修權限。

2. 子網沒有被正確辨識

ALB 要建立在哪些子網，控制器有明確規則。通常子網必須有正確標籤，讓控制器知道哪些是可用於 internet-facing，哪些是 internal。若標籤不完整，或 VPC 裡有多個子網但不符合條件，控制器會找不到可用資源。

典型日誌會出現「could not find subnets」「unable to resolve suitable subnets」「subnet tagged for cluster not found」這類訊息。這時候不要急著改 Ingress，應該回頭看 VPC 子網標籤。對公網 ALB，子網通常需要符合公開子網的標記；對內部 ALB，則需要私有子網標記。若你在多可用區部署，也要確保至少有足夠的子網分布，不然控制器會因為容災條件不足而拒絕建立。

還有一個很常被忽略的點，是子網上的資源標籤被別的團隊改掉了。很多環境不是一開始就壞，而是網路團隊重整 VPC 後，原本給控制器辨識的 tag 不見了。這種問題的特徵就是：同樣的 Ingress 在別的環境可以，到了這個叢集就卡住。

3. Annotation 與期望行為不一致

Ingress 的 annotation 決定 ALB 的多數行為，例如 scheme、target-type、listen-ports、certificate、group.name 等。只要其中一個設定和實際環境衝突，就可能導致建立失敗。

例如：

• scheme 設成 internet-facing，但子網卻只有私有子網。
• target-type 設成 instance，但 Service 或節點安全組不允許流量。
• 使用 HTTPS 卻沒有正確的憑證 ARN。
• 多個 Ingress 共用 group 時，規則互相衝突。

這些問題不一定直接讓 ALB 完全不生成，有時候是生成到一半失敗，最後只留下模糊的日誌。這也是為什麼控制器日誌要搭配 Kubernetes 事件一起看。若事件顯示模型建立失敗，而日誌又提到某個 annotation 值無效，基本上就能直接定位。

從日誌判讀問題，而不是只看錯誤字面

AWS Load Balancer Controller 的日誌看起來很長，但真正有用的是它在描述哪一個 reconcile 階段失敗。你可以把流程理解成幾步：先讀取 Ingress，再組裝模型，接著查子網與安全組，然後呼叫 AWS API 建立 Load Balancer、Target Group、Listener，最後寫入規則。

如果錯在前半段，通常表示 Ingress 定義有問題；如果錯在後半段，通常是 AWS 資源或權限問題。

以下是幾個常見訊號與方向：

• no matching ingress class：控制器根本沒接手。
• failed to build model：Ingress 內容或註解有問題。
• AccessDenied：IAM 或 IRSA 權限不足。
• could not find subnets：子網標籤或 VPC 選擇錯誤。
• failed to ensure load balancer：建立 ALB 時 AWS API 層出錯。
• failed to ensure target group：Service、Port 或 health check 設定有問題。

看日誌時，不要只抓最後一行。往前看幾十行，通常能看到更完整的上下文。例如某次錯誤看似是建立 ALB 失敗，但前面其實早就寫明子網找不到；只是後面的總結訊息比較籠統，容易讓人誤判。

不要忽略 Service 和 Target Group 的對應

很多人以為 Ingress 只要寫對 host 和 path 就夠了，實際上它最終還是要轉到某個 Service。Service 的 port、targetPort、selector 只要有一項對不上，Target Group 就可能無法健康檢查成功，甚至在建立階段就出現問題。

AWS國際實名帳號 如果你使用 target-type: ip，控制器會把 Pod IP 直接註冊到 Target Group，這要求 CNI、網路路由與安全組都能配合。如果你使用 instance，則是註冊節點，節點安全組必須允許來自 ALB 的流量。兩種模式的問題點完全不同，不要混在一起查。

AWS國際實名帳號 當 ALB 建立成功，但後續流量還是不通時，可以再看 Target Group 的健康狀態。不過如果你的問題是「根本沒有生成 ALB」，那麼 Service 與 Target Group 的設定多半是第二層問題，前提還是控制器有沒有完成建立流程。

一套實用的排查順序

遇到 ALB 沒生成，不要亂槍打鳥。最有效的順序通常是這樣：

1. 先看 Ingress 是否被正確的 controller 接手。
2. 看 Ingress 事件，抓第一個明確錯誤。
3. 看控制器日誌，確認是權限、子網、annotation 還是 AWS API 問題。
4. 確認 IAM Role 與 IRSA 綁定是否正確。
5. 確認 VPC 子網標籤、可用區分布與 scheme 設定一致。
6. 確認 Service 端口、健康檢查與 target-type 是否匹配。
7. 最後再看安全組和路由表。

如果你一開始就改 YAML 然後重建資源，很容易把原始錯誤洗掉，排查成本反而更高。正確做法是先固定版本與配置，再從日誌和事件倒推問題點。只要記住一件事：控制器不會無條件替你完成建置，它是在嚴格檢查每個前置條件。

實戰中最常見的幾種情境

第一種情境是控制器日誌安靜，Ingress 事件也沒內容。這通常代表 Ingress 根本沒被選中，優先檢查 class。第二種情境是有 reconcile 動作，但總在某一步失敗，這時看日誌中的關鍵字最有效。第三種情境是 ALB 建立過一次，之後又被刪掉或重建失敗，這往往和標籤、子網或權限回收有關。

AWS國際實名帳號 還有一種很隱晦的狀況：叢集中存在舊版 AWS ALB Ingress Controller 的殘留設定，或者同時裝了其他 Ingress Controller。這會讓某些 Ingress 被錯誤接手，結果你以為是 AWS 沒反應，其實是流量規則落到別的控制器上。這種問題通常要從 kubectl get ingressclass 與控制器部署設定一起看，不能只看單一物件。

最後該怎麼避免再次踩坑

這類問題最好不是等出事才修，而是把檢查點前置到部署流程裡。建立 Ingress 之前，先確認三件事：控制器安裝完成、IRSA 權限完整、子網標籤正確。接著在 Git 或 CI 裡統一管理 Ingress 模板，避免不同團隊各自加註解，最後產生衝突。

如果你的環境經常變動，建議把常見檢查做成標準作業：

• 固定 ingressClassName，避免混用多套控制器。
• 明確標示內外網 ALB 的子網規則。
• 每次調整 IAM 或 IRSA 後，順手驗證控制器日誌。
• 建立 Ingress 後立刻看事件，不要等到前端同事回報才查。
• 對 target-type、health check、Service port 做統一模板。

ALB 沒生成，表面上是「沒反應」，本質上卻是控制器已經在替你做判斷，只是某個條件沒有過。只要你學會從日誌、事件、AWS 資源三個面向同步觀察，這類問題其實很好定位。下次再遇到 Ingress 建好了卻沒有 ALB，不要急著重裝控制器，先看它到底卡在哪一步，通常答案就在那幾行日誌裡。