package envoy.service.discovery.v2
Get desktop application:
View/edit binary Protocol Buffers messages
See https://github.com/envoyproxy/envoy-api#apis for a description of the role of ADS and how it is intended to be used by a management server. ADS requests have the same structure as their singleton xDS counterparts, but can multiplex many resource types on a single stream. The type_url in the DiscoveryRequest/DiscoveryResponse provides sufficient information to recover the multiplexed singleton APIs at the Envoy instance and management server.
rpc StreamAggregatedResources (stream , stream )
ads.proto:30This is a gRPC-only API.
rpc DeltaAggregatedResources (stream , stream )
ads.proto:34
HDS is Health Discovery Service. It compliments Envoy’s health checking service by designating this Envoy to be a healthchecker for a subset of hosts in the cluster. The status of these health checks will be reported to the management server, where it can be aggregated etc and redistributed back to Envoy through EDS.
rpc StreamHealthCheck (stream , stream )
hds.proto:641. Envoy starts up and if its can_healthcheck option in the static bootstrap config is enabled, sends HealthCheckRequest to the management server. It supplies its capabilities (which protocol it can health check with, what zone it resides in, etc.). 2. In response to (1), the management server designates this Envoy as a healthchecker to health check a subset of all upstream hosts for a given cluster (for example upstream Host 1 and Host 2). It streams HealthCheckSpecifier messages with cluster related configuration for all clusters this Envoy is designated to health check. Subsequent HealthCheckSpecifier message will be sent on changes to: a. Endpoints to health checks b. Per cluster configuration change 3. Envoy creates a health probe based on the HealthCheck config and sends it to endpoint(ip:port) of Host 1 and 2. Based on the HealthCheck configuration Envoy waits upon the arrival of the probe response and looks at the content of the response to decide whether the endpoint is healthy or not. If a response hasn't been received within the timeout interval, the endpoint health status is considered TIMEOUT. 4. Envoy reports results back in an EndpointHealthResponse message. Envoy streams responses as often as the interval configured by the management server in HealthCheckSpecifier. 5. The management Server collects health statuses for all endpoints in the cluster (for all clusters) and uses this information to construct EndpointDiscoveryResponse messages. 6. Once Envoy has a list of upstream endpoints to send traffic to, it load balances traffic to them without additional health checking. It may use inline healthcheck (i.e. consider endpoint UNHEALTHY if connection failed to a particular endpoint to account for health status propagation delay between HDS and EDS). By default, can_healthcheck is true. If can_healthcheck is false, Cluster configuration may not contain HealthCheck message. TODO(htuch): How is can_healthcheck communicated to CDS to ensure the above invariant? TODO(htuch): Add @amb67's diagram.
rpc FetchHealthCheck (, )
hds.proto:71TODO(htuch): Unlike the gRPC version, there is no stream-based binding of request/response. Should we add an identifier to the HealthCheckSpecifier to bind with the response?
Discovery service for Runtime resources.
rpc StreamRuntime (stream , stream )
rtds.proto:29rpc DeltaRuntime (stream , stream )
rtds.proto:32rpc FetchRuntime (, )
rtds.proto:36
rpc DeltaSecrets (stream , stream )
sds.proto:25rpc StreamSecrets (stream , stream )
sds.proto:29rpc FetchSecrets (, )
sds.proto:32
message
ads.proto:41[#not-implemented-hide:] Not configuration. Workaround c++ protobuf issue with importing services: https://github.com/google/protobuf/issues/4221
(message has no fields)
message
hds.proto:79Defines supported protocols etc, so the management server can assign proper endpoints to healthcheck.
Used in:
repeated Capability.Protocol health_check_protocols = 1
Different Envoy instances may have different capabilities (e.g. Redis) and/or have ports enabled for different protocols.
Used in:
HTTP = 0
TCP = 1
REDIS = 2
message
hds.proto:125The cluster name and locality is provided to Envoy for the endpoints that it health checks to support statistics reporting, logging and debugging by the Envoy instance (outside of HDS). For maximum usefulness, it should match the same cluster structure as that provided by EDS.
Used in:
string cluster_name = 1
repeated health_checks = 2
repeated locality_endpoints = 3
message
hds.proto:97Used in:
optional endpoint = 1
api.v2.core.HealthStatus health_status = 2
message
hds.proto:103Used in:
repeated endpoints_health = 1
message
hds.proto:91Used in:
optional node = 1
optional capability = 2
message
hds.proto:107Used as request type in: HealthDiscoveryService.FetchHealthCheck, HealthDiscoveryService.StreamHealthCheck
oneof request_type
health_check_request = 1
endpoint_health_response = 2
message
hds.proto:133Used as response type in: HealthDiscoveryService.FetchHealthCheck, HealthDiscoveryService.StreamHealthCheck
repeated cluster_health_checks = 1
optional interval = 2
The default is 1 second.
message
hds.proto:115Used in:
optional locality = 1
repeated endpoints = 2
message
rtds.proto:44[#not-implemented-hide:] Not configuration. Workaround c++ protobuf issue with importing services: https://github.com/google/protobuf/issues/4221
(message has no fields)
message
rtds.proto:48RTDS resource type. This describes a layer in the runtime virtual filesystem.
string name = 1
Runtime resource name. This makes the Runtime a self-describing xDS resource.
optional layer = 2
message
sds.proto:40[#not-implemented-hide:] Not configuration. Workaround c++ protobuf issue with importing services: https://github.com/google/protobuf/issues/4221
(message has no fields)