xDS 配置 API 概述
Envoy 的架構設計允許各種不同的配置管理方法。部署中所採用的方法將取決於實施者的需求。簡單的部署可以使用完全靜態的配置。更複雜的部署可以逐步增加更複雜的動態配置，缺點是實施者必須提供一個或多個外部基於 gRPC/REST 的配置提供者 API。這些 API 統稱為 “xDS”（* 探索服務）。本文檔概述了目前可用的選項。
完全靜態
在完全靜態的配置中，實施者提供一組 監聽器（和 篩選器鏈）、叢集等等。動態主機探索僅能透過基於 DNS 的 服務探索 實現。配置重新載入必須透過內建的 熱重啟 機制進行。
雖然很簡單，但可以使用靜態配置和優雅的熱重啟來建立相當複雜的部署。
EDS
端點探索服務 (EDS) API 提供了一種更進階的機制，Envoy 可以透過該機制探索上游叢集的成員。在靜態配置之上分層，EDS 允許 Envoy 部署規避 DNS 的限制（回應中的最大記錄數等等），並使用於負載平衡和路由的更多資訊（例如， Canary 狀態、區域等等）。
CDS
叢集探索服務 (CDS) API 分層提供了一種機制，Envoy 可以透過該機制探索路由期間使用的上游叢集。Envoy 將根據 API 的指定，優雅地新增、更新和移除叢集。此 API 允許實施者建立一個拓撲，其中 Envoy 不需要在初始配置時知道所有上游叢集。通常，在執行 HTTP 路由以及 CDS（但沒有路由探索服務）時，實施者會利用路由器將請求轉發到 HTTP 請求標頭 中指定的叢集的能力。
雖然可以使用 CDS 而不使用 EDS 來指定完全靜態的叢集，但我們建議仍然將 EDS API 用於透過 CDS 指定的叢集。在內部，當更新叢集定義時，該操作是優雅的。但是，所有現有的連接池都將被耗盡並重新連接。EDS 沒有這個限制。當透過 EDS 新增和移除主機時，叢集中的現有主機不受影響。
RDS
路由探索服務 (RDS) API 分層提供了一種機制，Envoy 可以透過該機制在執行階段探索 HTTP 連接管理器篩選器的整個路由配置。路由配置將被優雅地替換，而不會影響現有的請求。此 API 與 EDS 和 CDS 一起使用時，允許實施者建立複雜的路由拓撲（流量轉移、藍/綠部署等等）。
VHDS
虛擬主機探索服務 允許根據需要，從路由配置本身分別請求屬於路由配置的虛擬主機。此 API 通常用於路由配置中具有大量虛擬主機的部署中。
SRDS
範圍路由探索服務 (SRDS) API 允許將路由表分成多個部分。此 API 通常用於具有大量路由表的 HTTP 路由部署中，其中簡單的線性搜尋是不可行的。
LDS
監聽器探索服務 (LDS) API 分層提供了一種機制，Envoy 可以透過該機制在執行階段探索整個監聽器。這包括所有篩選器堆疊，包括使用內嵌引用 RDS 的 HTTP 篩選器。將 LDS 加入組合中，幾乎可以動態配置 Envoy 的每個方面。熱重啟僅應在非常罕見的配置變更（管理、追蹤驅動程式等等）、憑證輪換或二進位更新時才需要。
SDS
密碼探索服務 (SDS) API 分層提供了一種機制，Envoy 可以透過該機制探索其監聽器的密碼編譯機密（憑證加上私密金鑰、TLS 會話票證金鑰），以及對等憑證驗證邏輯（受信任的根憑證、撤銷等等）的配置。
RTDS
執行階段探索服務 (RTDS) API 允許透過 xDS API 擷取 執行階段 層。這可能優於檔案系統層，或者透過檔案系統層來擴充。
ECDS
擴展配置探索服務 (ECDS) API 允許獨立於監聽器提供擴展配置（例如，HTTP 篩選器配置）。當建構更適合從主要控制平面分割的系統（例如，WAF、錯誤測試等等）時，這非常有用。
彙總 xDS (“ADS”)
EDS、CDS 等等是各自獨立的服務，具有不同的 REST/gRPC 服務名稱，例如 StreamListeners、StreamSecrets。對於希望強制執行不同類型資源到達 Envoy 的順序的使用者來說，有一個彙總的 xDS，這是一個單一的 gRPC 服務，在單一 gRPC 資料流中攜帶所有資源類型。（ADS 僅受 gRPC 支援）。有關 ADS 的更多詳細資訊。
Delta gRPC xDS
標準 xDS 是「世界狀態」：每個更新都必須包含每個資源，更新中沒有的資源意味著該資源已消失。Envoy 支援 xDS 的「delta」變體（包括 ADS），其中更新僅包含已新增/變更/移除的資源。Delta xDS 是一種新的協定，其請求/回應 API 與 SotW 不同。有關 delta 的更多詳細資訊。
xDS TTL
某些 xDS 更新可能需要設定 TTL，以防止控制平面無法使用，請在此處閱讀更多資訊：這裡。