Istio最佳實踐：在K8s上經過Istio服務網格進行灰度發佈

Istio是什麼？

Istio是Google繼Kubernetes以後的又一開源力做，主要參與的公司包括Google，IBM，Lyft等公司。它提供了完整的非侵入式的微服務治理解決方案，包含微服務的管理、網絡鏈接以及安全管理等關鍵能力，無需修改任何代碼就可以實現微服務的負載均衡，服務與服務之間的認證受權以及監控。從整個基礎設施角度上看，能夠將它理解爲PaaS平臺上的一個面向微服務管理平臺的補充。

 

                                                               Istio架構示意圖

Istio與Kubernetes

Kubernetes提供了部署、升級和有限的運行流量管理能力；利用service的機制來作服務註冊和發現，轉發，經過kubeproxy有必定的轉發和負載均衡能力。但並不具有上層如熔斷、限流降級、調用鏈治理等能力.

Istio則很好的補齊了k8s在微服務治理上的這部分能力，同時是基於k8s構建的，但不是像SpringCloud Netflix等徹底從新作一套。Istio是谷歌微服務治理上的很是關鍵的一環。

 

Istio與k8s緊密結合，包括：Sicecar 運行在k8s pod裏，做爲一個proxy和業務容器部署在一塊兒，部署過程對用戶透明。Mesh中要求業務程序的運行感知不到sidecar的存在，基於k8sd的pod的設計這部分作的更完全，對用戶更透明，用戶甚至感知不到部署sidecar的這個過程。試想若是是經過VM上部署一個agent，不會有這麼方便。

Pilot中包含一個controller，經過list/watch kube-apiserver自動發現K8S中的services、endpoints。它經過在Kubernetes裏面註冊一個controller來監聽事件，從而獲取Service和Kubernetes的Endpoint以及Pod的關係，可是在轉發層面，再也不使用kube-proxy轉發了，而是將這些映射關係轉換成爲pilot本身的轉發模型，下發到envoy進行轉發。

 

K8s編排容器服務已經成爲一種事實上的標準；由於微服務與容器在輕量、快速部署運維等特徵的匹配，微服務運行在容器中也正成爲一種標準實踐；對於雲原生應用，採用Kubernetes構建微服務部署和集羣管理能力，採用Istio構建服務治理能力，將逐漸成爲應用微服務轉型的標準配置。

      

 

自行管理Istio與CCE上使用Istio服務網格的對比

華爲雲 · 雲容器引擎CCE(Cloud Container Engine)提供高可靠高性能的企業級容器應用管理服務，支持Kubernetes社區原生應用和工具，簡化雲上自動化容器運行環境搭建：

• 簡單易用：自動化建立容器集羣，一站式部署/運維容器應用，一鍵式滾動升級；
• 高性能：自研高性能容器網絡，秒級自動彈性伸縮，支持高性能裸金屬容器私有集羣；
• 企業級：集羣控制面HA和跨AZ高可用，容器應用優雅伸縮，安全下線，保障業務不掉線；
• 開放兼容：兼容Kubernetes/Docker社區原生版本，CNCF認證的Kubernetes服務提供商，社區的主要貢獻者；

 

下列從安裝、運行管理和監控多維度對比自建Istio和華爲雲CCE上使用Istio的差異：

	自建	華爲雲CCE
Istio包管理	用戶自行下載和管理	用戶不感知
運行配置	用戶自行配置運行環境和依賴	用戶不感知
Istio安裝	用戶自行探索和安裝	用戶不須要關注具體細節，建立集羣時按需啓用。
Sidecar注入	用戶自行探索和開發、配置	用戶不感知
Istio升級	用戶自行探索、開發不影響業務的升級方案	提供完整解決方案，按需進行控制面和數據面的升級操做
應用調用鏈	用戶自行探索、開發和安裝、配置	對接華爲雲APM/AOM服務，提供請求調用鏈跟蹤查看能力
應用拓撲	用戶自行探索、開發和安裝、配置	對接華爲雲APM/AOM服務，提供查看應用拓撲能力
性能監控	用戶自行探索、開發和安裝、配置	對接華爲雲APM/AOM服務，提供請求響應時延的實時性能狀態監控

 

雲原生應用在CCE上的部署、管理實踐

雲原生應用、雲平臺與微服務架構

雲原生應用，是指原生爲在雲平臺上部署運行而設計開發的應用。公平的說，大多數傳統的應用，不作任何改動，都是能夠在雲平臺運行起來的，只要雲平臺支持這個傳統應用所運行的計算機架構和操做系統。只不過這種運行模式，僅僅是把虛擬機當物理機同樣使用，不可以真正利用起來雲平臺的能力。

雲計算平臺的核心能力就是提供按需分配資源和彈性計算的能力，而云原生應用的設計理念就是讓部署到雲平臺的應用可以利用雲平臺的能力實現按需使用計算資源和彈性伸縮。

微服務架構是實現企業分佈式系統的一種架構模式，即將一個複雜的單體應用按照業務的限定上下文，分解成多個獨立部署的組件。這些獨立部署的組件，就稱爲微服務。而在談論雲原生應用與微服務架構關係的時候，根據上下文不一樣能夠從兩個角度去看。

1） 宏觀的雲原生應用，即將整個分佈式系統看做一個應用，這個角度下，微服務架構是實現雲原生應用的一種架構模式；

2） 微觀的雲原生應用，即每一個微服務是一個應用，這種語境下，每一個微服務要按照雲原生應用的設計理念去設計(如咱們所熟知的雲原生12要素），才能真正實現微服務架構所要達到的目的，即讓分佈式系統具有按需使用計算資源和彈性伸縮的能力。

在華爲雲CCE容器服務中，咱們將宏觀的雲原生應用，稱之爲「應用」，而將微觀層面的雲原生應用，稱之爲「組件「，用這兩個概念來對分佈式應用進行管理：

                                          圖：應用、組件與工做負載的關係

在CCE上進行雲原生應用管理的實踐

建立Kubernetes集羣

       在建立應用前，須要準備好一個Kubernetes集羣（1.9及以上版本），並啓用Istio服務網格治理。登陸CCE控制檯，在左側導航欄中單擊「資源管理 > 虛擬機集羣」，在「虛擬機集羣」界面，單擊「建立Kubernetes集羣」，按照嚮導式逐步配置：

 

圖1：建立Kubernetes集羣

 

 

圖2：使能服務網格，一鍵式安裝Istio並自動使能應用sidecar注入：

 

其餘集羣建立步驟、配置與已有CCE上建立虛擬機集羣一致.

建立雲原生應用

這裏咱們以Istio開源社區的bookinfo樣例應用爲例，其包含ProductPage、Reviews、Details、Ratings這4個微服務，拓撲結構以及網絡訪問信息以下：

 

在CCE左側導航欄中選擇「應用管理」，單擊「建立應用」，選擇「嚮導式建立」 （後續將支持經過helm模板一鍵式建立微服務應用以及其流量策略配置，更方便管理），分三大塊配置：應用基本信息、網格內組件定義、對外放開路由配置。

一、 首先定義應用的基本信息：名稱、選擇所在集羣和namespace：

 

二、 第二步，點擊添加組件，按照上方的應用拓撲和網絡設計，把組件加入到服務網格：

 

A、添加ratings微服務組件（容器內監聽端口爲9080，開放至service mesh內部訪問端口也配置爲9080，後者可根據客戶端配置自行調整）

1）配置組件基本信息：

 

2）選擇負載鏡像，並配置版本號爲v1

 

 

3） 點擊「下一步」，負載高級配置中能夠選擇配置升級策略、縮容策略、自定義監控等，咱們這裏不作配置，點擊「添加「：

 

 

能夠看到咱們爲bookinfo添加了一個微服務組件進網格

 

 

 

B、 添加reviews微服務組件

參考上述添加ratings的步驟，添加reviews：

 

 

C、 添加details微服務組件

參考上述添加組件步驟，添加details微服務組件：

 

D、   添加productpage微服務組件

 

三、    最後，配置應用對外開放的訪問路由，從上方拓撲設計可知，productpage做爲訪問入口：

A、點擊「添加應用訪問方式「

 

B、選擇開放至外部訪問的組件，並配置開放端口

 

配置後的訪問方式信息以下所示：

 

最後點擊右下角「建立」，啓動應用，在應用列表中能夠看到新建的分佈式微服務應用bookinfo及其包含的微服務組件：

 

 

經過應用開放的訪問入口訪問productpage：

 

 

 

在CCE上使用Istio進行灰度發佈的實踐

一鍵式在集羣上啓用Istio服務網格

集羣下應用若是須要作微服務治理，只須要在建立集羣時點擊啓用服務網格便可，不須要自行進行Istio鏡像下載、yaml配置、安裝、升級等與應用業務無關的複雜基礎設施構建工做：

 

 

開發打包新版本

下方咱們以開發了一個新版本reviews微服務爲例（初始容器鏡像版本號爲1.5.0），新版本鏡像版本號爲1.5.0-v2，而且已在本地開發機經過docker push上傳至華爲雲容器鏡像服務（SWR）：

 

新版本在如今版本基礎上增長對ratings微服務的調用，支持評分星星級別展現.

 

 

 

發佈灰度版本並配置灰度策略

如今咱們計劃經過灰度發佈的方式，平滑的在現網升級，在應用列表頁面，展開bookinfo下的組件信息，選擇reviews微服務組件的「添加灰度版本」：

 

 

啓動灰度版本：配置灰度版本號v2，確認好鏡像版本（系統會默認選擇最新版本的鏡像），點擊「啓動負載」便可啓動灰度版本，容器高級配置已默認繼承已有版本

 

觀察灰度版本運行狀態並配置灰度策略：按照比例分配灰度版本流量比例（這裏以20%爲例），觀察負載啓動成功後，點擊「提交策略」：

 

回到組件列表能夠看到，review微服務已處於灰度發佈狀態：

 

 

對review服務進行灰度發佈先後的流量對好比下所示：

初始版本：

 

灰度狀態：如圖示，review v2版本調用ratings服務獲取星級評價，並將20%流量分流至本版本上

 

訪問productpage，能夠看到部分請求能夠顯示星級評價，部分請求仍然是老版本的顯示效果（即沒有評星這個新特性），而且出現的比例接近1:4.

部分訪問結果爲原有的頁面：

 

 

部分訪問結果爲帶有星級評價特性的頁面：

 

 

 

 

 

持續觀測灰度版本運轉狀態，並進行流量切換

接下來，咱們會持續觀測灰度版本的運行狀態，在確認業務處理、性能知足要求後，咱們能夠選擇逐步調大灰度版本的流量比例，然後進一步將流量所有導流至灰度版本上：

 

• 觀察健康與性能狀態：

點擊CCE左側導航欄「運維中心」進入AOM服務：

 

選擇「指標」->「應用」菜單，持續觀察review服務灰度版本v2的健康狀態與性能狀態：

 

 

• 觀察調用鏈以及請求響應時延：在CCE應用管理中，點擊bookinfo應用，查看詳情，能夠看到CCE服務提供了請求調用鏈跟蹤能力，可以實現分佈式異常請求的快速定位（當前提供開源zipkin和grafana能力，後續將對接至華爲雲AOM服務提供相應能力）

 

 

 

能夠看到V2版本運轉正常，那麼下一步咱們將逐步擴大流量比，最後將流量所有導至灰度版本，在cce服務中，點擊組件名稱，進入組件詳情頁面，點擊「接管全部流量」：

 

系統提示會將接管原有版本的全部流量，點擊「肯定「按鈕：

 

 

如今全部訪問reviews的流量都導向v2版本：

 

 

              訪問productpage，全部的請求都會呈現星級評價特性：

 

 

最後，咱們將原有老版本（V1）從平臺移除：

 

點擊確認後，能夠看到該微服務只剩下v2版本在運轉：

 

經過Istioctl工具進行更多微服務流量治理

         在上述規則的基礎上，cce Istio服務網格還提供了Istioctl命令行工具，實現更全面的流量治理能力，如限流、熔斷、鏈接池管理、會話保持等。進入」資源管理「->「虛擬機集羣「，點擊所要管理的集羣，能夠看到Istio命令行的下載和使用指導：

 

 

總結

菊廠雲CCE容器引擎 + Istio + 應用運維AOM/APM +容器鏡像服務 SWR，提供了完整的雲原生應用從開發、部署、上線、監控的完整生命週期管理全棧服務，讓企業上雲更簡單，運行更高效。

目前Istio服務網格能力已開放公測，可經過下方連接，快速申請公測，華爲雲容器服務的專家將全力爲您服務，爲您的成功保駕護航.

 

申請連接：https://console.huaweicloud.com/cce2.0/?region=cn-north-1#/app/Istio/meshList