這期內(nèi)容當中小編將會給大家?guī)碛嘘P(guān)kubernetes中Istio實現(xiàn)金絲雀發(fā)布原理是什么，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
一：簡介
互聯(lián)網(wǎng)產(chǎn)品用戶數(shù)量龐大，如果采用全量發(fā)布的話不論對于開發(fā)運維團隊有著未知的風險，而且產(chǎn)品以及運營團隊也同樣面臨的用戶體驗的巨大挑戰(zhàn)。
二：藍綠發(fā)布
在發(fā)布的過程中用戶無感知服務(wù)的重啟，通常情況下是通過新舊版本并存的方式實現(xiàn)，也就是說在發(fā)布的流程中，新的版本和舊的版本是相互熱備的，通過切換路由權(quán)重的方式（非0即100）實現(xiàn)不同的應(yīng)用的上線或者下線.
發(fā)布流程：
(1) 部署版本1的應(yīng)用（一開始的狀態(tài)），所有外部請求的流量都打到這個版本上。
(2) 部署版本2的應(yīng)用，版本2的代碼與版本1不同(新功能、Bug修復(fù)等)。
(3) 將流量從版本1切換到版本2。
(4) 如版本2測試正常，就刪除版本1正在使用的資源（例如實例），從此正式用版本2。
三：滾動發(fā)布
滾動發(fā)布，一般是取出一個或者多個服務(wù)器停止服務(wù)，執(zhí)行更新，并重新將其投入使用。周而復(fù)始，直到集群中所有的實例都更新成新版本。這種部署方式相對于藍綠部署，更加節(jié)約資源——它不需要運行兩個集群、兩倍的實例數(shù)。我們可以部分部署，例如每次只取出集群的百分之二十進行升級。
這種方式也有很多缺點，例如：
(1) 沒有一個確定OK的環(huán)境。使用藍綠部署，我們能夠清晰地知道老版本是OK的，而使用滾動發(fā)布，我們無法確定。
(2) 修改了現(xiàn)有的環(huán)境。
(3) 如果需要回滾，很困難。舉個例子，在某一次發(fā)布中，我們需要更新100個實例，每次更新10個實例，每次部署需要5分鐘。當滾動發(fā)布到第80個實例時，發(fā)現(xiàn)了問題，需要回滾。
(4) 有的時候，我們還可能對系統(tǒng)進行動態(tài)伸縮，如果部署期間，系統(tǒng)自動擴容/縮容了，我們還需判斷到底哪個節(jié)點使用的是哪個代碼。盡管有一些自動化的運維工具，但是依然令人心驚膽戰(zhàn)。
并不是說滾動發(fā)布不好，滾動發(fā)布也有它非常合適的場景。
四：金絲雀發(fā)布
金絲雀發(fā)布是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式。金絲雀發(fā)布是增量發(fā)布的一種類型，金絲雀發(fā)布是在原有版本可用的情況下，同時部署一個新版本應(yīng)用作為“金絲雀”，測試新版本的性能和表現(xiàn)，以保障整體系統(tǒng)穩(wěn)定的情況下，盡早發(fā)現(xiàn)、調(diào)整問題。
金絲雀發(fā)布由以下幾個步驟組成：
(1)準備好部署各個階段的工件，包括：構(gòu)建工件，測試腳本，配置文件和部署清單文件。
(2)從負載均衡列表中移除掉“金絲雀”服務(wù)器。
(3)升級“金絲雀”應(yīng)用（排掉原有流量并進行部署）。
(4)對應(yīng)用進行自動化測試。
(5)將“金絲雀”服務(wù)器重新添加到負載均衡列表中（連通性和健康檢查）。
(6)如果“金絲雀”在線使用測試成功，升級剩余的其他服務(wù)器。（否則就回滾）
金絲雀可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時候就可以發(fā)現(xiàn)、調(diào)整問題，以保證其影響度。
金絲雀部署適用的場景：
(1)不停止老版本，額外搞一套新版本，不同版本應(yīng)用共存。
(2)灰度發(fā)布中，常常按照用戶設(shè)置路由權(quán)重，例如百分之九十的用戶維持使用老版本，百分之十的用戶嘗鮮新版本。
(3)經(jīng)常與A/B測試一起使用，用于測試選擇多種方案。AB test就是一種灰度發(fā)布方式，讓一部分用戶繼續(xù)用A，一部分用戶開始用B，如果用戶對B沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到B上面來
五：Istio實現(xiàn)金絲雀發(fā)布原理
金絲雀發(fā)布的流程如下：
(1)準備和生產(chǎn)環(huán)境隔離的“金絲雀”服務(wù)器。
(2)將新版本的服務(wù)部署到“金絲雀”服務(wù)器上。
(3)對“金絲雀”服務(wù)器上的服務(wù)進行自動化和人工測試。
(4)測試通過后，將“金絲雀”服務(wù)器連接到生產(chǎn)環(huán)境，將少量生產(chǎn)流量導(dǎo)入到“金絲雀”服務(wù)器中。
(5)如果在線測試出現(xiàn)問題，則通過把生產(chǎn)流量從“金絲雀”服務(wù)器中重新路由到老版本的服務(wù)的方式進行回退，修復(fù)問題后重新進行發(fā)布。
(6)如果在線測試順利，則逐漸把生產(chǎn)流量按一定策略逐漸導(dǎo)入到新版本服務(wù)器中。
(7)待新版本服務(wù)穩(wěn)定運行后，刪除老版本服務(wù)。
從上面的流程可以看到，如果要實現(xiàn)一套金絲雀發(fā)佈的流程，需要應(yīng)用程序和運維流程對該發(fā)布過程進行支持，工作量和難度的挑戰(zhàn)是非常大的。雖然面對的問題類似，但每個企業(yè)或組織一般采用不同的私有化實現(xiàn)方案來進行灰度發(fā)布,為解決該問題導(dǎo)致研發(fā)和運維花費了大量的成本。
Istio通過高度的抽象和良好的設(shè)計采用一致的方式解決了該問題，采用sidecar對應(yīng)用流量進行了轉(zhuǎn)發(fā)，通過Pilot下發(fā)路由規(guī)則，可以在不修改應(yīng)用程序的前提下實現(xiàn)應(yīng)用的灰度發(fā)布。
備注：采用kubernetes的滾動升級(rolling UPDATE)功能也可以實現(xiàn)不中斷業(yè)務(wù)的應(yīng)用升級,但滾動升級是通過逐漸使用新版本的服務(wù)來替換老版本服務(wù)的方式對應(yīng)用進行升級，在滾動升級不能對應(yīng)用的流量分發(fā)進行控制，因此無法采用受控地把生產(chǎn)流量逐漸導(dǎo)流到新版本服務(wù)中，也就無法控制服務(wù)升級對用戶造成的影響。
采用Istio后，可以通過定制路由規(guī)則將特定的流量（如指定特征的用戶）導(dǎo)入新版本服務(wù)中，在生產(chǎn)環(huán)境下進行測試，同時通過漸進受控地導(dǎo)入生產(chǎn)流量，可以最小化升級中出現(xiàn)的故障對用戶的影響。并且在同時存在新老版本服務(wù)時，還可根據(jù)應(yīng)用壓力對不同版本的服務(wù)進行獨立的縮擴容，非常靈活。
采用Istio進行金絲雀發(fā)布的流程如下圖所示：
1.部署Reviews-V1,所有的流量指向V1
2.部署Reviews-V2
3.通過采用Istio的路由規(guī)則，將部分流量導(dǎo)入V2 (如百分之十)
4.逐步增加流量配置
5.流量全部切換到V2,刪除V1
上述就是小編為大家分享的kubernetes中Istio實現(xiàn)金絲雀發(fā)布原理是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道。
重慶分公司
重慶分公司
