Istio 流量治理

• 引言
• 目標規則(DestinationRule)
• • 流量策略(TrafficPolicy)
  • • tls (ClientTLSSettings)
    • subsets(服務版本 子集)
    • portLevelSettings(PortTrafficPolicy[])
    • 負載均衡配置(LoadBalancerSettings)
    • • simple方式
      • hash一致性方式(consistentHash)
      • 區域加權負載均衡(LocalityLoadBalancer)
• 熔斷降級
• • 連接池管理
  • 異常檢測（OutlierDetection 也叫離群檢測）
  • 服務重試
• 故障注入(HTTPFaultInjection)
• Sidecar配置

引言

流量治理是Istio的核心功能，通過使用Istio可以管理服務網格的服務發現、流量路由、負載均衡，簡化服務級屬性的配置，例如超時和重試等。

目標規則(DestinationRule)

在東西向流量管理的文章中我們簡單的了解過DestinationRule的subsets的作用，配合VirtrualService可以實現基于不同比例和通過header來控制流量導向。

這些規則還可以指定負載均衡的配置、來自Sidecar代理的連接池大小或異常檢測的設置，以實現從負載均衡池中檢測和驅逐不健康的主機。

DestinationRule定義了在路由發生后，應用于服務(對應host)流量的策略。

---

流量策略(TrafficPolicy)

在DestinationRule中我們可以配置TrafficPolicy，雖然它不是必須的。

tls (ClientTLSSettings)

我們在南北向流量管理中，也有一個tls設置，還記得嗎？不過那是在Gateway網關上的配置，其意義在于從集群外部到服務網格內部的流量設置，這和網格內的流量策略要區分開。
tls的mode有這幾種：

栗子:

apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata:name: db-mtls spec:host: mydbserver.prod.svc.cluster.localtrafficPolicy:tls:mode: MUTUALclientCertificate: /etc/certs/myclientcert.pemprivateKey: /etc/certs/client_private_key.pemcaCertificates: /etc/certs/rootcacerts.pem

subsets(服務版本 子集)

我們在東西向流量管理那篇文章中沒有寫trafficPolicy，我們可以看見這個字段并不是必須寫的，因為當時我們只是想簡單的分配比例和通過http headers導向不同版本，所以我們只使用了subsets。
其實我們可以根據subsets也可以定義不同的trafficPolicy，像是這樣：

apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata:name: bookinfo-ratings spec:host: ratings.prod.svc.cluster.localtrafficPolicy: # 如果沒有匹配subsets默認的流策loadBalancer:simple: LEAST_CONNsubsets:- name: testversionlabels:version: v3trafficPolicy: # 看這里哦loadBalancer:simple: ROUND_ROBIN

portLevelSettings(PortTrafficPolicy[])

針對某一具體目標我們可以定義流量策略，這些策略默認對目標服務端的所有端口有效。如果針對某一端口需要定義特定的策略，那么可以通過使用portLevelSettings(PortTrafficPolicy[]類型)來定義，像是這樣：

apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata:name: bookinfo-ratings-port spec:host: ratings.prod.svc.cluster.localtrafficPolicy: # Apply to all portsportLevelSettings:- port:number: 80loadBalancer:simple: LEAST_CONN- port:number: 9080loadBalancer:simple: ROUND_ROBIN

---

負載均衡配置(LoadBalancerSettings)

在trafficPolicy中我們看見了loadBalancer，上面2個例子都是使用simple方式的負載均衡算法，Istio其實提供了3種方式。

simple方式

我們先來看看simple提供的4種負載均衡算法:

• 輪訓模式
• 最少連接
• 隨機
• 透傳

hash一致性方式(consistentHash)

consistentHash的httpCookie栗子：
描述一個HTTP cookie，它將用作Consistent Hash負載平衡器的哈希鍵。如果不存在Cookie，則會生成它。

apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata:name: bookinfo-ratingsspec:host: ratings.prod.svc.cluster.localtrafficPolicy:loadBalancer:consistentHash:httpCookie:name: userttl: 0s # Cookie的生命周期 必須寫

區域加權負載均衡(LocalityLoadBalancer)

熔斷降級

Istio提供了一種非常實用且經過良好測試的熔斷模式，實現3個狀態機，這和Hystrix類似

• Closed
• Half-Open
• Open
  關于這3個狀態機，這里就不過多解釋了，應該都懂。

連接池管理

熔斷是分布式系統的重要組成部分，在整個微服務系統中，如果沒有熔斷，那么極大可能會因為某一服務掛掉導致整個服務雪崩。
Istio采用連接池管理Envoy代理在網絡級別實現強制斷路限制，而不必獨立配置和編寫對應每個應用程序的熔斷代碼。
我們可以通過trafficPolicy.connectionPoll來限制最大連接數和超時時間：

trafficPolicy:connectionPoll:tcp:maxConnections: 100connectTimeout: 30mshttp:http2MaxRequests: 1000maxRequestsPerConnection: 10

關于connectionPoll.tcp:

關于connectionPoll.http:

異常檢測（OutlierDetection 也叫離群檢測）

異常檢測OutlierDetection是Istio中熔斷具體實現，英文直譯離群檢測，是因為一旦達到需要移除的閾值就會被移出連接池。用于跟蹤上游服務中每個主機的狀態，適用于HTTP和TCP服務。對于HTTP服務來說，在預定時間段內，持續返回API調用的5XX錯誤的主機將在連接池中被移除。對于TCP服務來說，連接超時或連接失敗將認為異常。
白話的理解就是連接池負責熔斷降級，異常檢測負責將被降級或錯誤的服務移出連接池。
在不使用Istio的情況下我們只能做到熔斷降級，快速返回熔斷后被降級服務的響應。

優點:以前Hystrix只是針對單個服務實例的熔斷降級，而在微服務集群下，也許我們想要的是相同的服務均攤限流策略(有時候我們并不是用輪訓規則選擇服務)，而不是針對單個實例。所以Sentinel加入了集群限流模式，但是有時候我們的這些服務實例也許機器配置不同，集群限流模式下也許會讓比較差的服務器跟不上更高配置的機器。Istio的這種基礎架構上的異常離群檢測可以將單個服務實例暫時移出集群，比起集群限流來說更穩定。

我們可以通過trafficPolicy.outlierDetection來配置異常檢測：

apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata:name: test-policy spec:host: test.prod.svc.cluster.localtrafficPolicy:connectionPool:tcp:maxConnections: 1 # TCP最大連接數http:http1MaxPendingRequests: 1 # HTTP1.1 等待就緒連接池連接時排隊的最大請求數http2MaxRequests: 1 # HTTP2最大請求數maxRequestsPerConnection: 1 # 一個連接內能夠發出的最大請求數，如果為1那么就不會保持keepalive特性，因為這個連接只能發一次請求，也就不需要長連接了。outlierDetection: # 異常檢測consecutiveErrors: 1 # 連續錯誤數量interval: 1s # 移除檢測的時間間隔baseEjectionTime: 1m # 最小的移除時間長度，主機每次被移除后的隔離時間=移除次數*最小的移除時間長度maxEjectionPercent: 100 # 上游服務的負載均衡池中允許被移除主機的最大百分比，默認是10%

我們測試后，可以使用下面的命令進入pod中的sidecar代理查看關于upstream_rq_pending_xx日志。
upstream_rq_pending_overflow記錄的是熔斷次數。

kubectl exec it -n 命名空間 pod名 -c istio-proxy -- sh -c ‘curl localhost:15000/status’ | grep 服務名 | grep pending

服務重試

注意：這里開始是在VirtualService中了哦，不是DestinationRule.
Istio的VirtualService提供了用于定義HTTP請求失敗時的重試策略。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata:name: test-vs spec:hosts:- test.prod.svc.cluster.localhttp:- route:- destination:host: test.prod.svc.cluster.localsubset: v1retries:attempts: 3 # 給定請求的重試次數。重試之間的時間間隔將自動確定（25毫秒以上）perTryTimeout: 2s # 給定請求的每次重試嘗試超時retryOn: 5xx,gateway-error,connect-failure,refused-stream # 指定重試發生的條件。可以使用“，”分隔列表指定一個或多個策略

故障注入(HTTPFaultInjection)

故障注入HTTPFaultInjection用于在將HTTP請求轉發到路由中指定的目標時，指定要注入的一個或多個故障。故障規范是虛擬服務規則的一部分，包括從下游服務終止HTTP請求、延遲請求的代理等。
故障注入是混沌工程（說白話就是模擬故障）中經常用的一種手段。Istio支持2種故障注入手段(中斷abort和延遲delay)。

混沌工程，是一種提高技術架構彈性能力的復雜技術手段。Chaos工程經過實驗可以確保系統的可用性。混沌工程旨在將故障扼殺在襁褓之中，也就是在故障造成中斷之前將它們識別出來。通過主動制造故障，測試系統在各種壓力下的行為，識別并修復故障問題，避免造成嚴重后果。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata:name: test-vs spec:hosts:- test.prod.svc.cluster.localhttp:- route:- destination:host: test.prod.svc.cluster.localfault:#abort: # 表示將50%的請求直接返回502錯誤# httpStatus: 502# percentage:# value: 0.5delay: # 表示將50%的請求延遲5秒 如果是abort就是直接返回定義的錯誤fixedDelay: 5spercentage:value: 0.5

Sidecar配置

默認情況下，Istio將使用到達網格中每個工作負載實例所需的必要配置對網格中的所有Sidecar代理進行編程，并在與工作負載相關的所有端口上接受流量。Sidecar配置提供了一種方法，可以微調代理在與工作負載之間來回通信時，代理將接受的端口集，協議。此外，可以限制從工作負載實例轉發出站流量時，代理可以訪問的服務集。
注意:每個命名空間下只允許存在一個沒有workloadSelector的Sidecar配置。
默認情況下如果該命名空間下沒有Sidecar配置將使用根命名空間istio-config中的Sidecar配置。

注意：這里說的是Sidecar是資源，不是之前所說的Sidecar代理模式。
Sidecar資源包含了4個部分

IstioIngressListener在附加到工作負載實例的Sidecar代理上指定入站流量偵聽器的屬性。

IstioEgressListener在附加到工作負載實例的Sidecar代理上指定出站流量偵聽器的屬性。

栗子：

這個栗子在根命名空間istio-config下聲明了一個全局默認的Sidecar配置，它將所有命名空間中的Sidecar配置為出口流量只允許到同命名空間(并不是istio-config,而是指用了全局默認配置的命名空間本身)或istio-system命名空間中的工作負載服務。

apiVersion: networking.istio.io/v1alpha3 kind: Sidecar metadata:name: defaultnamespace: istio-config spec:egress:- hosts: - "./*"- "istio-system/*"

針對性的栗子：

apiVersion: networking.istio.io/v1alpha3 kind: Sidecar metadata:name: ratingsnamespace: prod-us1 spec:workloadSelector:labels:app: ratingsingress:- port:number: 9080protocol: HTTPname: somenamedefaultEndpoint: unix:///var/run/someuds.sockegress:- hosts:- "prod-us1/*"port:number: 9080protocol: HTTPname: egresshttp- hosts:- "istio-system/*"

上面的栗子是說，在prod-us1命名空間下，配置pod或VM標簽為app:ratings的工作負載實例使用此Sidecar配置進行限制，入口限制為僅允許9080端口（HTTP協議），并將它們轉發到附加的工作負載實例的unix套接字上。
對于出口流量只允許訪問prod-us1命名空間下9080端口的服務，或istio-system命名空間下的所有服務。
注意:因為我們寫了workloadSelector，所以prod-us1命名空間下還可以創建其他的Sidecar配置。

總結

以上是生活随笔為你收集整理的Istio 流量治理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。