金絲雀發布指在原有部署版本可用的情況下，同時部署新版本應用作為金絲雀，測試新版本的效能。在保證整體系統穩定的情況下，協助您儘早發現問題和修複問題。本文介紹如何使用金絲雀模式增強升級穩定性。
前提條件
已建立ASM企業版或旗艦版執行個體，且版本為1.16.4.91及以上版本。具體操作，請參見建立ASM執行個體。
已建立ACK叢集，並添加叢集到ASM執行個體。具體操作，請參見添加叢集到ASM執行個體。
已部署Bookinfo應用。具體操作，請參見在ASM執行個體關聯的叢集中部署應用。
功能介紹
阿里雲Service MeshASM支援基於修訂與標籤的升級模式，以更穩定安全的方式執行新版本控制面的金絲雀升級。在新升級模式中，資料面的網格代理將與其使用的特定控制面版本相關聯。這使得新版本能夠以較低的風險在叢集中部署，直到您明確選擇之前，沒有代理串連到新版本。同時也允許逐漸將工作負載遷移到新的控制面，每個獨立的控制面被稱為修訂版並具有istio.io/rev標籤。
為了支援這種基於修訂的升級，Istio為命名空間引入了一個istio.io/rev標籤。它可以指示哪個控制面版本應該為相應命名空間中的工作負載注入Sidecar代理。例如，標籤istio.io/rev=1-17-2表示為該命名空間中的工作負載注入1.17.2版本的Sidecar代理。
在金絲雀升級過程中，您可以通過將部分服務先升級的方式來驗證目標版本是否符合預期，若驗證結果不符合預期，可以快速進行復原來保證服務的穩定性。版本驗證符合預期後，可以將金絲雀版本切換為目前的版本，並通過變換方式將所有工作負載升級到最新版本，完成資料面的升級，並卸載老版本完成所有升級步驟。
準備工作
由於在金絲雀升級中，驗證階段需要顯式地通過命名空間標籤來指定注入的Sidecar代理版本，因此金絲雀升級具有對注入策略的前置要求。請按照以下步驟確認注入策略配置是否滿足金絲雀升級條件。
登入ASM控制台，在左側導覽列，選擇。
在網格管理頁面，單擊目標執行個體名稱，然後在左側導覽列，選擇。
在注入策略配置頁面的注入策略組態管理地區，確認Pod所在命名空間的標籤需要滿足條件為包含 istio-injection: enabled。
說明istio-injection: enabled與istio.io/rev: stable具有相同的語義。在金絲雀升級過程中，將使用istio.io/rev: stable為對應命名空間中的Pod注入穩定版本網格代理，使用istio.io/rev: canary為對應命名空間中的Pod注入金絲雀版本的網格代理。升級完成後，即使不將
istio.io/rev:stable替換回istio-injection: enabled，也可以正常注入，因為這兩個標籤的語義完全一致。升級前的狀態如下所示：
步驟一：升級ASM控制面
登入ASM控制台，在左側導覽列，選擇。
在網格管理頁面，單擊目標執行個體名稱，然後在左側導覽列，選擇。
在升級管理頁面，單擊金絲雀升級頁簽，在控制面頁簽下選擇金絲雀版本和建立負載平衡CLB執行個體，單擊確認，然後在確認升級？對話方塊，單擊確定。
金絲雀升級最多跨一個次要版本升級，本樣本的ASM執行個體版本為1.16，最高可升級到1.17或者1.18。本文以升級到v1.17.2.37為例進行說明。金絲雀升級的目標版本部署時會建立與之關聯的一個CLB執行個體，若無特別需求，CLB執行個體選擇預設的規格即可。關於CLB執行個體的計費說明，請參見CLB計費概述。
金絲雀版本的部署是一個非同步過程，大致需要幾分鐘，請等待相關組件部署完成。新版本部署完成後，介面顯示如下。
此時狀態如下所示：
步驟二：升級reviews-v2的注入代理到新版本
步驟一通過金絲雀升級方式部署了一個v1.17.2版本的Istio控制面。下文以在Bookinfo應用的reviews-v2版本更新其注入的網格代理版本到v1.17為例，驗證該版本是否符合預期。
登入ASM控制台，在左側導覽列，選擇。
在網格管理頁面，單擊目標執行個體名稱，然後在左側導覽列，選擇。
在全域命名空間頁面的自動注入列，查看default命名空間對應的標籤是否為
istio-injection: enabled。若標籤為
istio-injection: enabled，表明注入的是1.16版本的網格代理。
在全域命名空間頁面的自動注入列，單擊default命名空間對應的切換為注入1-17-2版本，在確認對話方塊，單擊確定。
default全域命名空間的標籤將切換為
istio.io/rev: canary，並立即將資料面default命名空間標籤也同步成istio.io/rev: canary。此時全域命名空間頁面顯示default注入的是1.17版本的網格代理。命名空間default下新建立的工作負載（Pod）將注入1.17版本的網格代理。其他命名空間的標籤未更改，依然注入當前1.16版本的網格代理。
說明上述步驟是為一個在升級前已經開啟自動注入的命名空間切換注入的Sidecar網格代理版本。對於升級前尚未開啟Sidecar網格代理注入的命名空間，您可以正常地為其開啟自動注入。注入時，請按需選擇注入的Sidecar網格代理版本。服務網格將根據您選擇的版本，為命名空間打上
istio.io/rev:stable或istio.io/rev:canary的標籤。
變換reviews-v2工作負載。
登入Container Service管理主控台，在左側導覽列選擇叢集。
在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇。
在無狀態頁面的操作列，單擊reviews-v2對應的，然後在重新部署對話方塊，單擊確定。
在無狀態頁面，單擊reviews-v2，在容器組頁簽，查看變換後的reviews-v2對應的Pod是否啟動成功，以及新的Pod是否注入了1.17對應的Sidecar代理版本。
可以看到變換後的reviews-v2對應的Pod啟動成功，且新的Pod成功注入了v1.17版本的Sidecar網格代理。
開啟瀏覽器，訪問Bookinfo頁面，檢查流量是否符合預期。
如下圖所示，可以正常訪問到reviews-v2版本，符合預期。
此時狀態如下所示：
步驟三：復原reviews-v2為1.16版本
若步驟二驗證失敗，或者因為其他原因需要進行復原，請參照以下步驟。
登入ASM控制台，在左側導覽列，選擇。
在網格管理頁面，單擊目標執行個體名稱，然後在左側導覽列，選擇。
在全域命名空間頁面的自動注入列，單擊default命名空間對應的切換為注入1-16-4版本，然後在確認對話方塊，單擊確定。
復原前的命名空間標籤為
istio.io/rev: canary，default注入的是1.17版本的網格代理。
復原後的標籤將切換為
istio.io/rev: stable，並且資料面default命名空間標籤也同步為istio.io/rev: stable，default注入的是1.16版本的網格代理。在Container Service控制台重新部署reviews-v2工作負載。
登入Container Service管理主控台，在左側導覽列選擇叢集。
在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇。
在無狀態頁面上方，命名空間選擇default，然後在操作列，單擊reviews-v2對應的，在重新部署對話方塊，單擊確定。
在無狀態頁面，單擊reviews-v2名稱，在容器組頁簽查看變換後的reviews-v2對應的Pod是否啟動成功，新的Pod是否注入了1.16對應的Sidecar代理版本。
可以看到變換後的reviews-v2對應的Pod啟動成功，且新的Pod注入了1.16對應的Sidecar代理版本。
步驟四：撤銷升級
復原成功後，您可以撤銷金絲雀升級，將ASM執行個體更新為最初的1.16版本。
撤銷升級前，請確保所有命名空間都已注入穩定Sidecar代理版本，否則無法撤銷。
登入ASM控制台，在左側導覽列，選擇。
在網格管理頁面，單擊目標執行個體名稱，然後在左側導覽列，選擇。
在升級管理頁面的金絲雀升級頁簽，單擊撤銷升級，然後在確認撤銷升級嗎？對話方塊，單擊確定。
單擊撤銷升級後，將會刪除升級中的灰階版本的控制面組件（即樣本中的1.17版本），只保留穩定版本的控制面組件（即樣本中的1.16版本）。
此時狀態如下所示：
步驟五：重新升級及驗證
此時整個ASM執行個體處於步驟一之前待升級的狀態。本樣本僅驗證reviews-v1、reviews-v2和reviews-v3三個工作負載。請您根據實際情況，參照上述步驟對任意的工作負載進行升級驗證，直至您認為驗證通過。
步驟六：驗證符合預期，切換為正式版本
通過上述步驟，已驗證review-v1、review-v2可以使用1.17（新版本）的網格代理，並且功能符合預期。此時，您可以選擇是否將1.17版本切換為正式版本。
一旦進行版本切換，意味著升級已經進入舊版本下線階段。您只能將現有工作負載全部切換成新的1.17版本的Sidecar網格代理，無法再撤銷升級。請確保在新版本部署階段完成全部驗證工作。
在版本切換後，帶有
istio.io/rev: stable和istio-injection: enabled標籤的命名空間將注入新的1.17版本的Sidecar網格代理，而istio.io/rev: canary標籤將失去作用。因此，在版本切換時，ASM會自動將所有istio.io/rev: canary標籤切換為istio.io/rev: stable。請您在升級管理頁面的金絲雀升級頁簽，單擊版本切換時進行確認。
登入ASM控制台，在左側導覽列，選擇。
在網格管理頁面，單擊目標執行個體名稱，然後在左側導覽列，選擇。
在升級管理頁面的金絲雀升級頁簽，單擊版本升級，在確認版本切換嗎對話方塊，仔細閱讀提示內容，確認無誤後單擊確定。
切換成功後，已經注入的1.16版本的網格代理依然保留，對應的工作負載不受影響。但重新部署的Pod將全部注入1.17版本的Sidecar代理。切換更新完成後的介面如下。
此時狀態如下所示：
步驟七：資料面升級
此時ASM的版本為1.17，命名空間標籤istio.io/rev=stable、istio.io/rev=1-17-2或istio-injection=enabled都注入1.17版本的Sidecar網格代理。通過變換工作負載，可以升級注入的Sidecar網格代理到當前新版本1.17，以此完成資料面升級。
登入ASM控制台，在左側導覽列，選擇。
在網格管理頁面，單擊目標執行個體名稱，然後在左側導覽列，選擇。
在升級管理頁面的金絲雀升級頁簽，單擊資料面頁簽，按需升級ASM網關或工作負載。
升級ASM網關：在ASM網關地區的操作列，單擊目標網關對應的滾動升級，在確認執行滾動升級嗎？對話方塊，單擊確定，將ASM網關升級到到1.17新版本。
升級工作負載：在待升級工作負載地區，切換命名空間，然後在操作列，單擊目標工作負載對應的滾動升級，在確認執行滾動升級嗎？對話方塊，單擊確定，將工作負載升級到到1.17新版本。
說明列表中不會顯示已完成升級的ASM網關或工作負載。
您也可以在左側導覽列，單擊網格狀態，查看全域未升級的工作負載或網關執行個體。
此時升級完資料面之後的狀態如下所示。
步驟八：下線舊版本
當資料面所有工作負載升級完成後，您可以將老版本1.16進行下線操作。
登入ASM控制台，在左側導覽列，選擇。
在網格管理頁面，單擊目標執行個體名稱，然後在左側導覽列，選擇。
在升級管理頁面的金絲雀升級頁簽，單擊下線舊版本，在確認下線舊版本控制面嗎？對話方塊，單擊確定。
此時狀態如下所示。
