Istio是一個(gè)開(kāi)源的服務(wù)網(wǎng)格，可為分布式微服務(wù)架構(gòu)提供所需的基礎(chǔ)運(yùn)行和管理要素。隨著各組織越來(lái)越多地采用云平臺(tái)，開(kāi)發(fā)者必須使用微服務(wù)設(shè)計(jì)架構(gòu)以實(shí)現(xiàn)可移植性，而運(yùn)維人員必須管理包含混合云部署和多云部署的大型分布式應(yīng)用。Istio采用一種一致的方式來(lái)保護(hù)、連接和監(jiān)控微服務(wù)，降低了管理微服務(wù)部署的復(fù)雜性。

從架構(gòu)設(shè)計(jì)上來(lái)看，Istio服務(wù)網(wǎng)格在邏輯上分為控制平面和數(shù)據(jù)平面兩部分。其中，控制平面Pilot負(fù)責(zé)管理和配置代理來(lái)路由流量，并配置Mixer以實(shí)施策略和收集遙測(cè)數(shù)據(jù)；數(shù)據(jù)平面由一組以Sidecar方式部署的智能代理（Envoy）組成，這些代理可以調(diào)節(jié)和控制微服務(wù)及Mixer之間所有的網(wǎng)絡(luò)通信。

Istio架構(gòu)

作為代理，Envoy非常適合服務(wù)網(wǎng)格的場(chǎng)景，但要發(fā)揮Envoy的最大價(jià)值，就需要使它很好地與底層基礎(chǔ)設(shè)施或組件緊密配合。Envoy構(gòu)成了服務(wù)網(wǎng)格的數(shù)據(jù)平面，Istio提供的支撐組件則是創(chuàng)建了控制平面。

Pilot與Envoy數(shù)據(jù)平面

一方面，我們?cè)贓nvoy中看到，可以使用靜態(tài)配置文件或使用一組發(fā)現(xiàn)服務(wù)來(lái)配置一組服務(wù)代理，以便在運(yùn)行時(shí)發(fā)現(xiàn)監(jiān)聽(tīng)器、端點(diǎn)和集群。Istio在Pilot中實(shí)現(xiàn)了這些Envoy代理的xDS API。

另一方面，Envoy的服務(wù)發(fā)現(xiàn)依賴于某種服務(wù)注冊(cè)表來(lái)發(fā)現(xiàn)服務(wù)端點(diǎn)。Istio Pilot實(shí)現(xiàn)了這個(gè)API，但也將Envoy從任何特定的服務(wù)注冊(cè)實(shí)現(xiàn)中抽象出來(lái)。當(dāng)Istio部署在Kubernetes上時(shí)，Kubernetes的服務(wù)注冊(cè)表是Istio用于服務(wù)發(fā)現(xiàn)的。其他注冊(cè)表也可以像HashiCorp的Consul那樣使用。Envoy數(shù)據(jù)平面完全不受這些實(shí)施細(xì)節(jié)的影響。

Mixer架構(gòu)

此外，Envoy代理可以發(fā)出很多指標(biāo)和遙測(cè)數(shù)據(jù)，這些遙測(cè)數(shù)據(jù)發(fā)送到何處，取決于Envoy的配置。Istio提供遙測(cè)接收器Mixer作為其控制平面的一部分，Envoy代理可以將這些數(shù)據(jù)發(fā)送到Mixer。Envoy還將分布式跟蹤數(shù)據(jù)發(fā)送到開(kāi)放式跟蹤引擎（遵循Open Tracing API）。Istio可以支持兼容的開(kāi)放式跟蹤引擎并配置Envoy將其跟蹤數(shù)據(jù)發(fā)送到該位置。

剖析Istio控制平面

Istio的控制平面和Envoy的數(shù)據(jù)平面共同構(gòu)成了一個(gè)引人注目的服務(wù)網(wǎng)格實(shí)現(xiàn)。兩者都擁有蓬勃發(fā)展和充滿活力的社區(qū)，并且面向下一代服務(wù)架構(gòu)。Istio是獨(dú)立于平臺(tái)的，可運(yùn)行于各種環(huán)境中，包括跨云、內(nèi)部部署、Kubernetes、Mesos等。你可以在Kubernetes 上部署Istio或在具有Consul的Nomad上部署。Istio目前支持在Kubernetes上部署的服務(wù)、使用Consul注冊(cè)的服務(wù)以及在虛擬機(jī)上部署的服務(wù)。

其中，控制平面部分包括了Pilot、Mixer、Citadel和Galley四個(gè)組件。

Pilot

Istio的Pilot組件用于管理流量，可以控制服務(wù)之間的流量流動(dòng)和API調(diào)用，通過(guò)Pilot可以更好地了解流量，以便在問(wèn)題出現(xiàn)之前發(fā)現(xiàn)問(wèn)題。這使得調(diào)用更加可靠、網(wǎng)絡(luò)更加強(qiáng)健，即使遇到不利條件也能讓?xiě)?yīng)用穩(wěn)如磐石。借助Istio的Pilot，你能夠配置熔斷器、超時(shí)和重試等服務(wù)級(jí)屬性，并設(shè)置常見(jiàn)的連續(xù)部署任務(wù)，如金絲雀發(fā)布、A/B測(cè)試和基于百分比拆分流量的分階段發(fā)布。Pilot為Envoy代理提供服務(wù)發(fā)現(xiàn)功能，為智能路由和彈性能力（如超時(shí)、重試、熔斷器等）提供流量管理功能。Pilot將控制流量行為的高級(jí)路由規(guī)則轉(zhuǎn)換為特定于Envoy代理的配置，并在運(yùn)行時(shí)將它們傳播到Envoy。此外，Istio提供了強(qiáng)大的開(kāi)箱即用故障恢復(fù)功能，包括超時(shí)、支持超時(shí)預(yù)算和變量抖動(dòng)的重試機(jī)制、發(fā)往上游服務(wù)的并發(fā)連接和請(qǐng)求數(shù)限制、對(duì)負(fù)載均衡池中的每個(gè)成員進(jìn)行的定期主動(dòng)運(yùn)行狀況檢查，以及被動(dòng)運(yùn)行狀況檢查。

Pilot將平臺(tái)特定的服務(wù)發(fā)現(xiàn)機(jī)制抽象化并將其合成為標(biāo)準(zhǔn)格式，符合數(shù)據(jù)平面API的任何Sidecar都可以使用這種標(biāo)準(zhǔn)格式。這種松散耦合使得Istio能夠在多種環(huán)境下運(yùn)行（例如Kubernetes、Consul、Nomad），同時(shí)可保持用于流量管理的操作界面相同。

Mixer

Istio的Mixer組件提供策略控制和遙測(cè)收集功能，將Istio的其余部分與各個(gè)后端基礎(chǔ)設(shè)施后端的實(shí)現(xiàn)細(xì)節(jié)隔離開(kāi)來(lái)。Mixer是一個(gè)獨(dú)立于平臺(tái)的組件，負(fù)責(zé)在服務(wù)網(wǎng)格上執(zhí)行訪問(wèn)控制和使用策略，并從Envoy代理和其他服務(wù)收集遙測(cè)數(shù)據(jù)。代理提取請(qǐng)求級(jí)屬性，發(fā)送到Mixer進(jìn)行評(píng)估。

Mixer中包括一個(gè)靈活的插件模型，使其能夠接入到各種主機(jī)環(huán)境和后端基礎(chǔ)設(shè)施，從這些細(xì)節(jié)中抽象出Envoy代理和Istio管理的服務(wù)。利用Mixer，你可以精細(xì)控制網(wǎng)格和后端基礎(chǔ)設(shè)施后端之間的所有交互。

與必須節(jié)省內(nèi)存的Sidecar代理不同，Mixer獨(dú)立運(yùn)行，因此它可以使用相當(dāng)大的緩存和輸出緩沖區(qū)，充當(dāng)Sidecar的高度可伸縮且高度可用的二級(jí)緩存。

Mixer旨在為每個(gè)實(shí)例提供高可用性。它的本地緩存和緩沖區(qū)可以減少延遲時(shí)間，還有助于屏蔽后端基礎(chǔ)設(shè)施后端故障，即使后端沒(méi)有響應(yīng)也是如此。

Citadel

Istio Citadel安全功能提供強(qiáng)大的身份驗(yàn)證功能、強(qiáng)大的策略、透明的TLS加密以及用于保護(hù)服務(wù)和數(shù)據(jù)的身份驗(yàn)證、授權(quán)和審計(jì)（AAA）工具，Envoy可以終止或向網(wǎng)格中的服務(wù)發(fā)起TLS流量。為此，Citadel需要支持創(chuàng)建、簽署和輪換證書(shū)。Istio Citadel提供特定于應(yīng)用程序的證書(shū)，可用于建立雙向TLS以保護(hù)服務(wù)之間的流量。

Istio Citadel架構(gòu)

借助Istio Citadel，確保只能從經(jīng)過(guò)嚴(yán)格身份驗(yàn)證和授權(quán)的客戶端訪問(wèn)包含敏感數(shù)據(jù)的服務(wù)。Citadel通過(guò)內(nèi)置身份和憑證管理提供了強(qiáng)大的服務(wù)間和最終用戶身份驗(yàn)證。可用于升級(jí)服務(wù)網(wǎng)格中未加密的流量，并為運(yùn)維人員提供基于服務(wù)標(biāo)識(shí)而不是網(wǎng)絡(luò)控制的強(qiáng)制執(zhí)行策略的能力。Istio的配置策略在服務(wù)器端配置平臺(tái)身份驗(yàn)證，但不在客戶端強(qiáng)制實(shí)施該策略，同時(shí)允許你指定服務(wù)的身份驗(yàn)證要求。Istio的密鑰管理系統(tǒng)可自動(dòng)生成、分發(fā)、輪換與撤銷(xiāo)密鑰和證書(shū)。

Istio RBAC為Istio網(wǎng)格中的服務(wù)提供命名空間級(jí)別、服務(wù)級(jí)別和方法級(jí)別的訪問(wèn)權(quán)限控制，包括易于使用的基于角色的語(yǔ)義、服務(wù)到服務(wù)和最終用戶到服務(wù)的授權(quán)，并在角色和角色綁定方面提供靈活的自定義屬性支持。

Istio可以增強(qiáng)微服務(wù)及其通信（包括服務(wù)到服務(wù)和最終用戶到服務(wù)的通信）的安全性，且不需要更改服務(wù)代碼。它為每個(gè)服務(wù)提供基于角色的強(qiáng)大身份機(jī)制，以實(shí)現(xiàn)跨集群、跨云端的交互操作。

Galley

Galley用于驗(yàn)證用戶編寫(xiě)的Istio API配置。隨著時(shí)間的推移，Galley將接管Istio獲取配置、處理和分配組件的頂級(jí)責(zé)任。它負(fù)責(zé)將其他的Istio組件與從底層平臺(tái)（例如Kubernetes）獲取用戶配置的細(xì)節(jié)中隔離開(kāi)來(lái)。

總而言之，通過(guò)Pilot，Istio可在部署規(guī)模逐步擴(kuò)大的過(guò)程中幫助你簡(jiǎn)化流量管理。通過(guò)Mixer，借助強(qiáng)健且易于使用的監(jiān)控功能，能夠快速有效地檢測(cè)和修復(fù)問(wèn)題。通過(guò)Citadel，減輕安全負(fù)擔(dān)，讓開(kāi)發(fā)者可以專(zhuān)注于其他關(guān)鍵任務(wù)。

Istio的架構(gòu)設(shè)計(jì)中有幾個(gè)關(guān)鍵目標(biāo)，這些目標(biāo)對(duì)于系統(tǒng)應(yīng)對(duì)大規(guī)模流量和高性能的服務(wù)處理至關(guān)重要。

• 最大化透明度：要采用Istio，應(yīng)該讓運(yùn)維和開(kāi)發(fā)人員只需付出很少的代價(jià)就可以從中獲得實(shí)際價(jià)值。為此，Istio將自身自動(dòng)注入到服務(wù)間所有的網(wǎng)絡(luò)路徑中。Istio使用Envoy代理來(lái)捕獲流量，并且在可能的情況下自動(dòng)對(duì)網(wǎng)絡(luò)層進(jìn)行編程，以便通過(guò)這些代理路由流量，而無(wú)需對(duì)已部署的應(yīng)用程序代碼進(jìn)行太多的更改，甚至不需要任何更改。在Kubernetes中，Envoy代理被注入到pod中，通過(guò)iptables規(guī)則來(lái)捕獲流量。一旦注入Envoy代理到pod中并且修改路由規(guī)則，Istio就能夠調(diào)節(jié)所有流量。這個(gè)原則也適用于性能。當(dāng)將Istio用于部署時(shí)，運(yùn)維人員可以發(fā)現(xiàn)，為提供這些功能而增加的資源開(kāi)銷(xiāo)是很小的。所有組件和API在設(shè)計(jì)時(shí)都必須考慮性能和規(guī)模。

• 可擴(kuò)展性：隨著運(yùn)維人員和開(kāi)發(fā)人員越來(lái)越依賴Istio提供的功能，系統(tǒng)必然和他們的需求一起成長(zhǎng)。在我們繼續(xù)添加新功能的同時(shí)，最需要的是能夠擴(kuò)展策略系統(tǒng)，集成其他策略和控制來(lái)源，并將網(wǎng)格行為信號(hào)傳播到其他系統(tǒng)進(jìn)行分析。策略運(yùn)行時(shí)支持標(biāo)準(zhǔn)擴(kuò)展機(jī)制以便插入到其他服務(wù)中。此外，它允許擴(kuò)展詞匯表，以允許基于網(wǎng)格生成的新信號(hào)來(lái)強(qiáng)制執(zhí)行策略。

• 可移植性：使用Istio的生態(tài)系統(tǒng)在很多方面都有所不同。Istio必須能夠以最少的代價(jià)運(yùn)行在任何云或本地環(huán)境中。將基于Istio的服務(wù)移植到新環(huán)境應(yīng)該是輕而易舉的，而使用Istio將一個(gè)服務(wù)同時(shí)部署到多個(gè)環(huán)境中也是可行的，例如可以在混合云上部署以實(shí)現(xiàn)冗余災(zāi)備。

• 策略一致性：策略應(yīng)用于服務(wù)之間的API調(diào)用，可以很好地控制網(wǎng)格行為。但對(duì)于無(wú)需在API級(jí)別表達(dá)的資源來(lái)說(shuō)，對(duì)資源應(yīng)用策略也同樣重要。例如，將配額應(yīng)用到機(jī)器學(xué)習(xí)訓(xùn)練任務(wù)消耗的CPU數(shù)量上，比將配額應(yīng)用到啟動(dòng)這個(gè)工作的調(diào)用上更為有用。因此，Istio將策略系統(tǒng)維護(hù)為具有自己的API的獨(dú)特服務(wù)，而不是將其放到代理中，這允許服務(wù)根據(jù)需要直接與其集成。

剖析Istio數(shù)據(jù)平面

當(dāng)介紹服務(wù)網(wǎng)格的概念時(shí)，提到了服務(wù)代理的概念以及如何使用代理構(gòu)建一個(gè)服務(wù)網(wǎng)格，以調(diào)節(jié)和控制微服務(wù)之間的所有網(wǎng)絡(luò)通信。Istio使用Envoy代理作為默認(rèn)的開(kāi)箱即用服務(wù)代理，這些Envoy代理與參與服務(wù)網(wǎng)格的所有應(yīng)用程序?qū)嵗黄疬\(yùn)行，但不在同一個(gè)容器進(jìn)程中，形成了服務(wù)網(wǎng)格的數(shù)據(jù)平面。只要應(yīng)用程序想要與其他服務(wù)通信，就會(huì)通過(guò)服務(wù)代理Envoy進(jìn)行。由此可見(jiàn)，Envoy代理是數(shù)據(jù)平面和整個(gè)服務(wù)網(wǎng)格架構(gòu)中的關(guān)鍵組成部分。

Envoy代理

Envoy最初是由Lyft開(kāi)發(fā)的，用于解決構(gòu)建分布式系統(tǒng)時(shí)出現(xiàn)的一些復(fù)雜的網(wǎng)絡(luò)問(wèn)題。它于2016年9月作為開(kāi)源項(xiàng)目提供，一年后加入了云原生計(jì)算基金會(huì)（CNCF）。Envoy是用C++語(yǔ)言實(shí)現(xiàn)的，具有很高的性能，更重要的是，它在高負(fù)載運(yùn)行時(shí)也非常穩(wěn)定和可靠。網(wǎng)絡(luò)對(duì)應(yīng)用程序來(lái)說(shuō)應(yīng)該是透明的，當(dāng)網(wǎng)絡(luò)和應(yīng)用程序出現(xiàn)問(wèn)題時(shí)，應(yīng)該很容易確定問(wèn)題的根源。正是基于這樣的一種設(shè)計(jì)理念，將Envoy設(shè)計(jì)為一個(gè)面向服務(wù)架構(gòu)的七層代理和通信總線。

為了更好地理解Envoy，我們需要先搞清楚相關(guān)的幾個(gè)基本術(shù)語(yǔ)：

• 進(jìn)程外（Out of Process）架構(gòu)：Envoy是一個(gè)獨(dú)立進(jìn)程，Envoy之間形成一個(gè)透明的通信網(wǎng)格，每個(gè)應(yīng)用程序發(fā)送消息到本地主機(jī)或從本地主機(jī)接收消息，但無(wú)需關(guān)心網(wǎng)絡(luò)拓?fù)洹?/p>

• 單進(jìn)程多線程模型：Envoy使用了單進(jìn)程多線程的架構(gòu)模型。一個(gè)主線程管理各種瑣碎的任務(wù)，而一些工作子線程則負(fù)責(zé)執(zhí)行監(jiān)聽(tīng)、過(guò)濾和轉(zhuǎn)發(fā)功能。

• 下游（Downstream）：連接到Envoy并發(fā)送請(qǐng)求、接收響應(yīng)的主機(jī)叫下游主機(jī)，也就是說(shuō)下游主機(jī)代表的是發(fā)送請(qǐng)求的主機(jī)。

• 上游（Upstream）：與下游相對(duì)，接收請(qǐng)求的主機(jī)叫上游主機(jī)。

• 監(jiān)聽(tīng)器（Listener）：監(jiān)聽(tīng)器是命名網(wǎng)絡(luò)地址，包括端口、unix domain socket等，可以被下游主機(jī)連接。Envoy暴露一個(gè)或者多個(gè)監(jiān)聽(tīng)器給下游主機(jī)連接。每個(gè)監(jiān)聽(tīng)器都獨(dú)立配置一些網(wǎng)絡(luò)級(jí)別（即三層或四層）的過(guò)濾器。當(dāng)監(jiān)聽(tīng)器接收到新連接時(shí)，配置好的本地過(guò)濾器將被實(shí)例化，并開(kāi)始處理后續(xù)事件。一般來(lái)說(shuō)監(jiān)聽(tīng)器架構(gòu)用于執(zhí)行絕大多數(shù)不同的代理任務(wù)，例如限速、TLS客戶端認(rèn)證、HTTP連接管理、MongoDB sniff?ing、原始TCP代理等。

• 集群（Cluster）：集群是指Envoy連接的一組邏輯相同的上游主機(jī)。

• xDS協(xié)議：在Envoy中xDS協(xié)議代表的是多個(gè)發(fā)現(xiàn)服務(wù)協(xié)議，包括集群發(fā)現(xiàn)服務(wù)（CDS，Cluster Discovery Service）、監(jiān)聽(tīng)器發(fā)現(xiàn)服務(wù)（LDS，Listener Discovery Service）、路由發(fā)現(xiàn)服務(wù)（RDS，Route Discovery Service）、端點(diǎn)發(fā)現(xiàn)服務(wù)（EDS，Endpoint Discovery Service），以及密鑰發(fā)現(xiàn)服務(wù)（SDS，Secret Discovery Service）。

Envoy代理

Envoy代理有許多功能可用于服務(wù)間通信，例如，暴露一個(gè)或者多個(gè)監(jiān)聽(tīng)器給下游主機(jī)連接，通過(guò)端口暴露給外部的應(yīng)用程序；通過(guò)定義路由規(guī)則處理監(jiān)聽(tīng)器中傳輸?shù)牧髁?#xff0c;并將該流量定向到目標(biāo)集群，等等。后續(xù)章節(jié)會(huì)進(jìn)一步分析這幾個(gè)發(fā)現(xiàn)服務(wù)在Istio中的角色和作用。

在了解了Envoy的術(shù)語(yǔ)之后，你可能想盡快知道Envoy到底起到了什么作用？

首先，Envoy是一種代理，在網(wǎng)絡(luò)體系架構(gòu)中扮演著中介的角色，可以為網(wǎng)絡(luò)中的流量管理添加額外的功能，包括提供安全性、隱私保護(hù)或策略等。在服務(wù)間調(diào)用的場(chǎng)景中，代理可以為客戶端隱藏服務(wù)后端的拓?fù)浼?xì)節(jié)，簡(jiǎn)化交互的復(fù)雜性，并保護(hù)后端服務(wù)不會(huì)過(guò)載。例如，后端服務(wù)實(shí)際上是運(yùn)行的一組相同實(shí)例，每個(gè)實(shí)例能夠處理一定量的負(fù)載。

其次，Envoy中的集群（Cluster）本質(zhì)上是指Envoy連接到的邏輯上相同的一組上游主機(jī)。那么客戶端如何知道在與后端服務(wù)交互時(shí)要使用哪個(gè)實(shí)例或IP地址？Envoy作為代理起到了路由選擇的作用，通過(guò)服務(wù)發(fā)現(xiàn)（SDS，Service Discovery Service），Envoy代理發(fā)現(xiàn)集群中的所有成員，然后通過(guò)主動(dòng)健康檢查來(lái)確定集群成員的健康狀態(tài)，并根據(jù)健康狀態(tài)，通過(guò)負(fù)載均衡策略決定將請(qǐng)求路由到哪個(gè)集群成員。而在Envoy代理處理跨服務(wù)實(shí)例的負(fù)載均衡過(guò)程中，客戶端不需要知道實(shí)際部署的任何細(xì)節(jié)。

Envoy的啟動(dòng)配置

Envoy目前提供了兩個(gè)版本的API，即v1和v2，從Envoy 1.5.0起就有v2 API了，為了能夠讓用戶順利地向v2版本API遷移，Envoy啟動(dòng)的時(shí)候設(shè)置了一個(gè)參數(shù)--v2-conf?ig-only。通過(guò)這個(gè)參數(shù)，可以明確指定Envoy使用v2 API的協(xié)議。幸運(yùn)的是，v2 API是v1的一個(gè)超集，兼容v1的API。在當(dāng)前的Istio 1.0之后的版本中，明確指定了其支持v2的API。通過(guò)查看使用Envoy作為Sidecar代理的容器啟動(dòng)命令，可以看到如下類(lèi)似的啟動(dòng)參數(shù)，其中指定了參數(shù)--v2-conf?ig-only：

$ /usr/local/bin/envoy -c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster ratings --service-node sidecar~172.33.14.2~ratings-v1-8558d4458d-ld8x9.default~default.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warn --v2-config-only

其中，參數(shù)-c表示的是基于版本v2的引導(dǎo)配置文件的路徑，格式為JSON，也支持其他格式，如YAML、Proto3等。它會(huì)首先作為版本v2的引導(dǎo)配置文件進(jìn)行解析，若解析失敗，會(huì)根據(jù)[--v2-conf?ig-only]選項(xiàng)決定是否作為版本v1的JSON配置文件進(jìn)行解析。其他參數(shù)解釋如下，以便讀者及時(shí)理解Envoy代理啟動(dòng)時(shí)的配置信息：

• restart-epoch表示熱重啟周期，對(duì)于第一次啟動(dòng)默認(rèn)為0，每次熱重啟后都應(yīng)該增加它。

• service-cluster定義Envoy運(yùn)行的本地服務(wù)集群名稱(chēng)。

• service-node定義Envoy運(yùn)行的本地服務(wù)節(jié)點(diǎn)名稱(chēng)。

• drain-time-s表示熱重啟期間Envoy將耗盡連接的時(shí)間（秒），默認(rèn)為600秒（10分鐘）。通常耗盡時(shí)間應(yīng)小于通過(guò)--parent-shutdown-time-s選項(xiàng)設(shè)置的父進(jìn)程關(guān)閉時(shí)間。

• parent-shutdown-time-s表示Envoy在熱重啟時(shí)關(guān)閉父進(jìn)程之前等待的時(shí)間（秒）。

• max-obj-name-len描述的是集群cluster、路由配置route_conf?ig以及監(jiān)聽(tīng)器listener中名稱(chēng)字段的最大長(zhǎng)度，以字節(jié)為單位。此選項(xiàng)通常用于自動(dòng)生成集群名稱(chēng)的場(chǎng)景，通常會(huì)超過(guò)60個(gè)字符的內(nèi)部限制。默認(rèn)為60。

Envoy的啟動(dòng)配置文件分為兩種方式：靜態(tài)配置和動(dòng)態(tài)配置。具體表現(xiàn)為：

• 靜態(tài)配置是將所有信息都放在配置文件中，啟動(dòng)的時(shí)候直接加載。

• 動(dòng)態(tài)配置需要提供一個(gè)Envoy的服務(wù)端，用于動(dòng)態(tài)生成Envoy需要的服務(wù)發(fā)現(xiàn)接口，也就是通常說(shuō)的xDS，通過(guò)發(fā)現(xiàn)服務(wù)來(lái)動(dòng)態(tài)調(diào)整配置信息，Istio實(shí)現(xiàn)了v2的xDS API。

Envoy靜態(tài)與動(dòng)態(tài)配置

Envoy是由JSON或YAML格式的配置文件驅(qū)動(dòng)的智能代理，對(duì)于已經(jīng)熟悉Envoy或Envoy配置的用戶來(lái)說(shuō)，相信應(yīng)該已經(jīng)知道了Envoy的配置也有不同的版本。初始版本v1是Envoy啟動(dòng)時(shí)配置Envoy的原始方式。此版本已被棄用，以支持Envoy配置的v2版本。Envoy的參考文檔（https://www.envoyproxy.io/docs）還提供了明確區(qū)分v1和v2的文檔。本書(shū)中將只關(guān)注v2配置，因?yàn)樗亲钚碌陌姹?#xff0c;也是Istio使用的版本。

Envoy版本v2的配置API建立在gRPC之上，v2 API的一個(gè)重要特性是可以在調(diào)用API時(shí)利用流功能來(lái)減少Envoy代理匯聚配置所需的時(shí)間。實(shí)際上，這也消除了輪詢API的弊端，允許服務(wù)器將更新推送到Envoy代理，而不是定期輪詢代理。

Envoy的架構(gòu)使得使用不同類(lèi)型的配置管理方法成為可能。部署中采用的方法將取決于實(shí)現(xiàn)者的需求。簡(jiǎn)單部署可以通過(guò)全靜態(tài)配置來(lái)實(shí)現(xiàn)，更復(fù)雜的部署可以遞增地添加更復(fù)雜的動(dòng)態(tài)配置。主要分為以下幾種情況：

• 全靜態(tài)：在全靜態(tài)配置中，實(shí)現(xiàn)者提供一組監(jiān)聽(tīng)器和過(guò)濾器鏈、集群和可選的HTTP路由配置。動(dòng)態(tài)主機(jī)發(fā)現(xiàn)僅能通過(guò)基于DNS的服務(wù)發(fā)現(xiàn)。配置重載必須通過(guò)內(nèi)置的熱重啟機(jī)制進(jìn)行。

• 僅SDS/EDS：在靜態(tài)配置之上，Envoy可以通過(guò)該機(jī)制發(fā)現(xiàn)上游集群中的成員。

• SDS/EDS和CDS：Envoy可以通過(guò)該機(jī)制發(fā)現(xiàn)使用的上游集群。

• SDS/EDS、CDS和RDS：RDS可以在運(yùn)行時(shí)發(fā)現(xiàn)用于HTTP連接管理器過(guò)濾器的整個(gè)路由配置。

• SDS/EDS、CDS、RDS和LDS：LDS可以在運(yùn)行時(shí)發(fā)現(xiàn)整個(gè)監(jiān)聽(tīng)器。這包括所有的過(guò)濾器堆棧，包括帶有內(nèi)嵌到RDS的應(yīng)用的HTTP過(guò)濾器。

靜態(tài)配置

我們可以使用Envoy的配置文件指定監(jiān)聽(tīng)器、路由規(guī)則和集群。如下示例提供了一個(gè)非常簡(jiǎn)單的Envoy配置：

static_resources:listeners:- name: httpbin-demoaddress:socket_address: { address: 0.0.0.0, port_value: 15001 }filter_chains:- filters:- name: envoy.http_connection_managerconfig:stat_prefix: egress_httproute_config:name: httpbin_local_routevirtual_hosts:- name: httpbin_local_servicedomains: ["*"]routes:- match: { prefix: "/" }route:auto_host_rewrite: truecluster: httpbin_servicehttp_filters:- name: envoy.routerclusters:- name: httpbin_serviceconnect_timeout: 5stype: LOGICAL_DNS# Comment out the following line to test on v6 networksdns_lookup_family: V4_ONLYlb_policy: ROUND_ROBINhosts: [{ socket_address: { address: httpbin, port_value: 8000 }}]

在這個(gè)簡(jiǎn)單的Envoy配置文件中，我們聲明了一個(gè)監(jiān)聽(tīng)器，它在端口15001上打開(kāi)一個(gè)套接字并為其附加一個(gè)過(guò)濾器鏈。過(guò)濾器http_connection_manager在Envoy配置中使用路由指令（在此示例中看到的簡(jiǎn)單路由指令是匹配所有虛擬主機(jī)的通配符），并將所有流量路由到httpbin_service集群。配置的最后一部分定義了httpbin_service集群的連接屬性。在此示例中，我們指定端點(diǎn)服務(wù)發(fā)現(xiàn)的類(lèi)型為L(zhǎng)OGICAL_DNS、與上游httpbin服務(wù)通信時(shí)的負(fù)載均衡算法為ROUND_ROBIN。

這是一個(gè)簡(jiǎn)單的配置文件，用于創(chuàng)建監(jiān)聽(tīng)器傳入的流量，并將所有流量路由到httpbin集群。它還指定要使用的負(fù)載均衡算法的設(shè)置以及要使用的連接超時(shí)配置。

你會(huì)注意到很多配置是明確指定的，例如指定了哪些監(jiān)聽(tīng)器，路由規(guī)則是什么，我們可以路由到哪些集群等。這是完全靜態(tài)配置文件的示例。

有關(guān)這些參數(shù)更多信息的解釋，請(qǐng)參閱Envoy的文檔（http://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/service_discovery#logical-dns）。

在前面的部分中，我們指出Envoy能夠動(dòng)態(tài)配置其各種設(shè)置。下面將介紹Envoy的動(dòng)態(tài)配置以及Envoy如何使用xDS API進(jìn)行動(dòng)態(tài)配置。

動(dòng)態(tài)配置

Envoy可以利用一組API進(jìn)行配置更新，而無(wú)需任何停機(jī)或重啟。Envoy只需要一個(gè)簡(jiǎn)單的引導(dǎo)配置文件，該配置文件將配置指向正確的發(fā)現(xiàn)服務(wù)API，其余動(dòng)態(tài)配置。Envoy進(jìn)行動(dòng)態(tài)配置的API通常統(tǒng)稱(chēng)為xDS服務(wù)，具體包括如下：

• 監(jiān)聽(tīng)器發(fā)現(xiàn)服務(wù)（LDS）：一種允許Envoy查詢整個(gè)監(jiān)聽(tīng)器的機(jī)制，通過(guò)調(diào)用該API可以動(dòng)態(tài)添加、修改或刪除已知監(jiān)聽(tīng)器；每個(gè)監(jiān)聽(tīng)器都必須具有唯一的名稱(chēng)。如果未提供名稱(chēng)，Envoy將創(chuàng)建一個(gè)UUID。

• 路由發(fā)現(xiàn)服務(wù)（RDS）：Envoy動(dòng)態(tài)獲取路由配置的機(jī)制，路由配置包括HTTP標(biāo)頭修改、虛擬主機(jī)以及每個(gè)虛擬主機(jī)中包含的單個(gè)路由規(guī)則。每個(gè)HTTP連接管理器都可以通過(guò)API獨(dú)立地獲取自身的路由配置。RDS配置隸屬于監(jiān)聽(tīng)器發(fā)現(xiàn)服務(wù)LDS的一部分，是LDS的一個(gè)子集，用于指定何時(shí)應(yīng)使用靜態(tài)和動(dòng)態(tài)配置，以及指定使用哪個(gè)路由。

• 集群發(fā)現(xiàn)服務(wù)（CDS）：一個(gè)可選的API，Envoy將調(diào)用該API來(lái)動(dòng)態(tài)獲取集群管理成員。Envoy還將根據(jù)API響應(yīng)協(xié)調(diào)集群管理，根據(jù)需要添加、修改或刪除已知的集群。在Envoy配置中靜態(tài)定義的任何集群都不能通過(guò)CDS API進(jìn)行修改或刪除。

• 端點(diǎn)發(fā)現(xiàn)服務(wù)（EDS）：一種允許Envoy獲取集群成員的機(jī)制，基于gRPC或RESTJSON的API，它是CDS的一個(gè)子集；集群成員在Envoy術(shù)語(yǔ)中稱(chēng)為端點(diǎn)（Endpoint）。對(duì)于每個(gè)集群，Envoy從發(fā)現(xiàn)服務(wù)獲取端點(diǎn)。EDS是首選的服務(wù)發(fā)現(xiàn)機(jī)制。

• 密鑰發(fā)現(xiàn)服務(wù)（SDS）：用于分發(fā)證書(shū)的API；SDS最重要的好處是簡(jiǎn)化證書(shū)管理。如果沒(méi)有此功能，在Kubernetes部署中，必須將證書(shū)創(chuàng)建為密鑰并掛載到Envoy代理容器中。如果證書(shū)過(guò)期，則需要更新密鑰并且需要重新部署代理容器。使用密鑰發(fā)現(xiàn)服務(wù)SDS，那么SDS服務(wù)器會(huì)將證書(shū)推送到所有Envoy實(shí)例。如果證書(shū)過(guò)期，服務(wù)器只需將新證書(shū)推送到Envoy實(shí)例，Envoy將立即使用新證書(shū)而無(wú)需重新部署。

• 聚合發(fā)現(xiàn)服務(wù)（ADS）：上述其他API的所有更改的序列化流；你可以使用此單個(gè)API按順序獲取所有更改；ADS并不是一個(gè)實(shí)際意義上的xDS，它提供了一個(gè)匯聚的功能，在需要多個(gè)同步xDS訪問(wèn)的時(shí)候，ADS可以在一個(gè)流中完成。

配置可以使用上述服務(wù)中的一個(gè)或其中幾個(gè)的組合，不必全部使用它們。需要注意的一點(diǎn)是，Envoy的xDS API是建立在最終一致性的前提下，正確的配置最終會(huì)收斂。例如，Envoy最終可能會(huì)使用新路由獲取RDS的更新，該路由將流量路由到尚未在CDS中更新的集群。這意味著，路由可能會(huì)引入路由錯(cuò)誤，直到更新CDS。Envoy引入了聚合發(fā)現(xiàn)服務(wù)ADS來(lái)解決這種問(wèn)題，而Istio實(shí)現(xiàn)了聚合發(fā)現(xiàn)服務(wù)ADS，并使用ADS進(jìn)行代理配置的更改。

例如，Envoy代理要?jiǎng)討B(tài)發(fā)現(xiàn)監(jiān)聽(tīng)器，可以使用如下配置：

dynamic_resources:lds_config:api_config_source:api_type: GRPCgrpc_services:- envoy_grpc:cluster_name: xds_cluster clusters: - name: xds_clusterconnect_timeout: 0.25stype: STATIClb_policy: ROUND_ROBINhttp2_protocol_options: {}hosts: [{ socket_address: { address: 127.0.0.3, port_value: 5678 }}]

通過(guò)上面的配置，我們不需要在配置文件中顯式配置每個(gè)監(jiān)聽(tīng)器。我們告訴Envoy使用LDS API在運(yùn)行時(shí)發(fā)現(xiàn)正確的監(jiān)聽(tīng)器配置值。但是，我們需要明確配置一個(gè)集群，這個(gè)集群就是LDS API所在的位置，也就是該示例中定義的集群xds_cluster。

在靜態(tài)配置的基礎(chǔ)上，比較直觀地表示出各個(gè)發(fā)現(xiàn)服務(wù)所提供的信息。

xDS服務(wù)信息

在靜態(tài)配置的基礎(chǔ)上，比較直觀地表示出各個(gè)發(fā)現(xiàn)服務(wù)所提供的信息。

福利時(shí)間

本文摘自于《Istio服務(wù)網(wǎng)格技術(shù)解析與實(shí)踐》，該書(shū)由阿里云高級(jí)技術(shù)專(zhuān)家王夕寧撰寫(xiě)，詳細(xì)介紹Istio的基本原理與開(kāi)發(fā)實(shí)戰(zhàn)，包含大量精選案例和參考代碼可以下載，可快速入門(mén)Istio開(kāi)發(fā)，適合所有對(duì)微服務(wù)和云原生感興趣的讀者，推薦大家對(duì)本書(shū)進(jìn)行深入的閱讀。本次聯(lián)合機(jī)械工業(yè)出版社華章公司為大家?guī)?lái)10本書(shū)作為福利。在文末留言中寫(xiě)下對(duì)Istio的認(rèn)識(shí)，截止4月21日12點(diǎn)前，評(píng)論點(diǎn)贊數(shù)前10名的讀者將獲以下任意圖書(shū)1本。沒(méi)中獎(jiǎng)的讀者也可以點(diǎn)擊下面鏈接購(gòu)買(mǎi)，目前京東有活動(dòng)，滿100減50。

基于Kubernetes的DevOps實(shí)戰(zhàn)培訓(xùn)

基于Kubernetes的DevOps實(shí)戰(zhàn)培訓(xùn)將于2020年5月15日在上海開(kāi)課，3天時(shí)間帶你系統(tǒng)掌握Kubernetes，學(xué)習(xí)效果不好可以繼續(xù)學(xué)習(xí)。本次培訓(xùn)包括：容器特性、鏡像、網(wǎng)絡(luò)；Kubernetes架構(gòu)、核心組件、基本功能；Kubernetes設(shè)計(jì)理念、架構(gòu)設(shè)計(jì)、基本功能、常用對(duì)象、設(shè)計(jì)原則；Kubernetes的數(shù)據(jù)庫(kù)、運(yùn)行時(shí)、網(wǎng)絡(luò)、插件已經(jīng)落地經(jīng)驗(yàn)；微服務(wù)架構(gòu)、組件、監(jiān)控方案等，點(diǎn)擊下方圖片或者閱讀原文鏈接查看詳情。

總結(jié)

以上是生活随笔為你收集整理的Istio架构剖析 | 文末有福利的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。