[Istio是什麼？] 還不知道你就out了,一文40分鐘快速理解

@[toc]

前言

這篇文章屬於純理論，所含內容如下，按需閱讀：

Istio概念、服務網格、流量管理、istio架構（Envoy、Sidecar 、Istiod）
虛擬服務(VirtualService)、路由規則、目標規則(DestinationRule)
閘道器(Gateway)、網路彈性和測試（超時、重試、熔斷器、故障注入）

Istio是什麼？
Istio是一個開源的服務網格，透明的接入到分散式服務中。它也是一個平臺，整合任何日誌、遙測和策略系統的 API 介面。
Istio 成功高效地執行分散式微服務架構，並提供保護、連線和監控微服務的統一方法。
Istio 有助於降低 DevOps 壓力、開發團隊的壓力。

服務網格是什麼？

組成微服務網路
實現服務之間的互動

應用場景

服務發現、負載均衡、故障恢復、度量和監控
A/B 測試、金絲雀釋出、速率限制、訪問控制和端到端認證

為什麼使用Istio？

服務網格是透過sidecar（邊車）代理服務實現，控制平面主要是對sidecar的配置和管理，這包括：

為 HTTP、gRPC、WebSocket 和 TCP 流量自動負載均衡。
透過豐富的路由規則、重試、故障轉移和故障注入對流量行為進行細粒度控制。
可插拔的策略層和配置 API，支援訪問控制、速率限制和配額。
叢集內（包括叢集的入口和出口）所有流量的自動化度量、日誌記錄和追蹤。
在具有強大的基於身份驗證和授權的叢集中實現安全的服務間通訊。

Istio還支援擴充套件，滿足你部署需求！

流量管理介紹

Istio流量路由規則可以很容易的控制服務之間的流量和API呼叫。能實現A/B測試、金絲雀釋出、基於流量百分比釋出。
開箱即用的故障恢復特性，有助於增強應用的健壯性，從而更好地應對被依賴的服務或網路發生故障的情況。
Istio 的流量管理由Envoy代理服務提供。網格內服務傳送和接收的所有流量都由 Envoy 代理處理，讓控制網格內的流量變得異常簡單，不需要對服務做更改。

為了在網格中導流，Istio 需要知道 endpoint 在哪和屬於哪個服務。為了定位到service registry(服務註冊中心)，Istio 會連線到一個服務發現系統。例如，如果您在 Kubernetes 叢集上安裝了 Istio，那麼它將自動檢測該叢集中的服務和 endpoint（端點）。

使用此服務註冊中心，Envoy 代理可以將流量定向到相關服務。大多數基於微服務的應用程式，每個服務的工作負載都有多個例項來處理流量，稱為負載均衡池。預設情況下，Envoy 代理基於輪詢排程在服務的負載均衡池內分發流量，按順序請求傳送給池中每個成員，一旦所有服務例項均接收過一次請求後，重新回到第一個池成員。

這些 API 也使用 Kubernetes 的自定義資源定義（CRDs）來宣告，可以使用 YAML 進行配置。

istio架構

Istio 服務網格邏輯上分為資料平面和控制平面

資料平面：Envoy代理被部署為sidecar，負責協調和控制微服務之間的通訊，收集和報告所有網格流量的遙測資料。
控制平面：管理並配置Envoy代理
Envoy
C++ 開發的高效能代理，用於協調服務網格中所有服務的入站和出站流量。Envoy 代理是唯一與資料平面流量互動的 Istio 元件。

Envoy 代理被部署為服務的 Sidecar，在邏輯上為服務增加了 Envoy 的許多內建特性，例如：

動態服務發現
負載均衡
TLS 終端
HTTP/2 與 gRPC 代理
熔斷器
健康檢查
基於百分比流量分割的分階段釋出
故障注入
豐富的指標

Sidecar

允許 Istio 可以執行策略決策，提取豐富的遙測資料，接著將這些資料傳送到監視系統以提供整個網格行為的資訊。
Sidecar 代理還允許向 Istio 新增功能，不需要重新設計架構或重寫程式碼。

Istiod

Istiod 提供服務發現、配置和證書管理。
Istiod 將控制流量的高階路由規則轉換為 Envoy 特定的配置，並在執行時傳播給 Sidecar。
Istiod 安全透過內建的身份和憑證管理，實現了強大的服務對服務和終端使用者認證。
Istiod 充當證書授權（CA），生成證書以允許在資料平面中進行 mTLS 通訊。

虛擬服務(VirtualService)
配置請求流量到服務,基於連通性和服務發現能力。
每個虛擬服務包含一組路由規則。可以實現負載均衡、基於不同版本流量百分比路由。

為什麼使用虛擬服務？

虛擬服務在增強 Istio 流量管理方面，發揮著至關重要的作用，透過對客戶端請求與真實響應請求的目標工作負載進行解耦來實現。
基於不同服務版本的流量百分比路由，實現A/B 測試、金絲雀釋出。

栗子

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3

hosts欄位

虛擬服務的主機，客戶端請求或路由規則的目標地址。
虛擬服務主機名可以是 IP 地址、DNS 名稱，或者依賴於平臺的一個簡稱（Kubernetes 服務的短名稱）也可以使用萬用字元（“*”）字首

路由規則

http 欄位包含虛擬服務的路由規則，用來描述匹配條件和路由行為，它們把 HTTP/1.1、HTTP2 和 gRPC 等流量傳送到 hosts 欄位指定的目標
一個路由規則包含了請求要流向哪個目標地址，具有 0 或多個匹配條件，取決於您的使用場景。

匹配條件

示例中的第一個路由規則有一個條件，因此以 match 欄位開始。在本例中，您希望此路由應用於來自 ”jason“ 使用者的所有請求，所以使用 headers、end-user 和 exact 欄位選擇適當的請求。

- match:
   - headers:
       end-user:
         exact: jason

Destination

route 部分的 destination 欄位指符合此條件的流量的實際目標地址。
與虛擬服務的 hosts 不同，destination 的 host 必須是存在於 Istio 服務註冊中心的實際目標地址，否則 Envoy 不知道該將請求傳送到哪裡。

route:
- destination:
    host: reviews
    subset: v2

destination 片段還指定了 Kubernetes 服務的子集，將符合此規則條件的請求轉入其中，本例中子集名稱是 v2。

路由規則優先順序

路由規則按從上到下的順序選擇，虛擬服務中定義的第一條規則有最高優先順序，不滿足第一個路由規則的流量均流向一個預設的目標。

本例中：第二條規則沒有 match 條件，直接將流量導向 v3 子集。

- route:
  - destination:
      host: reviews
      subset: v3

路由規則的更多內容

可以在流量埠、header 欄位、URI 等內容上設定匹配條件

匹配條件：

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳

目標規則(DestinationRule)

可以將虛擬服務視為將流量如何路由到目標地址，然後目標規則來配置該目標的流量。虛擬服務路由規則之後，目標規則將應用於流量的“真實”目標地址。

簡單來說：虛擬服務透過目標規則後，到達目標地址（服務）

應用場景：整個目的地服務或特定服務子集時定製 Envoy 的流量策略，負載均衡模型、TLS 安全模式或熔斷器設定。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination-rule
spec:
  host: my-svc
  trafficPolicy:
    loadBalancer:
      simple: RANDOM  # 隨機負載均衡器
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN   # 輪詢負載均衡器
  - name: v3
    labels:
      version: v3

每個子集都是基於一個或多個 labels 定義的，標籤應用於kubernetes叢集中deployment控制器metadata欄位來識別不同版本。

負載均衡選項

Istio 預設使用輪詢的負載均衡策略，Istio 同時支援如下的負載均衡模型，可以在 DestinationRule 中為指定：

隨機：請求以隨機的方式轉到池中的例項。
權重：請求根據指定的百分比轉到例項。
最少請求：請求被轉到最少被訪問的例項。

閘道器(Gateway)
管理入站和出站流量，閘道器配置網格邊界的獨立 Envoy 代理，而不是服務工作負載的 sidecar 代理。
Istio 閘道器可以配置 4-6 層的負載均衡屬性，如對外暴露的埠、TLS 設定等
閘道器主要用於管理進入的流量
Istio 提供了預先配置的閘道器代理（istio-ingressgateway 和 istio-egressgateway）

栗子

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: ext-host-gwy
spec:
  selector:
    istio: ingressgateway  # use istio default controller
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - ext-host.example.com
    tls:
      mode: SIMPLE
      serverCertificate: /tmp/tls.crt
      privateKey: /tmp/tls.key

這個閘道器配置讓 HTTPS 流量從 ext-host.example.com 透過 443 埠流入網格，但沒有為請求指定任何路由規則。為想要工作的閘道器指定路由，您必須把閘道器繫結到虛擬服務上。

如下面的示例所示，使用虛擬服務的 gateways 欄位進行設定：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: virtual-svc
spec:
  hosts:
  - ext-host.example.com
  gateways:
    - ext-host-gwy

然後就可以為出口流量配置帶有路由規則的虛擬服務。

Sidecar

預設情況下，Istio 讓每個 Envoy 代理都可以訪問和它關聯工作負載的所有埠的請求，然後轉發到對應的工作負載。

可以使用 sidecar配置做：

微調 Envoy 代理接受的埠和協議集。
限制 Envoy 代理可以訪問的服務集合。

在較龐大的應用程式中限制 sidecar 可達性，配置每個代理能訪問網格中的任意服務，可能會因為高記憶體使用量而影響網格的效能。

可以指定將 sidecar 配置應用於特定名稱空間中的所有工作負載，或者使用 workloadSelector 選擇特定的工作負載

例如，下面的 sidecar 配置將 bookinfo 名稱空間中的所有服務配置為，僅能訪問執行在相同名稱空間和 Istio 控制平面中的服務：

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
  namespace: bookinfo
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"

網路彈性和測試

除了網格導流外，Istio 還提供了故障恢復和故障注入功能，您可以在執行時動態配置這些功能。使用這些特性可以讓您的應用程式執行穩定，確保服務網格能夠容忍故障節點，並防止區域性故障級聯影響到其他節點。

超時

超時是 Envoy 代理等待來自給服務答覆的時間，確保服務不會因為等待答覆而無限期的掛起。HTTP 請求的預設超時時間是 15 秒，這意味著如果服務在 15 秒內沒有響應，呼叫將失敗。

為了找到最佳超時設定，Istio 允許使用虛擬服務，按服務輕鬆地動態調整超時，而不必修改您的業務程式碼。

栗子：

一個虛擬服務，對 ratings 服務的 v1 子集的呼叫，指定 10 秒超時時間

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    timeout: 10s

重試

服務為初始呼叫失敗，Envoy 代理嘗試連線服務的最大次數。確保呼叫不會因為臨時過載的服務或網路等問題而永久失敗。

重試之間的間隔（25ms+）是可變的，HTTP 請求的預設重試行為是在返回錯誤之前重試兩次。

應用場景：與超時一樣，Istio 預設的重試行為在延遲方面可能不適合您的應用程式需求（對失敗的服務進行過多的重試會降低速度）或可用性。

栗子

配置了在初始呼叫失敗後,最多重試 3 次來連線到服務子集，每個重試都有 2 秒的超時。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    retries:
      attempts: 3
      perTryTimeout: 2s

熔斷器

熔斷器中，設定一個對服務中單個主機呼叫的限制，例如併發連線的數量或對該主機呼叫失敗的次數。一旦限制被觸發，熔斷器就會“跳閘”並停止連線到該主機。

作用：使用熔斷模式可以快速失敗而不必讓客戶端嘗試連線到過載或有故障的主機。

熔斷適用於在負載均衡池中的“真實”網格目標地址，可以在目標規則中配置熔斷器閾值，讓配置適用於服務中的每個主機。

栗子：

將 v1 子集的reviews服務工作負載的併發連線數限制為 100：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100

故障注入

是什麼：可以使用 Istio 的故障注入機制來為整個應用程式測試故障恢復能力。

為什麼使用：故障注入是一種將錯誤引入系統以確保系統能夠承受並從錯誤條件中恢復的測試方法。

作用：使用故障注入特別有用，能確保故障恢復策略不至於不相容或者太嚴格，這會導致關鍵服務不可用。

可以注入兩種故障，都使用虛擬服務配置：

延遲：延遲是時間故障。它們模擬增加的網路延遲或一個超載的上游服務。
終止：終止是崩潰失敗。他們模仿上游服務的失敗。終止通常以 HTTP 錯誤碼或 TCP 連線失敗的形式出現。

栗子：

千分之一訪問ratings 服務的請求，配置了一個 5 秒的延遲：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percentage:
          value: 0.1
        fixedDelay: 5s
    route:
    - destination:
        host: ratings
        subset: v1

和您的應用程式一起執行

Istio 故障恢復功能對應用程式來說是完全透明的。在返回響應之前，應用程式不知道 Envoy sidecar 代理是否正在處理被呼叫服務的故障。這意味著，如果在應用程式程式碼中設定了故障恢復策略，那麼您需要記住這兩個策略都是獨立工作的，否則會發生衝突。

例如，假設您設定了兩個超時，一個在虛擬服務中配置，另一個在應用程式中配置。應用程式為服務的 API 呼叫設定了 2 秒超時。而您在虛擬服務中配置了一個 3 秒超時和重試。在這種情況下，應用程式的超時會先生效，因此 Envoy 的超時和重試嘗試會失效。

雖然 Istio 故障恢復特性提高了網格中服務的可靠性和可用性，但應用程式必須處理故障或錯誤並採取適當的回退操作。例如，當負載均衡中的所有例項都失敗時，Envoy 返回一個HTTP 503程式碼。應用程式必須實現回退邏輯來處理HTTP 503錯誤程式碼。

總結

這篇花費了不少精力，還望博友們支援支援新人！！！

後期會發布一篇實際操作，期待大家持續關注！！！

學習不走彎路，關注v「yeTechLog」

[Istio是什麼？] 還不知道你就out了,一文40分鐘快速理解

前言

Istio是什麼？

服務網格是什麼？

應用場景

為什麼使用Istio？

流量管理介紹

istio架構

Envoy

Sidecar

Istiod

虛擬服務(VirtualService)

為什麼使用虛擬服務？

栗子

路由規則

匹配條件

Destination

路由規則優先順序

路由規則的更多內容

目標規則(DestinationRule)

負載均衡選項

閘道器(Gateway)

栗子

Sidecar

網路彈性和測試

超時

重試

栗子

熔斷器

故障注入

和您的應用程式一起執行

總結

相關文章