We need to watch for changes to peerings and update the server addresses which get served by the ring buffer.
Also, if there is an active connection for a peer, we are getting up-to-date server addresses from the replication stream and can safely ignore the token's addresses which may be stale.
Includes:
- Improved scannability and organization of checks overview
- Checks overview includes more guidance on
- How to register a health check
- The options available for a health check definition
- Contextual cross-references to maintenance mode
Contains 2 changes to the GetEnvoyBootstrapParams response to support
consul-dataplane.
Exposing node_name and node_id:
consul-dataplane will support providing either the node_id or node_name in its
configuration. Unfortunately, supporting both in the xDS meta adds a fair amount
of complexity (partly because most tables are currently indexed on node_name)
so for now we're going to return them both from the bootstrap params endpoint,
allowing consul-dataplane to exchange a node_id for a node_name (which it will
supply in the xDS meta).
Properly setting service for gateways:
To avoid the need to special case gateways in consul-dataplane, service will now
either be the destination service name for connect proxies, or the gateway
service name. This means it can be used as-is in Envoy configuration (i.e. as a
cluster name or in metric tags).
* Clarify docs around using either Consul or Vault managed PKI paths
The current docs can be misread to indicate that you need both the
Consul and Vault managed PKI Paths policies. The [Learning Tutorial](https://learn.hashicorp.com/tutorials/consul/vault-pki-consul-connect-ca?in=consul/vault-secure#create-vault-policies)
is clearer. This tries to make the original docs as clear as the
learning tutorial
* Clarify that PKI secret engines are used to store certs
Co-authored-by: Blake Covarrubias <blake.covarrubias@gmail.com>
* Clarify transparent proxy documentation
Some confusion over known limitations for transparent proxy, specifically over federation versus cluster peering.
Updated `KubeDNS` to Kubernetes DNS for consistency with Kubernetes documentation.
Co-authored-by: David Yu <dyu@hashicorp.com>
Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com>
smamindla57