Container Service for Kubernetes：ALB Ingress FAQ

問題現象

在實際業務情境中，既需要通過公網訪問 ALB Ingress，也希望通過私網進行訪問，但不清楚 ALB Ingress 是否支援同時滿足公網和私網訪問需求？

解決方案

支援。如果您想同時使用公網和私網訪問ALB Ingress，您需要建立公網ALB執行個體，該執行個體會在每個可用性區域建立一個公網EIP，ALB執行個體可以通過EIP與公網通訊。同時，該執行個體還會提供一個私網VIP，您可以通過私網VIP訪問ALB執行個體，實現從私網訪問的效果。如果您只想私網訪問ALB Ingress，建議您建立一個私網ALB執行個體。

問題現象

在叢集中尋找 ALB Ingress Controller Pod 時，發現 kube-system 命名空間下沒有相關的 Pod，無法通過常規方法查看ALB Ingress Controller 組件。

解決方案

僅ACK專有版才能在kube-system命名空間下看到ALB Ingress Controller Pod。ACK基礎版、ACK Pro版和ACK Serverless託管了ALB Ingress Controller組件，因此無法在叢集中看到ALB Ingress Controller Pod。關於ACK專有版升級到ACK Pro版的具體操作，請參見熱遷移ACK專有叢集至ACK託管叢集Pro版。

問題現象

需要將後端 Pod 以 IP類型的方式掛載到 ALB，但在預設配置下，Service 無法自動建立 IP類型的伺服器組，導致後端服務的流量分發受限。

解決方案

可以通過在 Service 的 annotations 中添加 alb.ingress.kubernetes.io/server-group-type: Ip 註解，實現為該 Service 建立 IP類型的伺服器組，從而支援以 IP 方式將後端 Pod 註冊到 ALB。

apiVersion: v1
kind: Service
metadata:
  annotations:
    alb.ingress.kubernetes.io/server-group-type: Ip
  name: tea-svc
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    app: tea
  type: ClusterIP

問題原因

• 503（Service Temporarily Unavailable）錯誤

  • 路由規則未匹配：請求路徑與Ingress實際配置的路由規則不符。

  • 後端無存活Pod：Service關聯的Pod全部未就緒或不存在，導致Endpoints對象為空白。

• 502（Bad Gateway）錯誤

  HTTP或HTTPS監聽接收到用戶端串連請求後，ALB由於無法正常將請求轉寄至Pod或無法從Pod收到響應，則會向用戶端發送HTTP 502 Bad Gateway狀態代碼。

• 404（Not Found）錯誤

  通常原因為已匹配Ingress中定義的路由規則，但與Pod中應用實際提供服務的URL不匹配。

更多HTTP錯誤碼說明，請參見ALB狀態代碼說明。

解決方案

1. 檢查Ingress狀態：執行kubectl describe ingress <ingress-name> -n <namespace>命令，查看Events部分是否有錯誤資訊。如出現類似listener is not exist in alb的事件，請在AlbConfig中建立Ingress資源所需的監聽。

   ...
   Events:
     Type     Reason                  Age     From     Message
     ----     ------                  ----    ----     -------
     Warning  FailedBuildModel        ****    ingress  listener is not exist in alb, port: 443, protocol: HTTPS
     Warning  FailedBuildModel        ****    ingress  listener not found for (443/HTTPS), with ingresses 1
   ...

2. 檢查後端Endpoints：執行kubectl get endpoints <service-name> -n <namespace>命令，確認ENDPOINTS欄位下有至少一個健康的Pod IP和連接埠。若為空白，則排查Service的selector是否與Pod的labels匹配，以及Pod是否處於Running狀態。

3. 檢查Pod狀態與日誌：先執行kubectl get pod -l <app=your-app> -n <namespace>命令，查看Pod運行狀態。擷取Pod名稱之後執行kubectl logs <pod-name> -n <namespace>命令，查看應用日誌是否有啟動失敗或處理請求的錯誤資訊。

4. 網路連通性測試：在Pod內或節點上嘗試curl後端Service的ClusterIP或Pod IP，驗證叢集內部服務是否可達。

問題原因

• ALB執行個體未監聽443連接埠：只配置了Ingress的TLS安全加密，但沒有建立對應的HTTPS:443監聽。

• 認證配置錯誤：Secret類型不是kubernetes.io/tls或IngressTLS，或者data中的tls.crt和tls.key內容不正確或不匹配。

• 認證更新不生效：在阿里雲認證中心更新了認證，但未更新AlbConfig中指定的認證ID，或未觸發自動探索認證調諧，導致ALB執行個體仍引用舊認證。

解決方案

1. 檢查監聽連接埠：執行kubectl describe albconfig <alb-name> -n <namespace>命令，檢查是否缺少spec.listeners.port: 443和spec.listeners.protocol: HTTPS配置。

2. 檢查Ingress配置：檢查Ingress的配置中是否缺少註解alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS": 443}]，該註解將Ingress關聯到HTTP和HTTPS監聽上。

3. 檢查Secret配置：檢查Ingress的配置中spec.tls的secretName欄位，確認引用了正確的Secret。執行kubectl get secret <secret-name> -n <namespace> -o yaml命令，確認Secret類型和資料完整性。

問題現象

建立 ALB Ingress 規則後，發現路由規則沒有按預期生效，無法正常轉寄到對應的後端服務。

問題原因

ALB執行個體是按照串列的方式維護路由規則。也就是說，如果多個ALB Ingress使用的是同一個ALB執行個體，那麼一個ALB Ingress配置有問題，其他的ALB Ingress變更都不會生效。

解決方案

如果您建立的ALB Ingress沒有生效，那麼有可能是之前建立的ALB Ingress發生了錯誤。您需要將錯誤的ALB Ingress修正為正確後，新建立的ALB Ingress才會生效。

問題現象

ALB Ingress 在配置變更或關聯 AlbConfig 後，未見例外狀況事件上報，但相關變更並未生效。

解決方案

當出現未執行AlbConfig相關的調和事件，或者變更事件沒有成功處理時，原因可能是IngressClass和AlbConfig的綁定關係錯誤。請按照使用文檔檢查IngressClass中指定的parameters參數是否正確。詳細操作，請參見使用IngressClass關聯AlbConfig與Ingress。

問題現象

ALB Ingress 轉寄規則建立後被立即刪除，導致服務訪問返回 503 狀態代碼，無法正常進行流量分發。

解決方案

檢查轉寄規則對應Ingress是否都配置了canary:true註解項。由於Canary灰階強制需要主幹版本才能引流，所以對於主幹版本的Ingress，不需要添加canary:true註解。關於如何使用ALB Ingress實現服務的灰階發布，請參見通過ALB Ingress實現灰階發布。

Canary灰階方式僅支援兩個Ingress且條件有限，推薦您使用自訂轉寄規則，使用更豐富的引流方案 。具體操作，請參見自訂ALB Ingress的轉寄規則。

問題現象

當訪問除 80 連接埠外的其他連接埠時，發現請求均無法正常串連。同時，AlbConfig 資源報出 “listener is not exist in alb, port: xxx” 錯誤，導致相關連接埠未能被監聽和轉寄流量。

解決方案

預設建立的 AlbConfig 僅包含連接埠 80 的監聽器。如果需要監聽其它連接埠，需要在 AlbConfig 中新增對應連接埠的監聽配置。具體操作請參見建立監聽。

問題現象

已在 AlbConfig 中配置了 HTTP 和 HTTPS 監聽連接埠，但實際訪問時，HTTP 和 HTTPS 連接埠均無法正常被監聽或轉寄，導致服務無法通過這兩個連接埠對外提供訪問。

解決方案

確認是否在 Ingress 資源的 annotations 中添加 alb.ingress.kubernetes.io/listen-ports 註解，指定 ALB Ingress 同時監聽 HTTP（80）和 HTTPS（443）連接埠。例如：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: https-ingress
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]' # 使用多個監聽時需要添加annotation使ALB Ingress正常工作。
spec:
  #...

為什麼在ALB控制台手動變更的配置會丟失，並且添加的規則會被刪除，訪問日誌會被關閉？

為什麼會在調諧過程中出現錯誤提示：Specified parameter array contains too many items, up to 15 items, Certificates is not valid？

在控制台上配置完建立的ALB執行個體後，使用kubectl apply命令更新AlbConfig的ACL（存取控制清單）配置，為什麼會導致部分監聽被刪除？

問題現象

在 Kubernetes 環境中，當 Service 關聯的 Pod 擴縮容時，Server 調諧過程耗時較長，影響業務彈性擴縮容的即時性。排查發現，調諧時間隨關聯 Ingress 數量增加而明顯變長。

解決方案

為提升 Server 調諧效率，可採取以下最佳化措施：

• 限制Ingress數量：同一個Service掛載的Ingress數不超過30條。

• 合并Ingress規則：當Ingress數量過多時，您可以將多個Service掛載在同一個Ingress下，然後通過在同一個Ingress資源下定義多條轉寄規則來提升Server調諧效能。

問題現象

在使用 Flannel 網路外掛程式且 Service 配置為 Local 模式的情境下，節點實際接收到的流量分布不均衡，導致部分節點負載偏高，未能實現期望的流量均衡。如何自動根據節點上的 Pod 數量為節點分配權重，從而實現更合理的流量分發。

解決方案

Flannel外掛程式的叢集中，當Service設定為Local模式時，Node權重的計算方式如下圖所示，樣本中業務Pod（app=nginx）部署在三台ECS上，通過Service A對外提供服務。