1

　 Istio 技術架構剖析

　2 目 錄 1．

　Istio 架構 ................................................................................................................................... 4

　2．

　剖析 Istio 控制平面 .................................................................................................................. 6

　3．

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

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

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

　4 1． Istio 架構

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

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

　5 一方面，我們在 Envoy 中看到，可以使用靜態(tài)配置文件或使用一組發(fā)現(xiàn)服務來配置一組服務代理，以便在運行時發(fā)現(xiàn)監(jiān)聽器、端點和集群。Istio 在 Pilot 中實現(xiàn)了這些 Envoy 代理的 xDS API。

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

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

　6

　2． 剖析 Istio 控制平面

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

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

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

　Pilot 將平臺特定的服務發(fā)現(xiàn)機制抽象化并將其合成為標準格式，符合數(shù)據(jù)平面 API 的任何Sidecar 都可以使用這種標準格式。這種松散耦合使得 Istio 能夠在多種環(huán)境下運行（例如

　7 Kubernetes、Consul、Nomad），同時可保持用于流量管理的操作界面相同。

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

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

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

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

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

　8

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

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

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

　Galley

　9 Galley 用于驗證用戶編寫的 Istio API 配置。隨著時間的推移，Galley 將接管 Istio 獲取配置、處理和分配組件的頂級責任。它負責將其他的 Istio 組件與從底層平臺（例如 Kubernetes）獲取用戶配置的細節(jié)中隔離開來。

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

　Istio 的架構設計中有幾個關鍵目標，這些目標對于系統(tǒng)應對大規(guī)模流量和高性能的服務處理至關重要。

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

　? 可擴展性：隨著運維人員和開發(fā)人員越來越依賴 Istio 提供的功能，系統(tǒng)必然和他們的需求一起成長。在我們繼續(xù)添加新功能的同時，最需要的是能夠擴展策略系統(tǒng)，集成其他策略和控制來源，并將網(wǎng)格行為信號傳播到其他系統(tǒng)進行分析。策略運行

　10 時支持標準擴展機制以便插入到其他服務中。此外，它允許擴展詞匯表，以允許基于網(wǎng)格生成的新信號來強制執(zhí)行策略。

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

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

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

　當介紹服務網(wǎng)格的概念時，提到了服務代理的概念以及如何使用代理構建一個服務網(wǎng)格，以調節(jié)和控制微服務之間的所有網(wǎng)絡通信。Istio 使用 Envoy 代理作為默認的開箱即用服務代理，這些 Envoy 代理與參與服務網(wǎng)格的所有應用程序實例一起運行，但不在同一個容器進程中，形成了服務網(wǎng)格的數(shù)據(jù)平面。只要應用程序想要與其他服務通信，就會通過服務代理 Envoy 進行。由此可見，Envoy 代理是數(shù)據(jù)平面和整個服務網(wǎng)格架構中的關鍵組成部分。

　Envoy 代理

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

　為了更好地理解 Envoy，我們需要先搞清楚相關的幾個基本術語：

　? 進程外（Out of Process）架構：Envoy 是一個獨立進程，Envoy 之間形成一個透明的通信網(wǎng)格，每個應用程序發(fā)送消息到本地主機或從本地主機接收消息，但無需關心網(wǎng)絡拓撲。

　? 單進程多線程模型：Envoy 使用了單進程多線程的架構模型。一個主線程管理各種瑣碎的任務，而一些工作子線程則負責執(zhí)行監(jiān)聽、過濾和轉發(fā)功能。

　? 下游（Downstream）：連接到 Envoy 并發(fā)送請求、接收響應的主機叫下游主機，也就是說下游主機代表的是發(fā)送請求的主機。

　? 上游（Upstream）：與下游相對，接收請求的主機叫上游主機。

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

　? 集群（Cluster）：集群是指 Envoy 連接的一組邏輯相同的上游主機。

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

　 Envoy 代理 Envoy 代理有許多功能可用于服務間通信，例如，暴露一個或者多個監(jiān)聽器給下游主機連接，通過端口暴露給外部的應用程序；通過定義路由規(guī)則處理監(jiān)聽器中傳輸?shù)牧髁浚⒃摿髁慷ㄏ虻侥繕思海鹊取：罄m(xù)章節(jié)會進一步分析這幾個發(fā)現(xiàn)服務在 Istio 中的角色和作用。

　在了解了 Envoy 的術語之后，你可能想盡快知道 Envoy 到底起到了什么作用？ 首先，Envoy 是一種代理，在網(wǎng)絡體系架構中扮演著中介的角色，可以為網(wǎng)絡中的流量管理添加額外的功能，包括提供安全性、隱私保護或策略等。在服務間調用的場景中，代理可以為客

　13 戶端隱藏服務后端的拓撲細節(jié)，簡化交互的復雜性，并保護后端服務不會過載。例如，后端服務實際上是運行的一組相同實例，每個實例能夠處理一定量的負載。

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

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

　1. $ /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

　14

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

　? restart-epoch 表示熱重啟周期，對于第一次啟動默認為 0，每次熱重啟后都應該增加它。

　? service-cluster 定義 Envoy 運行的本地服務集群名稱。

　? service-node 定義 Envoy 運行的本地服務節(jié)點名稱。

　? drain-time-s 表示熱重啟期間 Envoy 將耗盡連接的時間（秒），默認為 600 秒（10分鐘）。通常耗盡時間應小于通過--parent-shutdown-time-s 選項設置的父進程關閉時間。

　? parent-shutdown-time-s 表示 Envoy 在熱重啟時關閉父進程之前等待的時間（秒）。

　? max-obj-name-len 描述的是集群 cluster、路由配置 route_conf?ig 以及監(jiān)聽器listener 中名稱字段的最大長度，以字節(jié)為單位。此選項通常用于自動生成集群名稱的場景，通常會超過 60 個字符的內部限制。默認為 60。

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

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

　? 動態(tài)配置需要提供一個 Envoy 的服務端，用于動態(tài)生成 Envoy 需要的服務發(fā)現(xiàn)接口，也就是通常說的 xDS，通過發(fā)現(xiàn)服務來動態(tài)調整配置信息，Istio 實現(xiàn)了 v2 的xDS API。

　Envoy 靜態(tài)與動態(tài)配置 Envoy 是由 JSON 或 YAML 格式的配置文件驅動的智能代理，對于已經(jīng)熟悉 Envoy 或 Envoy配置的用戶來說，相信應該已經(jīng)知道了 Envoy 的配置也有不同的版本。初始版本 v1 是 Envoy啟動時配置 Envoy 的原始方式。此版本已被棄用，以支持 Envoy 配置的 v2 版本。Envoy 的參考文檔（https://www.envoyproxy.io/docs）還提供了明確區(qū)分 v1 和 v2 的文檔。本書中將只關注 v2 配置，因為它是最新的版本，也是 Istio 使用的版本。

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

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

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

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

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

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

　? SDS/EDS、CDS、RDS 和 LDS：LDS 可以在運行時發(fā)現(xiàn)整個監(jiān)聽器。這包括所有的過濾器堆棧，包括帶有內嵌到 RDS 的應用的 HTTP 過濾器。

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

　1. static_resources: 2.

　 listeners: 3.

　 - name: httpbin-demo 4.

　 address: 5.

　 socket_address: { address: 0.0.0.0, port_value: 15001 } 6.

　 filter_chains: 7.

　 - filters: 8.

　 - name: envoy.http_connection_manager 9.

　 config: 10.

　 stat_prefix: egress_http

　17 11.

　 route_config: 12.

　 name: httpbin_local_route 13.

　 virtual_hosts: 14.

　 - name: httpbin_local_service 15.

　 domains: ["*"] 16.

　 routes: 17.

　 - match: { prefix: "/" } 18.

　 route: 19.

　 auto_host_rewrite: true 20.

　 cluster: httpbin_service 21.

　 http_filters: 22.

　 - name: envoy.router 23.

　 clusters: 24.

　 - name: httpbin_service 25.

　 connect_timeout: 5s 26.

　 type: LOGICAL_DNS 27.

　 # Comment out the following line to test on v6 networks 28.

　 dns_lookup_family: V4_ONLY 29.

　 lb_policy: ROUND_ROBIN 30.

　 hosts: [{ socket_address: { address: httpbin, port_value: 8000 }}]

　在這個簡單的 Envoy 配置文件中，我們聲明了一個監(jiān)聽器，它在端口 15001 上打開一個套接

　18 字并為其附加一個過濾器鏈。過濾器 http_connection_manager 在 Envoy 配置中使用路由指令（在此示例中看到的簡單路由指令是匹配所有虛擬主機的通配符），并將所有流量路由到httpbin_service 集群。配置的最后一部分定義了 httpbin_service 集群的連接屬性。在此示例中，我們指定端點服務發(fā)現(xiàn)的類型為 LOGICAL_DNS、與上游 httpbin 服務通信時的負載均衡算法為 ROUND_ROBIN。

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

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

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

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

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

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

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

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

　? 端點發(fā)現(xiàn)服務（EDS）：一種允許 Envoy 獲取集群成員的機制，基于 gRPC 或RESTJSON 的 API，它是 CDS 的一個子集；集群成員在 Envoy 術語中稱為端點（Endpoint）。對于每個集群，Envoy 從發(fā)現(xiàn)服務獲取端點。EDS 是首選的服務發(fā)現(xiàn)機制。

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

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

　20

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

　例如，Envoy 代理要動態(tài)發(fā)現(xiàn)監(jiān)聽器，可以使用如下配置：

　1. dynamic_resources: 2.

　 lds_config: 3.

　 api_config_source: 4.

　 api_type: GRPC 5.

　 grpc_services: 6.

　 - envoy_grpc: 7.

　 cluster_name: xds_cluster 8. clusters: 9. - name: xds_cluster 10.

　 connect_timeout: 0.25s 11.

　 type: STATIC 12.

　 lb_policy: ROUND_ROBIN 13.

　 http2_protocol_options: {} 14.

　 hosts: [{ socket_address: { address: 127.0.0.3, port_value: 5678 }}]

　21

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

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

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

推薦訪問： 剖析 架構 技術