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​cluster
object, an additional field, require_tls
must be set to true.ssl_config
field, which can be set to specify its configuration. The Cluster SSL Config Object appears as follows:sni
field for a cluster
accepts a string that the Envoy cluster uses to specify Server Name Indication when creating TLS backend connections.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.cipher_filter
field takes a colon :
delimited string to set a specified cipher list for TLS. This populates Envoys cipher_suites
field.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.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
.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.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: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.cluster_key
zone_key
name
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.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.require_tls
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.secret
ssl_config
instances
circuit_breakers
outlier_detection
health_checks
lb_policy
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.http2_protocol_options
ring_hash_lb_config
lb_policy
field is set to ring_hash
.original_dst_lb_config
least_request_lb_config
lb_policy
field is set to least_request
.common_lb_config
checksum