Documentation
¶
Index ¶
- Constants
- Variables
- func RegisterHealthDiscoveryServiceServer(s grpc.ServiceRegistrar, srv HealthDiscoveryServiceServer)
- type HealthDiscoveryServiceClient
- type HealthDiscoveryServiceServer
- type HealthDiscoveryService_StreamHealthCheckClient
- type HealthDiscoveryService_StreamHealthCheckServer
- type UnimplementedHealthDiscoveryServiceServer
- type UnsafeHealthDiscoveryServiceServer
Constants ¶
const ( HealthDiscoveryService_StreamHealthCheck_FullMethodName = "/envoy.service.health.v3.HealthDiscoveryService/StreamHealthCheck" HealthDiscoveryService_FetchHealthCheck_FullMethodName = "/envoy.service.health.v3.HealthDiscoveryService/FetchHealthCheck" )
Variables ¶
var HealthDiscoveryService_ServiceDesc = grpc.ServiceDesc{ ServiceName: "envoy.service.health.v3.HealthDiscoveryService", HandlerType: (*HealthDiscoveryServiceServer)(nil), Methods: []grpc.MethodDesc{ { MethodName: "FetchHealthCheck", Handler: _HealthDiscoveryService_FetchHealthCheck_Handler, }, }, Streams: []grpc.StreamDesc{ { StreamName: "StreamHealthCheck", Handler: _HealthDiscoveryService_StreamHealthCheck_Handler, ServerStreams: true, ClientStreams: true, }, }, Metadata: "envoy/service/health/v3/hds.proto", }
HealthDiscoveryService_ServiceDesc is the grpc.ServiceDesc for HealthDiscoveryService service. It's only intended for direct use with grpc.RegisterService, and not to be introspected or modified (even as a copy)
Functions ¶
func RegisterHealthDiscoveryServiceServer ¶
func RegisterHealthDiscoveryServiceServer(s grpc.ServiceRegistrar, srv HealthDiscoveryServiceServer)
Types ¶
type HealthDiscoveryServiceClient ¶
type HealthDiscoveryServiceClient interface {
// 1. 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.
StreamHealthCheck(ctx context.Context, opts ...grpc.CallOption) (grpc.BidiStreamingClient[v3.HealthCheckRequestOrEndpointHealthResponse, v3.HealthCheckSpecifier], error)
// TODO(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?
FetchHealthCheck(ctx context.Context, in *v3.HealthCheckRequestOrEndpointHealthResponse, opts ...grpc.CallOption) (*v3.HealthCheckSpecifier, error)
}
HealthDiscoveryServiceClient is the client API for HealthDiscoveryService service.
For semantics around ctx use and closing/ending streaming RPCs, please refer to https://pkg.go.dev/google.golang.org/grpc/?tab=doc#ClientConn.NewStream.
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.
func NewHealthDiscoveryServiceClient ¶
func NewHealthDiscoveryServiceClient(cc grpc.ClientConnInterface) HealthDiscoveryServiceClient
type HealthDiscoveryServiceServer ¶
type HealthDiscoveryServiceServer interface {
// 1. 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.
StreamHealthCheck(grpc.BidiStreamingServer[v3.HealthCheckRequestOrEndpointHealthResponse, v3.HealthCheckSpecifier]) error
// TODO(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?
FetchHealthCheck(context.Context, *v3.HealthCheckRequestOrEndpointHealthResponse) (*v3.HealthCheckSpecifier, error)
}
HealthDiscoveryServiceServer is the server API for HealthDiscoveryService service. All implementations should embed UnimplementedHealthDiscoveryServiceServer for forward compatibility.
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.
type HealthDiscoveryService_StreamHealthCheckClient ¶
type HealthDiscoveryService_StreamHealthCheckClient = grpc.BidiStreamingClient[v3.HealthCheckRequestOrEndpointHealthResponse, v3.HealthCheckSpecifier]
This type alias is provided for backwards compatibility with existing code that references the prior non-generic stream type by name.
type HealthDiscoveryService_StreamHealthCheckServer ¶
type HealthDiscoveryService_StreamHealthCheckServer = grpc.BidiStreamingServer[v3.HealthCheckRequestOrEndpointHealthResponse, v3.HealthCheckSpecifier]
This type alias is provided for backwards compatibility with existing code that references the prior non-generic stream type by name.
type UnimplementedHealthDiscoveryServiceServer ¶
type UnimplementedHealthDiscoveryServiceServer struct{}
UnimplementedHealthDiscoveryServiceServer should be embedded to have forward compatible implementations.
NOTE: this should be embedded by value instead of pointer to avoid a nil pointer dereference when methods are called.
func (UnimplementedHealthDiscoveryServiceServer) FetchHealthCheck ¶
func (UnimplementedHealthDiscoveryServiceServer) FetchHealthCheck(context.Context, *v3.HealthCheckRequestOrEndpointHealthResponse) (*v3.HealthCheckSpecifier, error)
func (UnimplementedHealthDiscoveryServiceServer) StreamHealthCheck ¶
func (UnimplementedHealthDiscoveryServiceServer) StreamHealthCheck(grpc.BidiStreamingServer[v3.HealthCheckRequestOrEndpointHealthResponse, v3.HealthCheckSpecifier]) error
type UnsafeHealthDiscoveryServiceServer ¶
type UnsafeHealthDiscoveryServiceServer interface {
// contains filtered or unexported methods
}
UnsafeHealthDiscoveryServiceServer may be embedded to opt out of forward compatibility for this service. Use of this interface is not recommended, as added methods to HealthDiscoveryServiceServer will result in compilation errors.
Source Files
¶
- hds_grpc.pb.go