本文匯總了使用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
命令後發現有監聽被刪除,推薦您按照以下方式進行恢複。
查看YAML檔案中是否指定了完整的監聽列表。
若監聽列表中缺少被刪除的監聽,請執行下一步操作。否則,無需執行。
執行以下命令,編輯對應的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負載分布。 |