kubernetes實踐之六十六：Istio實現金絲雀釋出原理

一：簡介

    網際網路產品使用者數量龐大，如果採用全量釋出的話不論對於開發運維團隊有著未知的風險，而且產品以及運營團隊也同樣面臨的使用者體驗的巨大挑戰。

二：藍綠釋出

   在釋出的過程中使用者無感知服務的重啟，通常情況下是透過新舊版本並存的方式實現，也就是說在釋出的流程中，新的版本和舊的版本是相互熱備的，透過切換路由權重的方式（非0即100）實現不同的應用的上線或者下線.

  釋出流程：

(1) 部署版本1的應用（一開始的狀態），所有外部請求的流量都打到這個版本上。

(2) 部署版本2的應用，版本2的程式碼與版本1不同(新功能、Bug修復等)。

(3) 將流量從版本1切換到版本2。

(4) 如版本2測試正常，就刪除版本1正在使用的資源（例如例項），從此正式用版本2。

三：滾動釋出

滾動釋出，一般是取出一個或者多個伺服器停止服務，執行更新，並重新將其投入使用。週而復始，直到叢集中所有的例項都更新成新版本。這種部署方式相對於藍綠部署，更加節約資源——它不需要執行兩個叢集、兩倍的例項數。我們可以部分部署，例如每次只取出叢集的百分之二十進行升級。

這種方式也有很多缺點，例如：

(1) 沒有一個確定OK的環境。使用藍綠部署，我們能夠清晰地知道老版本是OK的，而使用滾動釋出，我們無法確定。

(2) 修改了現有的環境。

(3) 如果需要回滾，很困難。舉個例子，在某一次釋出中，我們需要更新100個例項，每次更新10個例項，每次部署需要5分鐘。當滾動釋出到第80個例項時，發現了問題，需要回滾。

(4) 有的時候，我們還可能對系統進行動態伸縮，如果部署期間，系統自動擴容/縮容了，我們還需判斷到底哪個節點使用的是哪個程式碼。儘管有一些自動化的運維工具，但是依然令人心驚膽戰。

並不是說滾動釋出不好，滾動釋出也有它非常合適的場景。

四：金絲雀釋出

金絲雀釋出是指在黑與白之間，能夠平滑過渡的一種釋出方式。金絲雀釋出是增量釋出的一種型別，金絲雀釋出是在原有版本可用的情況下，同時部署一個新版本應用作為“金絲雀”，測試新版本的效能和表現，以保障整體系統穩定的情況下，儘早發現、調整問題。

  金絲雀釋出由以下幾個步驟組成：

(1)準備好部署各個階段的工件，包括：構建工件，測試指令碼，配置檔案和部署清單檔案。

(2)從負載均衡列表中移除掉“金絲雀”伺服器。

(3)升級“金絲雀”應用（排掉原有流量並進行部署）。

(4)對應用進行自動化測試。

(5)將“金絲雀”伺服器重新新增到負載均衡列表中（連通性和健康檢查）。

(6)如果“金絲雀”線上使用測試成功，升級剩餘的其他伺服器。（否則就回滾）

金絲雀可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。

金絲雀部署適用的場景：

(1)不停止老版本，額外搞一套新版本，不同版本應用共存。

(2)灰度釋出中，常常按照使用者設定路由權重，例如百分之九十的使用者維持使用老版本，百分之十的使用者嚐鮮新版本。

(3)經常與A/B測試一起使用，用於測試選擇多種方案。AB test就是一種灰度釋出方式，讓一部分使用者繼續用A，一部分使用者開始用B，如果使用者對B沒有什麼反對意見，那麼逐步擴大範圍，把所有使用者都遷移到B上面來

五：Istio實現金絲雀釋出原理

金絲雀釋出的流程如下：

(1)準備和生產環境隔離的“金絲雀”伺服器。

(2)將新版本的服務部署到“金絲雀”伺服器上。

(3)對“金絲雀”伺服器上的服務進行自動化和人工測試。

(4)測試透過後，將“金絲雀”伺服器連線到生產環境，將少量生產流量匯入到“金絲雀”伺服器中。

(5)如果線上測試出現問題，則透過把生產流量從“金絲雀”伺服器中重新路由到老版本的服務的方式進行回退，修復問題後重新進行釋出。

(6)如果線上測試順利，則逐漸把生產流量按一定策略逐漸匯入到新版本伺服器中。

(7)待新版本服務穩定執行後，刪除老版本服務。

從上面的流程可以看到，如果要實現一套金絲雀釋出的流程，需要應用程式和運維流程對該釋出過程進行支援，工作量和難度的挑戰是非常大的。雖然面對的問題類似，但每個企業或組織一般採用不同的私有化實現方案來進行灰度釋出,為解決該問題導致研發和運維花費了大量的成本。

Istio透過高度的抽象和良好的設計採用一致的方式解決了該問題，採用sidecar對應用流量進行了轉發，透過Pilot下發路由規則，可以在不修改應用程式的前提下實現應用的灰度釋出。

備註：採用kubernetes的滾動升級(rolling UPDATE)功能也可以實現不中斷業務的應用升級,但滾動升級是透過逐漸使用新版本的服務來替換老版本服務的方式對應用進行升級，在滾動升級不能對應用的流量分發進行控制，因此無法採用受控地把生產流量逐漸導流到新版本服務中，也就無法控制服務升級對使用者造成的影響。

採用Istio後，可以透過定製路由規則將特定的流量（如指定特徵的使用者）匯入新版本服務中，在生產環境下進行測試，同時透過漸進受控地匯入生產流量，可以最小化升級中出現的故障對使用者的影響。並且在同時存在新老版本服務時，還可根據應用壓力對不同版本的服務進行獨立的縮擴容，非常靈活。

採用Istio進行金絲雀釋出的流程如下圖所示：

1.部署Reviews-V1,所有的流量指向V1

2.部署Reviews-V2

3.透過採用Istio的路由規則，將部分流量匯入V2 (如百分之十)

4.逐步增加流量配置

5.流量全部切換到V2,刪除V1