xDS API 端點

xDS 管理伺服器會根據 gRPC 和/或 REST 服務的需求實作以下端點。在串流 gRPC 和 REST-JSON 案例中，都會傳送 DiscoveryRequest，並依照 xDS 協定接收 DiscoveryResponse。

以下我們描述 v3 傳輸 API 的端點。

gRPC 串流端點

POST /envoy.service.cluster.v3.ClusterDiscoveryService/StreamClusters

請參閱 cds.proto 以取得服務定義。當 Envoy 作為用戶端且

xds-api-cds-demo.yaml

    api_config_source:
      api_type: GRPC
      grpc_services:
      - envoy_grpc:
          cluster_name: xds_cluster
  lds_config:
    api_config_source:
      api_type: GRPC

在 dynamic_resources 的 Bootstrap 組態中設定時，就會使用此端點。

POST /envoy.service.endpoint.v3.EndpointDiscoveryService/StreamEndpoints

請參閱 eds.proto 以取得服務定義。當 Envoy 作為用戶端且

eds_config:
  api_config_source:
    api_type: GRPC
    grpc_services:
    - envoy_grpc:
        cluster_name: some_xds_cluster

在 eds_cluster_config 的 Cluster 組態欄位中設定時，就會使用此端點。

POST /envoy.service.listener.v3.ListenerDiscoveryService/StreamListeners

請參閱 lds.proto 以取得服務定義。當 Envoy 作為用戶端且

xds-api-lds-demo.yaml

      grpc_services:
      - envoy_grpc:
          cluster_name: xds_cluster

static_resources:
  clusters:
  - type: STRICT_DNS
    typed_extension_protocol_options:

在 dynamic_resources 的 Bootstrap 組態中設定時，就會使用此端點。

POST /envoy.service.route.v3.RouteDiscoveryService/StreamRoutes

請參閱 rds.proto 以取得服務定義。當 Envoy 作為用戶端且

route_config_name: some_route_name
config_source:
  api_config_source:
    api_type: GRPC
    grpc_services:
    - envoy_grpc:
        cluster_name: some_xds_cluster

在 rds 的 HttpConnectionManager 組態欄位中設定時，就會使用此端點。

POST /envoy.service.route.v3.ScopedRoutesDiscoveryService/StreamScopedRoutes

請參閱 srds.proto 以取得服務定義。當 Envoy 作為用戶端且

name: some_scoped_route_name
scoped_rds:
  config_source:
    api_config_source:
      api_type: GRPC
      grpc_services:
      - envoy_grpc:
          cluster_name: some_xds_cluster

在 scoped_routes 的 HttpConnectionManager 組態欄位中設定時，就會使用此端點。

POST /envoy.service.secret.v3.SecretDiscoveryService/StreamSecrets

請參閱 sds.proto 以取得服務定義。當 Envoy 作為用戶端且

oauth-sds-example.yaml

                  token_secret:
                    name: token
                    sds_config:
                      api_config_source:
                        api_type: GRPC
                        grpc_services:
                        - envoy_grpc:
                            cluster_name: sds_server_uds
                  hmac_secret:
                    name: hmac

在 SdsSecretConfig 訊息內設定時，就會使用此端點。此訊息會在不同的地方使用，例如 CommonTlsContext。

POST /envoy.service.runtime.v3.RuntimeDiscoveryService/StreamRuntime

請參閱 rtds.proto 以取得服務定義。當 Envoy 作為用戶端且

name: some_runtime_layer_name
config_source:
  api_config_source:
    api_type: GRPC
    grpc_services:
    - envoy_grpc:
        cluster_name: some_xds_cluster

在 rtds_layer 欄位內設定時，就會使用此端點。

REST 端點

POST /v3/discovery:clusters

請參閱 cds.proto 以取得服務定義。當 Envoy 作為用戶端且

cds_config:
  api_config_source:
    api_type: REST
    cluster_names: [some_xds_cluster]

在 dynamic_resources 的 Bootstrap 組態中設定時，就會使用此端點。

POST /v3/discovery:endpoints

請參閱 eds.proto 以取得服務定義。當 Envoy 作為用戶端且

eds_config:
  api_config_source:
    api_type: REST
    cluster_names: [some_xds_cluster]

在 eds_cluster_config 的 Cluster 組態欄位中設定時，就會使用此端點。

POST /v3/discovery:listeners

請參閱 lds.proto 以取得服務定義。當 Envoy 作為用戶端且

lds_config:
  api_config_source:
    api_type: REST
    cluster_names: [some_xds_cluster]

在 dynamic_resources 的 Bootstrap 組態中設定時，就會使用此端點。

POST /v3/discovery:routes

請參閱 rds.proto 以取得服務定義。當 Envoy 作為用戶端且

route_config_name: some_route_name
config_source:
  api_config_source:
    api_type: REST
    cluster_names: [some_xds_cluster]

在 rds 的 HttpConnectionManager 組態欄位中設定時，就會使用此端點。

注意

回應這些端點的管理伺服器必須回應 DiscoveryResponse 以及 HTTP 狀態碼 200。此外，如果將要提供的組態沒有變更 (如 Envoy 用戶端提供的版本所指示)，則管理伺服器可以使用空白主體和 HTTP 狀態碼 304 回應。

聚合探索服務

雖然 Envoy 從根本上採用最終一致性模型，但 ADS 提供序列化 API 更新推送的機會，並確保單一管理伺服器對 Envoy 節點的 API 更新具有親和性。ADS 允許管理伺服器在單一雙向 gRPC 串流上傳遞一或多個 API 及其資源。如果沒有此功能，某些 API (例如 RDS 和 EDS) 可能需要管理多個串流和與不同管理伺服器的連線。

ADS 可藉由適當的序列化來允許組態的無損更新。例如，假設 *foo.com* 對應到叢集 *X*。我們希望變更路由表中的對應，以將 *foo.com* 指向叢集 *Y*。為了執行此操作，必須先傳遞包含叢集 *X* 和 *Y* 的 CDS/EDS 更新。

如果沒有 ADS，CDS/EDS/RDS 串流可能會指向不同的管理伺服器，或者當在相同的管理伺服器上時，會指向需要協調的不同 gRPC 串流/連線。EDS 資源請求可能會分散在兩個不同的串流上，一個用於 *X*，另一個用於 *Y*。ADS 允許將這些合併到單一串流到單一管理伺服器，避免需要分散式同步來正確排序更新。使用 ADS，管理伺服器會在單一串流上傳遞 CDS、EDS，然後傳遞 RDS 更新。

ADS 僅適用於 gRPC 串流 (而非 REST)，並在 xDS 文件中有更完整的描述。gRPC 端點為

POST /envoy.service.discovery.v3.AggregatedDiscoveryService/StreamAggregatedResources

請參閱 discovery.proto 以取得服務定義。當 Envoy 作為用戶端且

xds-api-ads-demo.yaml

  ads_config:
    api_type: GRPC
    grpc_services:
    - envoy_grpc:
        cluster_name: xds_cluster
  cds_config:

在 dynamic_resources 的 Bootstrap 組態中設定時，就會使用此端點。

設定此選項時，任何上述組態來源都可以設定為使用 ADS 通道。例如，LDS 組態可以從

lds_config:
  api_config_source:
    api_type: REST
    cluster_names: [some_xds_cluster]

變更為

lds_config: {ads: {}}

其效果是，LDS 串流將透過共用的 ADS 通道導向 *some_ads_cluster*。

Delta 端點

REST、檔案系統和原始 gRPC xDS 實作都會傳遞「世界狀態」更新：每個 CDS 更新必須包含每個叢集，如果更新中缺少叢集，則表示該叢集已消失。對於具有大量資源甚至少量變動的 Envoy 部署，這些世界狀態更新可能會很麻煩。

自 1.12.0 版本起，Envoy 支援 xDS（包含 ADS）的「差異」（delta）變體，其中更新僅包含新增/變更/移除的資源。差異 xDS 是一種 gRPC（僅限）協定。差異使用與 SotW 不同的請求/回應 protos (DeltaDiscovery{Request,Response})；請參閱 discovery.proto。從概念上講，差異應被視為一種新的 xDS 傳輸類型：有靜態、檔案系統、REST、gRPC-SotW，而現在多了 gRPC-delta。（Envoy 的 gRPC-SotW/delta 客戶端實作恰巧在兩者之間共享了大部分程式碼，並且在伺服器端也可能實現類似的機制。然而，它們實際上是不相容的協定。delta xDS 協定的行為規範在此。）

要使用差異，只需將您的 ApiConfigSource proto 的 api_type 欄位設定為 DELTA_GRPC 即可。這適用於 xDS 和 ADS；對於 ADS，它是 DynamicResources.ads_config 的 api_type 欄位，如上一節所述。

xDS TTL

使用 xDS 時，使用者可能會發現自己需要暫時更新某些 xDS 資源。為了安全地執行此操作，可以使用 xDS TTL 來確保在控制平面變得不可用並且無法恢復 xDS 變更時，Envoy 會在伺服器指定的 TTL 後移除資源。有關更多資訊，請參閱協定文件。

目前，當 TTL 過期時的行為是將資源移除（而不是恢復到先前的版本）。因此，此功能主要應用於那些資源不存在比臨時版本更為理想的用例，例如在使用 RTDS 來應用臨時運行時覆寫時。

TTL 在 Resource proto 上指定：對於差異 xDS，這是直接在回應中指定的，而對於 SotW xDS，伺服器可能會將回應中列出的個別資源包裝在 Resource 中，以便指定 TTL 值。

伺服器可以通過針對相同版本發出另一個回應來重新整理或修改 TTL。在這種情況下，資源本身不必包含在內。