kubernetes實踐之六十七：Istio介紹

一：簡介

隨著微服務架構的普及，越來越多的應用已經拆分成了微服務的架構。而微服務架構落地的一個難點，就是如何讓服務和服務之間進行穩定的通訊。

部署微服務之後，如何做服務的負載均衡、容錯性、服務監控、日誌追蹤以及熔斷等功能都需要考慮周全。

為了讓業務團隊返璞歸真，將所有精力集中在業務程式碼而不是配合微服務元件寫大量非功能性需求的程式碼，Istio應運而生。

Istio是谷歌、IBM、Lyft等公司貢獻的開源Service Mesh元件。它實現的目標就是讓業務開發不再關注微服務之間如何呼叫、管理、監控等非功能性需求，而是讓Istio來處理這些問題。Istio和Kubernetes有天然的支援。

Istio能輕鬆解決藍綠髮布和金絲雀釋出的問題。

Istio能夠做到：

1.HTTP、gRPC、WebSocket和TCP流量的自動負載均衡。

2.通過豐富的路由規則、重試、故障轉移和故障注入對流量行為進行細粒度控制。

3.支援訪問控制、速率限制和配額的可拔插策略層和配置API。

4.自動指標、日誌和叢集內所有流量的跟蹤，包括叢集入口和出口。

5.通過叢集中的服務之間的強身份斷言來實現服務間的身份驗證。

通過在整個環境中部署一個特殊的sidecar代理（輔助容器），您可以將Istio支援新增到服務中。安裝了sidecar代理之後，（微）服務之間的所有網路通訊都通過這個代理。此外，所有的網路通訊都是使用Istio的控制平面功能進行配置和管理的。

二：主要功能

1.流量管理(Pilot)。控制服務之間的流量和API呼叫的流向，使得呼叫更靈活可靠，並使網路在惡劣情況下更加健壯。

2.可觀察性。通過整合zipkin等服務，快速瞭解服務之間的依賴關係，以及它們之間流量的本質和流向，從而提供快速識別問題的能力。

3.策略執行(mixer)。將組織策略應用於服務之間的互動，確保訪問策略得以執行，資源在消費者之間良好分配。策略的更改是通過配置網格而不是修改應用程式程式碼。

4.服務身份和安全(Istio-auth)。為網格中的服務提供可驗證身份，並提供保護服務流量的能力，使其可以在不同可信度的網路上流轉。

除此之外，Istio針對可擴充套件性進行了設計，以滿足不同的部署需要：

1.平臺支援。Istio旨在可以在各種環境中執行，包括跨雲、預置環境、Kubernetes、Mesos等。最初專注於Kubernetes，但很快將支援其他環境。

2.整合和定製。策略執行元件可以擴充套件和定製，以便與現有的ACL、日誌、監控、配額、稽核等解決方案整合。

三：整體架構

分為控制平面和資料平面兩部分：

控制平面 ：Pilot, Mixer, Istio-Auth，分別對Istio中的服務做流量管理，策略配置，安全通訊等規則配置 

資料平面 ：所有pod上的Envoy，負責所有規則的執行

主要構成元件：

1. Envoy ：用於調解服務網格中所有服務的所有入站和出站流量。支援例如動態服務發現，負載均衡，故障注入、流量管理等功能。Envoy 以 sidecar 的方式部署在相關的服務的 Pod 中。

2. Pilot ：Pilot 負責收集和驗證配置並將其傳播到各種 Istio元件。

3. Mixer ：負責在服務網格上執行訪問控制和使用策略，並從 Envoy 代理和其他服務收集遙測資料。

4. Istio-Auth ：提供強大的服務間認證和終端使用者認證。

四：Istio分散式追蹤實現原理

Istio 服務網格的核心是 Envoy，是一個高效能的開源 L7 代理和通訊匯流排。在 Istio 中，每個微服務都被注入了 Envoy Sidecar，該例項負責處理所有傳入和傳出的網路流量。因此，每個 Envoy Sidecar 都可以監控所有的服務間 API 呼叫，並記錄每次服務呼叫所需的時間以及是否成功完成。

每當微服務發起外部呼叫時，客戶端 Envoy 會建立一個新的 span。一個 span 代表一組微服務之間的完整互動過程，從請求者（客戶端）發出請求開始到接收到服務方的響應為止。

在服務互動過程中，客戶端會記錄請求的發起時間和響應的接收時間，伺服器端 Envoy 會記錄請求的接收時間和響應的返回時間。

每個 Envoy 都會將自己的 span 檢視資訊釋出到分散式追蹤系統。當一個微服務處理請求時，可能需要呼叫其他微服務，從而導致因果關聯的 span 的建立，形成完整的 trace。這就需要由應用來從請求訊息中收集和轉發下列 Header。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28624388/viewspace-2168782/，如需轉載，請註明出處，否則將追究法律責任。