1. 程式人生 > 程式設計 >Istio微服務治理筆記(一)

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 中,這容許服務根據需要直接與其整合。

參考連結