cluster
A cluster handles final routing of each request to its intended target. Each cluster can have 0 or more instances defined, which are simply the host:port pairs of the targets. Instances within a cluster can be statically configured when the object is created, or dynamically loaded through the service discovery mechanisms
Static or dynamic instances
Circuit breakers
Health Checks
Outlier Detection
Outgoing SSL configuration
Directly via SSL certs on disk
Through SPIFFE/SPIRE and Envoy SDS
Load balancing policy and its configurations
{"zone_key": "default-zone","cluster_key": "catalog-service","name": "service","instances": [{"host": "localhost","port": 8080}],"circuit_breakers": {"max_connections": 500,"max_requests": 500},"outlier_detection": null,"health_checks": [],"lb_policy": "","http2_protocol_options": {},"secret": {"secret_key": "","secret_name": "","secret_validation_name": "","subject_alt_name": "","ecdh_curves": null,"set_current_client_cert_details": {"uri": false},"checksum": ""}}
To require TLS on the cluster object, an additional field, require_tls must be set to true.
There is also an optional ssl_config field, which can be set to specify it's configuration. The Cluster SSL Config Object appears as follows:
"ssl_config": {"cipher_filter": "","protocols": [],"cert_key_pairs": null,"trust_file": "","crl": null,"sni": null}
The Cluster SSL Configuration is used to populate an UpstreamTlsContext for the Envoy Cluster.
The sni field for a cluster accepts a string that the Envoy cluster uses to specify Server Name Indication when creating TLS backend connections.
To specify a minimum and maximum TLS protocol version, set the protocols field to one of the following: "TLSv1_0", "TLSv1_1", "TLSv1_2", "TLSv1_3". If one protocol is specified, it will be set as both the minimum and maximum protocol versions in Envoy. If more than one protocol version is specified in the list, the lowest will set the minimum TLS protocol version and the highest will set the maximum TLS protocol version. If this field is left empty, Envoy will choose the default TLS version.
The cipher_filter field takes a colon : delimited string to set a specified cipher list for TLS. This populates Envoys cipher_suites field.
Specifying the path to a trust_file is optional. If a path is specified, it will be added to the UpstreamTlsContext for verifying a presented server certificate. Otherwise, the server certificate will not be verified.
If the Cluster connects to a service that is secured via TLS, the trust_file will need to contain the root CA and any intermediate certificates to authenticate the sidecar as a client of the service. If you're unfamiliar with generating certificates, OpenSSL Certificate Authority is a great primer. The end result is that you have all trust certificates required by the service in a single file, the trust_file.
Specifying a crl (a PEM-encoded certificate revocation list) is also optional, and may be added by pointing to a path on disk to a CRL file from the crl.filename field or by specifying CRLs directly through the crl.inline_string field. More details on CRL configuration can be found in the Cluster SSL Configuration Guide.
To configure the service to use SPIFFE/SPIRE on its egress, you must set a secret on the cluster. In the same form as above, require_tls must be set to true. Note that if both an ssl_config and a secret are set on a cluster, the secret will override the ssl configuration. An example secret object is as follows:
"secret" : {"secret_key": "secret-{{.service.serviceName}}-secret","secret_name": "spiffe://{{ .Values.global.spire.trustDomain }}/{{.service.serviceName}}/mTLS","secret_validation_name": "spiffe://{{ .Values.global.spire.trustDomain }}","ecdh_curves": ["X25519:P-256:P-521:P-384"]}
This object will configure Envoy to use Secret Discovery Service to fetch SPIFFE certificates from the configured path specified as an environment variable SPIRE_PATH in gm-proxy. For information on how Envoy's SDS works, see the docs. The secret_key specifies the name of the secret to fetch. secret_name should be the SPIFFE Id of your certificate. secret_validation_name will set the validation context for the sds secret config.
A unique key used to identify this particular cluster configuration. This key is used in routes or shared_rules to handle routing of traffic to an endpoint.
The zone in which this object will live. It will only be able to be referenced by objects or sent to Sidecars that live in the same zone.
The name of the service that this cluster is addressing. This field has different behavior depending on whether this cluster will be pulling instances from service discovery or wether they will be manually inserted.
To use service discovery, the name field should match the announced XDS_CLUSTER of another service running in the mesh. If no match is found, from the service not yet being online or a incorrect spelling, the instance array will remain empty. If a match is found, then the discovered instances will be populated in the array. More information can be found in the service discovery pages.
To specify instances manually, with no service discovery, the name field must be set to a value that does not match an announced service. If a match is found, the manually inserted instances will be overridden.
If true, this cluster will only accept HTTPS connections. In this case, one of the secret or ssl_config fields should be set. If false, this cluster will only accept plaintext HTTP connections.
Configure SSL certificate configuration through Envoy's SDS (Secret Discovery Service)
Cluster SSL configuration for this cluster.
An array of instances that this cluster will use to route requests. Can be either manually inserted, or automatically populated from service discovery.
The order of how instances will handle requests is governed by the lb_policy field.
Default and high priority circuit breakers
Array of health checks.
Defaults to least_request, supported options are: round_robin, least_request, ring_hash, random, maglev, and cluster_provided. Both the least_request and ring_hash options require additional configuration in the least_request_lb_config field and ring_hash_lb_config field respectively.
Options for configuring HTTP/2. Setting this field indicates that the cluster supports HTTP/2, and must be set in order to upgrade connections to HTTP/2.
Specific configuration for the RingHash load balancing policy. Must be set if the lb_policy field is set to ring_hash.
Envoy RingHash Load Balancing Policy
This is a special purpose load balancer that can only be used with an original destination cluster. No other load balancing policy can be used with original destination clusters.
Envoy Original Destination Load Balancing Policy
Specific configuration for the LeastRequest load balancing policy. Must be set if the lb_policy field is set to least_request.
Envoy LeastRequest Load Balancing Policy
Common configuration for all load balancer implementations.
Envoy Common Load Balancer Configuration
An API calculated checksum. Can be used to verify that the API contains the expected object before performing a write.
