Container Compute Service：ALB Ingress FAQ

索引

• 為什麼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流量管理方式和高效能的網關服務。

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版和ACS託管了ALB Ingress Controller組件，因此無法在叢集中看到ALB Ingress Controller Pod。

如何保證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的形式儲存在叢集的API Server中。在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參數是否正確。具體資訊，請參見通過ALBConfig配置ALB執行個體。

在控制台上配置完建立的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對外提供服務。