xDS API 端点

xDS 管理服务器将根据需要实现以下端点，以提供 gRPC 和/或 REST 服务。 在流式 gRPC 和 REST-JSON 情况下，一个 DiscoveryRequest 被发送，并且一个 DiscoveryResponse 遵循 xDS 协议 被接收。

下面我们描述了 v3 传输 API 的端点。

gRPC 流式端点

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

有关服务定义，请参阅 cds.proto。 当

xds-api-cds-demo.yaml
12    api_config_source:
13      api_type: GRPC
14      grpc_services:
15      - envoy_grpc:
16          cluster_name: xds_cluster
17  lds_config:
18    api_config_source:
19      api_type: GRPC

设置在 dynamic_resources 的 Bootstrap 配置中时，Envoy 将此用作客户端。

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

有关服务定义，请参阅 eds.proto。 当

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

设置在 eds_cluster_config 字段的 Cluster 配置中时，Envoy 将此用作客户端。

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

有关服务定义，请参阅 lds.proto。 当

xds-api-lds-demo.yaml
20      grpc_services:
21      - envoy_grpc:
22          cluster_name: xds_cluster
23
24static_resources:
25  clusters:
26  - type: STRICT_DNS
27    typed_extension_protocol_options:

设置在 dynamic_resources 的 Bootstrap 配置中时，Envoy 将此用作客户端。

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

有关服务定义，请参阅 rds.proto。 当

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 配置中时，Envoy 将此用作客户端。

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

有关服务定义，请参阅 srds.proto。 当

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 配置中时，Envoy 将此用作客户端。

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

有关服务定义，请参阅 sds.proto。 当

oauth-sds-example.yaml
48                  token_secret:
49                    name: token
50                    sds_config:
51                      api_config_source:
52                        api_type: GRPC
53                        grpc_services:
54                        - envoy_grpc:
55                            cluster_name: sds_server_uds
56                  hmac_secret:
57                    name: hmac

设置在 SdsSecretConfig 消息中时，Envoy 将此用作客户端。 此消息在各种位置使用，例如 CommonTlsContext。

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

有关服务定义，请参阅 rtds.proto。 当

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

设置在 rtds_layer 字段中时，Envoy 将此用作客户端。

REST 端点

POST /v3/discovery:clusters

有关服务定义，请参阅 cds.proto。 当

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

设置在 dynamic_resources 的 Bootstrap 配置中时，Envoy 将此用作客户端。

POST /v3/discovery:endpoints

有关服务定义，请参阅 eds.proto。 当

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

设置在 eds_cluster_config 字段的 Cluster 配置中时，Envoy 将此用作客户端。

POST /v3/discovery:listeners

有关服务定义，请参阅 lds.proto。 当

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

设置在 dynamic_resources 的 Bootstrap 配置中时，Envoy 将此用作客户端。

POST /v3/discovery:routes

有关服务定义，请参阅 rds.proto。 当

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

设置在 rds 字段的 HttpConnectionManager 配置中时，Envoy 将此用作客户端。

注意

响应这些端点的管理服务器必须以一个 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。 当

xds-api-ads-demo.yaml
 6  ads_config:
 7    api_type: GRPC
 8    grpc_services:
 9    - envoy_grpc:
10        cluster_name: xds_cluster
11  cds_config:

设置在 dynamic_resources 的 Bootstrap 配置中时，Envoy 将此用作客户端。

设置时，任何 上面 的配置源都可以设置为使用 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），其中更新只包含添加/更改/删除的资源。增量 xDS 是一种仅限 gRPC 的协议。增量使用与 SotW 不同的请求/响应协议（DeltaDiscovery{Request,Response}）；请参见 discovery.proto。从概念上讲，增量应被视为一种新的 xDS 传输类型：有静态、文件系统、REST、gRPC-SotW，现在还有 gRPC-增量。（Envoy 的 gRPC-SotW/增量客户端实现恰好共享了它们的大部分代码，并且服务器端也可能存在类似的情况。然而，它们实际上是不兼容的协议。 增量 xDS 协议行为的规范在此处。）

要使用增量，只需将 ApiConfigSource 协议中的 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 协议中指定：对于增量 xDS，它直接在响应中指定，而对于 SotW xDS，服务器可能会将响应中列出的单个资源包装在 Resource 中以指定 TTL 值。

服务器可以通过针对同一版本发出另一个响应来刷新或修改 TTL。在这种情况下，不需要包含资源本身。