索引

• 為什么ALB Ingress規則不生效？

• ALB Ingress和Nginx Ingress有什么區別？

• ALB后端默認監聽轉發到kube-system-fake-svc-80服務器組，該服務器組的作用是什么?

• ALB Ingress是否支持同時使用公網和私網？

• 為什么在集群中看不到ALB Ingress Controller Pod?

• 如何保證ALB Ingress使用固定的ALB域名？

• 創建ACK托管版集群時選擇使用ALB Ingress，是否會自動創建ALB實例？

• 為什么在ALB控制臺手動變更的配置會丟失，并且添加的規則會被刪除，訪問日志會被關閉？

• ALB Ingress轉發規則創建后被立即刪除，出現503狀態碼怎么辦？

• ALB Ingress無異常事件，但是變更不生效怎么辦？

• 在控制臺上配置完創建的ALB實例后，使用kubectl apply命令更新AlbConfig的ACL（訪問控制列表）配置，為什么會導致部分監聽被刪除？

• 如何優化Service中Pod變配場景下的Server調諧時間？

• 在使用Flannel網絡插件且Service配置為Local模式時，如何自動分配Node權重？

為什么ALB Ingress規則不生效？

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

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

ALB Ingress和Nginx Ingress有什么區別？

推薦您使用ALB Ingress，相較于Nginx Ingress需要您自己運維，ALB Ingress基于阿里云應用型負載均衡ALB（Application Load Balancer），屬于全托管免運維的云服務，提供了更為強大的Ingress流量管理方式和高性能的網關服務。關于Nginx Ingress與ALB Ingress的對比詳情，請參見Nginx Ingress、ALB Ingress和MSE Ingress對比。

ALB后端默認監聽轉發到kube-system-fake-svc-80服務器組，該服務器組的作用是什么?

創建監聽必須有一個默認轉發規則，并且轉發規則目前只支持轉發到某個服務器組。所以，當前需要通過創建kube-system-fake-svc-80服務器組實現監聽功能。該服務器組不參與業務處理，但不能被刪除。

ALB Ingress是否支持同時使用公網和私網？

支持。如果您想同時使用公網和私網訪問ALB Ingress，您需要創建公網ALB實例，該實例會在每個可用區創建一個公網EIP，ALB實例可以通過EIP與公網通信。同時，該實例還會提供一個私網VIP，您可以通過私網VIP訪問ALB實例，實現從私網訪問的效果。如果您只想私網訪問ALB Ingress，建議您創建一個私網ALB實例。

為什么在集群中看不到ALB Ingress Controller Pod?

僅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版。

如何保證ALB Ingress使用固定的ALB域名？

通過ALBConfig創建ALB實例之后，ALB Ingress會通過IngressClass引用ALBConfig，從而使用對應的ALB實例域名。如果ALB Ingress關聯的IngressClass以及ALBConfig不做變更，則域名保持不變。

創建ACK托管版集群時選擇使用ALB Ingress，是否會自動創建ALB實例？

不會。創建ACK托管版集群時選擇ALB Ingress，將會安裝ALB Ingress Controller，并不會自動創建ALB實例。

為什么在ALB控制臺手動變更的配置會丟失，并且添加的規則會被刪除，訪問日志會被關閉？

ALB Ingress需要通過修改集群內資源來實現配置變更，相應的配置會以ALB Ingress或ALBConfig的形式保存在集群的APIServer中。在ALB控制臺手動修改配置的行為并沒有修改APIServer中的資源，所以修改的配置并不會生效。如果觸發集群內調和操作，就會使用Ingress或ALBConfig中的配置對控制臺配置進行變更，導致出現手動修改的配置被覆蓋的現象。建議您通過修改ALB Ingress或AlbConfig來修改對應配置。

ALB Ingress轉發規則創建后被立即刪除，出現503狀態碼怎么辦？

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

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

ALB Ingress無異常事件，但是變更不生效怎么辦？

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

在控制臺上配置完創建的ALB實例后，使用kubectl apply命令更新AlbConfig的ACL（訪問控制列表）配置，為什么會導致部分監聽被刪除？

kubectl apply命令的語義會對ALBConfig進行覆蓋式更新。因此，在使用kubectl apply命令更新ALBConfig的ACL配置時，請確保YAML文件中包含了完整的監聽配置，以免未包含的監聽被刪除。

若執行kubectl apply命令后發現有監聽被刪除，推薦您按照以下方式進行恢復。

1. 查看YAML文件中是否指定了完整的監聽列表。

   若監聽列表中缺少被刪除的監聽，請執行下一步操作。否則，無需執行。

2. 執行以下命令，編輯對應的AlbConfig，將被刪除的監聽配置添加回來。

   kubectl -n <namespace> edit AlbConfig <albconfig-name> # 將<namespace>和<albconfig-name>分別替換為AlbConfig資源所在的命名空間和AlbConfig資源的名稱。

如何優化Service中Pod變配場景下的Server調諧時間？

在Kubernetes環境下，Service進行Pod擴縮容時，Server調諧時間的長短可能受到關聯的Ingress數量影響。為保證Server調諧效率，您可以采取以下措施：

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

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

在使用Flannel網絡插件且Service配置為Local模式時，如何自動分配Node權重？

本文以一個示例說明，在安裝了Flannel插件的集群中，當Service設置為Local模式時，Node權重的計算方式。如下圖所示，示例中業務Pod（app=nginx）部署在三臺ECS上，通過Service A對外提供服務。