全部產品
Search
文件中心

:ALB Ingress FAQ

更新時間:Jun 19, 2024

本文匯總了使用ALB Ingress時遇到的常見問題。

索引

為什麼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 edit命令直接更新資源的配置。如果必須使用kubectl apply命令來更新資源,請在執行kubectl apply命令之前先執行kubectl diff命令預覽變更點,確保變更符合預期,然後再使用kubectl apply命令將變更應用到Kubernetes叢集。

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權重

說明

從v2.13.1-aliyun.1版本開始,ALB Ingress Controller支援自動化佈建節點權重。請確保您升級到最新版本以使用此功能。更多資訊,請參見升級ALB Ingress Controller組件

本文以一個樣本說明,在安裝了Flannel外掛程式的叢集中,當Service設定為Local模式時,Node權重的計算方式。如下圖所示,樣本中業務Pod(app=nginx)部署在三台ECS上,通過Service A對外提供服務。

Service後端Pod的總數量

描述

Pod數量 <= 100個

ALB Ingress Controller會將每個節點上的Pod數量作為該節點的權重。

例如:如上圖所示,三台ECS的Pod數量為1、2、3,則相應的ECS權重被設定為1、2、3。因此,流量將以1:2:3的比例分配至這三台ECS上,從而實現更均衡的Pod負載分配。

Pod數量 > 100個

ALB Ingress Controller將根據Node上部署的Pod數量占Pod總數的百分比計算Node權重。

例如:若上圖中三台ECS上的Pod數量分別為100、200、300,則相應的ECS權重被設定為16、33、50。因此,流量將依照16:33:50的比例分配到這三台ECS上,以達到更平衡的Pod負載分布。