Istio微服務治理筆記(一)

一 背景

1.1 微服務是什麼

• 服務之間有輕量級的通信機制，一般爲REST API
• 去中心化的管理機制
• 每一個服務可使用不一樣的編程語言實現，使用不一樣的數據存儲技術
• 應用按業務拆分紅服務，一個大型應用系統能夠由多個獨立的服務組成
• 各個服務都可獨立部署，都有本身的業務邏輯
• 服務可被多個應用共享，其餘服務可複用一些公共的資源服務

1.2 微服務的優點

• 模塊化開發，以單哥服務爲組件進行更新升級，提高系統總體異常穩定性

• 模塊化開發管理方便，單獨團隊開發維護，職責分明

• 模塊服用，公共服務模塊可被其餘業務模塊使用

• 系統架構更加分明

• 結合CI/CD，實現DevOPS

• 彈性伸縮，結合服務編排K8S動態HPA

• 服務熔斷/降級，避免但節點異常雪崩效應，分散故障節點

1.3 微服務帶來的挑戰

• 服務愈來愈多，配置管理維護複雜
• 服務間依賴關係複雜
• 服務調用鏈追蹤難
• 服務之間的負載均衡
• 服務的拓展
• 服務監控/日誌
• 服務熔斷/降級
• 服務鑑權
• 服務上線與下線
• 服務文檔
• ...

1.4 什麼是微服務治理

針對以微服務爲咱們帶來的方便以及挑戰，從裸金屬到虛擬化再到公有云，再到容器，到serverless，技術不斷革新，應對微服務帶來的挑戰，如何對服務進行註冊發現，請求鏈路追蹤，負載均衡，服務熔斷/降級，服務限流，訪問控制，監控日誌，配置管理，金絲雀發佈呢，本文爲本身學習Istio的筆記，istio解決了一些問題，還有一些挑戰須要其餘工具平臺解決，本文後續更新不斷，一塊來學習Kubernetes中服務治理神器Istio。

二 Istio介紹

2.1 istio是什麼

Istio 容許您鏈接、保護、控制和觀測微服務，在較高的層次上，Istio 有助於下降這些部署的複雜性，並減輕開發團隊的壓力。它是一個徹底開源的服務網格，能夠透明地分層到現有的分佈式應用程序上。它也是一個平臺，包括容許它集成到任何日誌記錄平臺、遙測或策略系統的 API。Istio 的多樣化功能集使您可以成功高效地運行分佈式微服務架構，並提供保護、鏈接和監控微服務的統一方法。

1.2 什麼是service mesh

在從單體應用程序向分佈式微服務架構的轉型過程當中，開發人員和運維人員面臨諸多挑戰，使用 Istio 能夠解決這些問題。

服務網格（Service Mesh）這個術語一般用於描述構成這些應用程序的微服務網絡以及應用之間的交互。隨着規模和複雜性的增加，服務網格愈來愈難以理解和管理。它的需求包括服務發現、負載均衡、故障恢復、指標收集和監控以及一般更加複雜的運維需求，例如 A/B 測試、金絲雀發佈、限流、訪問控制和端到端認證等。

Istio 提供了一個完整的解決方案，經過爲整個服務網格提供行爲洞察和操做控制來知足微服務應用程序的多樣化需求。

1.3 爲何使用istio

Istio 提供一種簡單的方式來爲已部署的服務創建網絡，該網絡具備負載均衡、服務間認證、監控等功能，只須要對服務的代碼進行一點或不須要作任何改動。想要讓服務支持 Istio，只須要在您的環境中部署一個特殊的 sidecar 代理，使用 Istio 控制平面功能配置和管理代理，攔截微服務之間的全部網絡通訊：

• HTTP、gRPC、WebSocket 和 TCP 流量的自動負載均衡。
• 經過豐富的路由規則、重試、故障轉移和故障注入，能夠對流量行爲進行細粒度控制。
• 可插入的策略層和配置 API，支持訪問控制、速率限制和配額。
• 對出入集羣入口和出口中全部流量的自動度量指標、日誌記錄和追蹤。
• 經過強大的基於身份的驗證和受權，在集羣中實現安全的服務間通訊。

Istio 旨在實現可擴展性，知足各類部署需求。

三 核心功能

3.1 流量管理

經過簡單的規則配置和流量路由，您能夠控制服務之間的流量和 API 調用。Istio 簡化了斷路器、超時和重試等服務級別屬性的配置，而且能夠輕鬆設置 A/B測試、金絲雀部署和基於百分比的流量分割的分階段部署等重要任務。

經過更好地瞭解您的流量和開箱即用的故障恢復功能，您能夠在問題出現以前先發現問題，使調用更可靠，而且使您的網絡更增強大——不管您面臨什麼條件。

• 負載均衡
• 動態路由
• 灰度發佈
• 故障注入

3.2 安全

Istio 的安全功能使開發人員能夠專一於應用程序級別的安全性。Istio 提供底層安全通訊信道，並大規模管理服務通訊的認證、受權和加密。使用Istio，服務通訊在默認狀況下是安全的，它容許您跨多種協議和運行時一致地實施策略——全部這些都不多或根本不須要應用程序更改。

雖然 Istio 與平臺無關，但將其與 Kubernetes（或基礎架構）網絡策略結合使用，其優點會更大，包括在網絡和應用層保護 pod 間或服務間通訊的能力。

• 認證
• 鑑權

3.3 可觀察行

Istio 強大的追蹤、監控和日誌記錄可以讓您深刻了解服務網格部署。經過 Istio 的監控功能，能夠真正瞭解服務性能如何影響上游和下游的功能，而其自定義儀表板能夠提供對全部服務性能的可視性，並讓您瞭解該性能如何影響您的其餘進程。

Istio 的 Mixer 組件負責策略控制和遙測收集。它提供後端抽象和中介，將 Istio 的其他部分與各個基礎架構後端的實現細節隔離開來，併爲運維提供對網格和基礎架構後端之間全部交互的細粒度控制。

全部這些功能可讓您能夠更有效地設置、監控和實施服務上的 SLO。固然，最重要的是，您能夠快速有效地檢測和修復問題。

• 調用鏈
• 訪問日誌
• 監控

3.4 平臺支持

stio 是獨立於平臺的，旨在運行在各類環境中，包括跨雲、內部部署、Kubernetes、Mesos 等。您能夠在 Kubernetes 上部署 Istio 或具備 Consul 的 Nomad 上部署。Istio 目前支持：

• 在 Kubernetes 上部署的服務
• 使用 Consul 註冊的服務
• 在虛擬機上部署的服務

3.5 集成和定製

策略執行組件能夠擴展和定製，以便與現有的 ACL、日誌、監控、配額、審計等方案集成。

四 架構

Istio 服務網格邏輯上分爲數據平面和控制平面。

• 數據平面由一組以 sidecar 方式部署的智能代理（Envoy）組成。這些代理能夠調節和控制微服務及 Mixer 之間全部的網絡通訊。
• 控制平面負責管理和配置代理來路由流量。此外控制平面配置 Mixer 以實施策略和收集遙測數據。

4.1 架構圖

4.2 組件

4.2.1 Envoy

Istio 使用 Envoy 代理的擴展版本，Envoy 是以 C++ 開發的高性能代理，用於調解服務網格中全部服務的全部入站和出站流量。Envoy 的許多內置功能被 Istio 發揚光大，例如：

• 動態服務發現
• 負載均衡
• TLS 終止
• HTTP/2 & gRPC 代理
• 熔斷器
• 健康檢查、基於百分比流量拆分的灰度發佈
• 故障注入
• 豐富的度量指標

Envoy 被部署爲 sidecar，和對應服務在同一個 Kubernetes pod 中。這容許 Istio 將大量關於流量行爲的信號做爲屬性提取出來，而這些屬性又能夠在 Mixer 中用於執行策略決策，併發送給監控系統，以提供整個網格行爲的信息。

Sidecar 代理模型還能夠將 Istio 的功能添加到現有部署中，而無需從新構建或重寫代碼。能夠閱讀更多來了解爲何咱們在設計目標中選擇這種方式。

4.2.2 Mixer

• 概念

Mixer 是一個獨立於平臺的組件，負責在服務網格上執行訪問控制和使用策略，並從 Envoy 代理和其餘服務收集遙測數據。代理提取請求級屬性，發送到 Mixer 進行評估。有關屬性提取和策略評估的更多信息，請參見 Mixer 配置。

Mixer 中包括一個靈活的插件模型，使其可以接入到各類主機環境和基礎設施後端，從這些細節中抽象出 Envoy 代理和 Istio 管理的服務。

• 架構圖

  

4.2.3 Pilot

• 概念

Pilot 爲 Envoy sidecar 提供服務發現功能，爲智能路由（例如 A/B 測試、金絲雀部署等）和彈性（超時、重試、熔斷器等）提供流量管理功能。它將控制流量行爲的高級路由規則轉換爲特定於 Envoy 的配置，並在運行時將它們傳播到 sidecar。

Pilot 將平臺特定的服務發現機制抽象化並將其合成爲符合 Envoy 數據平面 API 的任何 sidecar 均可以使用的標準格式。這種鬆散耦合使得 Istio 可以在多種環境下運行（例如，Kubernetes、Consul、Nomad），同時保持用於流量管理的相同操做界面。

• 架構圖

4.2.4 Citadel

• 概念

Citadel 經過內置身份和憑證管理賦能強大的服務間和最終用戶身份驗證。可用於升級服務網格中未加密的流量，併爲運維人員提供基於服務標識而不是網絡控制的強制執行策略的能力。從 0.5 版本開始，Istio 支持基於角色的訪問控制，以控制誰能夠訪問您的服務，而不是基於不穩定的三層或四層網絡標識。

• 架構圖

4.2.5 Galley

Galley 表明其餘的 Istio 控制平面組件，用來驗證用戶編寫的 Istio API 配置。隨着時間的推移，Galley 將接管 Istio 獲取配置、 處理和分配組件的頂級責任。它將負責將其餘的 Istio 組件與從底層平臺（例如 Kubernetes）獲取用戶配置的細節中隔離開來。

4.3 設計目標

• 最大化透明度：若想 Istio 被採納，應該讓運維和開發人員只需付出不多的代價就能夠從中受益。爲此，Istio 將自身自動注入到服務間全部的網絡路徑中。Istio 使用 sidecar 代理來捕獲流量，而且在儘量的地方自動編程網絡層，以路由流量經過這些代理，而無需對已部署的應用程序代碼進行任何改動。在 Kubernetes中，代理被注入到 pod 中，經過編寫 iptables 規則來捕獲流量。注入 sidecar 代理到 pod 中而且修改路由規則後，Istio 就可以調解全部流量。這個原則也適用於性能。當將 Istio 應用於部署時，運維人員能夠發現，爲提供這些功能而增長的資源開銷是很小的。全部組件和 API 在設計時都必須考慮性能和規模。
• 可擴展性：隨着運維人員和開發人員愈來愈依賴 Istio 提供的功能，系統必然和他們的需求一塊兒成長。雖然咱們指望繼續本身添加新功能，可是咱們預計最大的需求是擴展策略系統，集成其餘策略和控制來源，並將網格行爲信號傳播到其餘系統進行分析。策略運行時支持標準擴展機制以便插入到其餘服務中。此外，它容許擴展詞彙表，以容許基於網格生成的新信號來執行策略。
• 可移植性：使用 Istio 的生態系統將在不少維度上有差別。Istio 必須可以以最少的代價運行在任何雲或預置環境中。將基於 Istio 的服務移植到新環境應該是垂手可得的，而使用 Istio 將一個服務同時部署到多個環境中也是可行的（例如，在多個雲上進行冗餘部署）。
• 策略一致性：在服務間的 API 調用中，策略的應用使得能夠對網格間行爲進行全面的控制，但對於無需在 API 級別表達的資源來講，對資源應用策略也一樣重要。例如，將配額應用到 ML 訓練任務消耗的 CPU 數量上，比將配額應用到啓動這個工做的調用上更爲有用。所以，策略系統做爲獨特的服務來維護，具備本身的 API，而不是將其放到代理/sidecar 中，這允許服務根據須要直接與其集成。

參考連接

• juejin.im/post/5a3f20…
• juejin.im/post/5acb0d…
• juejin.im/post/5a727e…
• segmentfault.com/a/119000001…