clusterhandles final routing of each request to its intended target. Each
clustercan 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
clusterobject, an additional field,
require_tlsmust be set to true.
ssl_configfield, which can be set to specify its configuration. The Cluster SSL Config Object appears as follows:
snifield for a
clusteraccepts a string that the Envoy cluster uses to specify Server Name Indication when creating TLS backend connections.
protocolsfield to one of the following:
"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_filterfield takes a colon
:delimited string to set a specified cipher list for TLS. This populates Envoys
trust_fileis 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_filewill 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
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.filenamefield or by specifying CRLs directly through the
crl.inline_stringfield. More details on CRL configuration can be found in the Cluster SSL Configuration Guide.
secreton the cluster. In the same form as above,
require_tlsmust be set to true. Note that if both an
secretare set on a cluster, the secret will override the ssl configuration. An example secret object is as follows:
gm-proxy. For information on how Envoy's SDS works, see the docs. The
secret_keyspecifies the name of the secret to fetch.
secret_nameshould be the SPIFFE Id of your certificate.
secret_validation_namewill set the validation context for the sds secret config.
namefield should match the announced
XDS_CLUSTERof 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.
namefield must be set to a value that does not match an announced service. If a match is found, the manually inserted
instanceswill be overridden.