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: http://white_list_registry/  
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。