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模板一鍵式建立微服務應用以及其流量策略配置，更方便管理），分三大塊配置：應用基本資訊、網格內元件定義、對外放開路由配置。

1、 首先定義應用的基本資訊：名稱、選擇所在叢集和namespace：

2、 第二步，點選新增元件，按照上方的應用拓撲和網路設計，把元件加入到服務網格：

A、 新增ratings微服務元件（容器內監聽埠為9080，開放至service mesh內部訪問埠也配置為9080，後者可根據客戶端配置自行調整）

1 ）配置元件基本資訊：

2 ）選擇負載映象，並配置版本號為v1

 

3 ） 點選“下一步”，負載高階配置中可以選擇配置升級策略、縮容策略、自定義監控等，我們這裡不做配置，點選“新增“：

 

可以看到我們為bookinfo新增了一個微服務元件進網格

 

 

B、 新增reviews微服務元件

參考上述新增ratings的步驟，新增reviews：

 

C、 新增details微服務元件

參考上述新增元件步驟，新增details微服務元件：

D、    新增productpage微服務元件

3、     最後，配置應用對外開放的訪問路由，從上方拓撲設計可知，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/istioPublicBeta