kubernetes實踐之七十二：Istio之策略與遙測

一：Istio簡介

1.Istio定義

一個用來連線，管理和保護服務的開發平臺。Istio提供一種簡單的方式建立已部署服務網路，具備負載均衡，服務間認證和監控等功能。

而不需要改變任何服務程式碼。想要為服務增加對Istio的支援，只需要在環境中部署一個sidecar,使用Istio控制皮膚功能配置和管理代理，攔截微服務之間的所有網路通訊。

2.為什麼需要Istio

隨著微服務出現，微服務的連線，管理和監控成為難題。Kubernetes可以處理多個容器的工作負載，但當涉及更復雜的需求時，需要像Istio這樣的服務網格。

3.Istio的主要功能

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

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

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

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

4.Envoy架構

a.svcA服務作為客戶端點用服務端svcB，svcB存在有兩個版本，但是svcA並不知情

b.Envoy作為sidecar部署到各個svc到pod內，代理所有到進出流量

c.當svcA透過svcB到域名訪問其服務時，Envoy根據Pilot配置的路由規則，將1%的流量分給了svcB的alpha版本

5.Pilot架構

透過配置，Pilot可以使Envoy實現：路由配置、故障注入、流量遷移、請求超時、熔斷等諸多能力。

6.Mixer架構

Mixer主要提供三個核心功能：

前提條件檢查：發生在服務響應請求之前，如果檢查不透過可終止響應

配額管理：

遙測報告：可監控服務、上報日誌資訊

二：Mixer詳解

1. 基礎設施後端：

Mixer在應用程式程式碼和基礎架構後端之間提供通用中介層，

基礎設施後端旨在提供用於構建服務的支援功能。它們包括訪問控制系統，遙測捕獲系統，配額執行系統，計費系統等等。服務傳統上直接與這些後端系統整合，建立硬耦合，還有沾染特定的語義和使用選項。

Istio 提供統一抽象，使得 Istio 可以與一組開放式基礎設施後端進行互動。這樣做是為了給運維提供豐富而深入的控制，同時不給服務開發人員帶來負擔。Istio 旨在改變層與層之間的邊界，以減少系統複雜性，消除服務程式碼中的策略邏輯並將控制權交給運維

2. 屬性

屬性是描述出口入口流量的有名稱和型別的後設資料片段。 

Mixer在執行時，接受一組屬性，mixer根據配置處理傳入的屬性到適當的基礎設定後端。

功能：

a.前期條件檢查。 發生在請求處理前 ，請求被攔截到envoy時訪問mixer。 

允許服務在響應來自服務消費者的傳入請求之前驗證一些前提條件。前提條件可以包括服務使用者是否被正確認證，是否在服務的白名單上，是否透過ACL檢查等等。

b.配額管理。 發生在請求處理中 ，服務中需要呼叫後端基礎設施時。 

使服務能夠在分配和釋放多個維度上的配額，配額這一簡單的資源管理工具可以在服務消費者對有限資源發生爭用時，提供相對公平的（競爭手段）。頻率控制就是配額的一個例項。

c.遙測報告。發生在請求處理後 ，上報參考性資料給mixer。也因此，envoy擁有檢查pod健康能力。 

服務能夠上報日誌和監控。在未來，它還將啟用針對服務運營商以及服務消費者的跟蹤和計費流。 

遙測報告是非同步形式。即快取多條上報一次

3.介面卡

Mixer 是高度模組化和可擴充套件的元件。他的一個關鍵功能就是把不同後端的策略和遙測收集系統的細節抽象出來，使得 Istio 的其餘部分對這些後端不知情。

Mixer 處理不同基礎設施後端的靈活性是透過使用通用外掛模型實現的。每個外掛都被稱為 Adapter，Mixer透過它們與不同的基礎設施後端連線，這些後端可提供核心功能，例如日誌、監控、配額、ACL 檢查等。透過配置能夠決定在執行時使用的確切的介面卡套件，並且可以輕鬆擴充套件到新的或定製的基礎設施後端。

4.配置檔案示例

a.處理器(Handler):

介面卡封裝了 Mixer 和特定外部基礎設施後端進行互動的必要介面，例如 Prometheus 或者 Stackdriver。各種介面卡都需要引數配置才能工作。例如日誌介面卡可能需要 IP 地址和埠來進行日誌的輸出。

這裡的例子配置了一個型別為 listchecker 的介面卡。listchecker 介面卡使用一個列表來檢查輸入。如果配置的是白名單模式且輸入值存在於列表之中，就會返回成功的結果。

apiVersion: config.istio.io/v1alpha2
kind: listcheckermetadata:
name: staticversion  
namespace: istio-systemspec:
providerUrl: 
blacklist: false

{metadata.name}.{kind}.{metadata.namespace} 是 HANDLER 的完全限定名。上面定義的物件的 FQDN 就是 staticversion.listchecker.istio-system，他必須是唯一的。spec 中的資料結構則依賴於對應的介面卡的要求。

有些介面卡實現的功能就不僅僅是把 Mixer 和後端連線起來。例如 prometheus 介面卡消費指標並以可配置的方式將它們聚合成分佈或計數器。

apiVersion: config.istio.io/v1alpha2
kind: prometheusmetadata:
name: handler  
namespace: istio-systemspec:
  metrics:- name: request_count  
  instance_name: requestcount.metric.istio-system  
  kind: COUNTER  
  label_names:
  - destination_service  
  - destination_version  
  - response_code- name: request_duration  
  instance_name: requestduration.metric.istio-system  
  kind: DISTRIBUTION  
  label_names:
  - destination_service  -
   destination_version  
   - response_code    
   buckets:
    explicit_buckets:
      bounds: [0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10]

每個介面卡都定義了自己格式的配置資料。介面卡及其配置的詳盡列表可以在這裡找到

b.例項(Instance):

配置例項將請求中的屬性對映成為介面卡的輸入。下面的例子，是一個 metric 例項的配置，用於生成 requestduration metric。

apiVersion: config.istio.io/v1alpha2
kind: metricmetadata:
name: requestduration  
namespace: istio-systemspec:
  value: response.duration | "0ms"  dimensions:
    destination_service: destination.service | "unknown"    destination_version: destination.labels["version"] | "unknown"    
response_code: response.code | 200  
monitored_resource_type: '"UNSPECIFIED"'

c.規則(Rule):

規則用於指定使用特定例項配置呼叫某一 HANDLER 的時機。比如我們想要把 service1 服務中，請求頭中帶有 X-USER 的請求的 requestduration 指標傳送給 Prometheus HANDLER。

apiVersion: config.istio.io/v1alpha2
kind: rulemetadata:
  name: promhttp  
 namespace: istio-system
 spec:
  match: destination.service == "service1.ns.svc.cluster.local" && request.headers["x-user"] == "user1"  
 actions:- handler: handler.prometheus  
 instances:
  - requestduration.metric.istio-system

規則中包含有一個 MATCH 元素，用於前置檢查，如果檢查透過則會執行動作列表。動作中包含了一個例項列表，這個列表將會分發給 HANDLER。規則必須使用 HANDLER 和例項的完全限定名。如果規則、HANDLER 以及例項全都在同一個名稱空間，名稱空間字尾就可以在 FQDN 中省略，例如 handler.prometheus。