一：Istio簡(jiǎn)介

網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)公司！專(zhuān)注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、重慶小程序開(kāi)發(fā)公司、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶(hù)創(chuàng)新互聯(lián)還提供了武進(jìn)免費(fèi)建站歡迎大家使用！

1.Istio定義

一個(gè)用來(lái)連接，管理和保護(hù)服務(wù)的開(kāi)發(fā)平臺(tái)。Istio提供一種簡(jiǎn)單的方式建立已部署服務(wù)網(wǎng)絡(luò)，具備負(fù)載均衡，服務(wù)間認(rèn)證和監(jiān)控等功能。

而不需要改變?nèi)魏畏?wù)代碼。想要為服務(wù)增加對(duì)Istio的支持，只需要在環(huán)境中部署一個(gè)sidecar,使用Istio控制面板功能配置和管理代理，攔截微服務(wù)之間的所有網(wǎng)絡(luò)通信。

2.為什么需要Istio

隨著微服務(wù)出現(xiàn)，微服務(wù)的連接，管理和監(jiān)控成為難題。Kubernetes可以處理多個(gè)容器的工作負(fù)載，但當(dāng)涉及更復(fù)雜的需求時(shí)，需要像Istio這樣的服務(wù)網(wǎng)格。

3.Istio的主要功能

a.流量管理(Pilot): 控制服務(wù)之間的流量和API調(diào)用的流向，使得調(diào)用更靈活可靠，并使網(wǎng)絡(luò)在惡劣情況下更加健壯。

b.可觀察性： 通過(guò)集成zipkin等服務(wù)，快速了解服務(wù)之間的依賴(lài)關(guān)系，以及它們之間流量的本質(zhì)和流向，從而提供快速識(shí)別問(wèn)題的能力。

c.策略執(zhí)行(mixer): 將組織策略應(yīng)用于服務(wù)之間的互動(dòng)，確保訪問(wèn)策略得以執(zhí)行，資源在消費(fèi)者之間良好分配。策略的更改是通過(guò)配置網(wǎng)格而不是修改應(yīng)用程序代碼。

d.服務(wù)身份和安全(Istio-auth)： 為網(wǎng)格中的服務(wù)提供可驗(yàn)證身份，并提供保護(hù)服務(wù)流量的能力，使其可以在不同可信度的網(wǎng)絡(luò)上流轉(zhuǎn)。

4.Envoy架構(gòu)

a.svcA服務(wù)作為客戶(hù)端點(diǎn)用服務(wù)端svcB，svcB存在有兩個(gè)版本，但是svcA并不知情

b.Envoy作為sidecar部署到各個(gè)svc到pod內(nèi)，代理所有到進(jìn)出流量

c.當(dāng)svcA通過(guò)svcB到域名訪問(wèn)其服務(wù)時(shí)，Envoy根據(jù)Pilot配置的路由規(guī)則，將1%的流量分給了svcB的alpha版本

5.Pilot架構(gòu)

通過(guò)配置，Pilot可以使Envoy實(shí)現(xiàn)：路由配置、故障注入、流量遷移、請(qǐng)求超時(shí)、熔斷等諸多能力。

6.Mixer架構(gòu)

Mixer主要提供三個(gè)核心功能：

前提條件檢查：發(fā)生在服務(wù)響應(yīng)請(qǐng)求之前，如果檢查不通過(guò)可終止響應(yīng)

配額管理：

遙測(cè)報(bào)告：可監(jiān)控服務(wù)、上報(bào)日志信息

二：Mixer詳解

1. 基礎(chǔ)設(shè)施后端：

Mixer在應(yīng)用程序代碼和基礎(chǔ)架構(gòu)后端之間提供通用中介層，

基礎(chǔ)設(shè)施后端旨在提供用于構(gòu)建服務(wù)的支持功能。它們包括訪問(wèn)控制系統(tǒng)，遙測(cè)捕獲系統(tǒng)，配額執(zhí)行系統(tǒng)，計(jì)費(fèi)系統(tǒng)等等。服務(wù)傳統(tǒng)上直接與這些后端系統(tǒng)集成，創(chuàng)建硬耦合，還有沾染特定的語(yǔ)義和使用選項(xiàng)。

Istio 提供統(tǒng)一抽象，使得 Istio 可以與一組開(kāi)放式基礎(chǔ)設(shè)施后端進(jìn)行交互。這樣做是為了給運(yùn)維提供豐富而深入的控制，同時(shí)不給服務(wù)開(kāi)發(fā)人員帶來(lái)負(fù)擔(dān)。Istio 旨在改變層與層之間的邊界，以減少系統(tǒng)復(fù)雜性，消除服務(wù)代碼中的策略邏輯并將控制權(quán)交給運(yùn)維

2. 屬性

屬性是描述出口入口流量的有名稱(chēng)和類(lèi)型的元數(shù)據(jù)片段。 

Mixer在運(yùn)行時(shí)，接受一組屬性，mixer根據(jù)配置處理傳入的屬性到適當(dāng)?shù)幕A(chǔ)設(shè)置后端。

功能：

a.前期條件檢查。 發(fā)生在請(qǐng)求處理前 ，請(qǐng)求被攔截到envoy時(shí)訪問(wèn)mixer。 

允許服務(wù)在響應(yīng)來(lái)自服務(wù)消費(fèi)者的傳入請(qǐng)求之前驗(yàn)證一些前提條件。前提條件可以包括服務(wù)使用者是否被正確認(rèn)證，是否在服務(wù)的白名單上，是否通過(guò)ACL檢查等等。

b.配額管理。 發(fā)生在請(qǐng)求處理中 ，服務(wù)中需要調(diào)用后端基礎(chǔ)設(shè)施時(shí)。 

使服務(wù)能夠在分配和釋放多個(gè)維度上的配額，配額這一簡(jiǎn)單的資源管理工具可以在服務(wù)消費(fèi)者對(duì)有限資源發(fā)生爭(zhēng)用時(shí)，提供相對(duì)公平的（競(jìng)爭(zhēng)手段）。頻率控制就是配額的一個(gè)實(shí)例。

c.遙測(cè)報(bào)告。發(fā)生在請(qǐng)求處理后 ，上報(bào)參考性數(shù)據(jù)給mixer。也因此，envoy擁有檢查pod健康能力。 

服務(wù)能夠上報(bào)日志和監(jiān)控。在未來(lái)，它還將啟用針對(duì)服務(wù)運(yùn)營(yíng)商以及服務(wù)消費(fèi)者的跟蹤和計(jì)費(fèi)流。 

遙測(cè)報(bào)告是異步形式。即緩存多條上報(bào)一次

3.適配器

Mixer 是高度模塊化和可擴(kuò)展的組件。他的一個(gè)關(guān)鍵功能就是把不同后端的策略和遙測(cè)收集系統(tǒng)的細(xì)節(jié)抽象出來(lái)，使得 Istio 的其余部分對(duì)這些后端不知情。

Mixer 處理不同基礎(chǔ)設(shè)施后端的靈活性是通過(guò)使用通用插件模型實(shí)現(xiàn)的。每個(gè)插件都被稱(chēng)為 Adapter，Mixer通過(guò)它們與不同的基礎(chǔ)設(shè)施后端連接，這些后端可提供核心功能，例如日志、監(jiān)控、配額、ACL 檢查等。通過(guò)配置能夠決定在運(yùn)行時(shí)使用的確切的適配器套件，并且可以輕松擴(kuò)展到新的或定制的基礎(chǔ)設(shè)施后端。

4.配置文件示例

a.處理器(Handler):

適配器封裝了 Mixer 和特定外部基礎(chǔ)設(shè)施后端進(jìn)行交互的必要接口，例如 Prometheus 或者 Stackdriver。各種適配器都需要參數(shù)配置才能工作。例如日志適配器可能需要 IP 地址和端口來(lái)進(jìn)行日志的輸出。

這里的例子配置了一個(gè)類(lèi)型為 listchecker 的適配器。listchecker 適配器使用一個(gè)列表來(lái)檢查輸入。如果配置的是白名單模式且輸入值存在于列表之中，就會(huì)返回成功的結(jié)果。

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 的完全限定名。上面定義的對(duì)象的 FQDN 就是 staticversion.listchecker.istio-system，他必須是唯一的。spec 中的數(shù)據(jù)結(jié)構(gòu)則依賴(lài)于對(duì)應(yīng)的適配器的要求。

有些適配器實(shí)現(xiàn)的功能就不僅僅是把 Mixer 和后端連接起來(lái)。例如 prometheus 適配器消費(fèi)指標(biāo)并以可配置的方式將它們聚合成分布或計(jì)數(shù)器。

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]

每個(gè)適配器都定義了自己格式的配置數(shù)據(jù)。適配器及其配置的詳盡列表可以在這里找到

b.實(shí)例(Instance):

配置實(shí)例將請(qǐng)求中的屬性映射成為適配器的輸入。下面的例子，是一個(gè) metric 實(shí)例的配置，用于生成 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.規(guī)則(Rule):

規(guī)則用于指定使用特定實(shí)例配置調(diào)用某一 HANDLER 的時(shí)機(jī)。比如我們想要把 service1 服務(wù)中，請(qǐng)求頭中帶有 X-USER 的請(qǐng)求的 requestduration 指標(biāo)發(fā)送給 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

規(guī)則中包含有一個(gè) MATCH 元素，用于前置檢查，如果檢查通過(guò)則會(huì)執(zhí)行動(dòng)作列表。動(dòng)作中包含了一個(gè)實(shí)例列表，這個(gè)列表將會(huì)分發(fā)給 HANDLER。規(guī)則必須使用 HANDLER 和實(shí)例的完全限定名。如果規(guī)則、HANDLER 以及實(shí)例全都在同一個(gè)命名空間，命名空間后綴就可以在 FQDN 中省略，例如 handler.prometheus。