diff --git a/website/content/docs/connect/cluster-peering/k8s.mdx b/website/content/docs/connect/cluster-peering/k8s.mdx index a65ea0193d..0966053398 100644 --- a/website/content/docs/connect/cluster-peering/k8s.mdx +++ b/website/content/docs/connect/cluster-peering/k8s.mdx @@ -97,7 +97,45 @@ Install Consul on Kubernetes by using the CLI to apply `values.yaml` to each clu ## Create a peering connection for Consul on Kubernetes -To peer Kubernetes clusters running Consul, you need to create a peering token and share it with the other cluster. Complete the following steps to create the peer connection. +To peer Kubernetes clusters running Consul, you need to create a peering token on one cluster (`cluster-01`) and share +it with the other cluster (`cluster-02`). The generated peering token from `cluster-01` will include the addresses of +the servers for that cluster. The servers for `cluster-02` will use that information to dial the servers in +`cluster-01`. Complete the following steps to create the peer connection. + +### Using mesh gateways for the peering connection +If the servers in `cluster-01` are not directly routable from the dialing cluster `cluster-02`, then you'll need to set up peering through mesh gateways. + +1. In `cluster-01` apply the `Mesh` custom resource so the generated token will have the mesh gateway addresses which will be routable from the other cluster. + + + + ```yaml + apiVersion: consul.hashicorp.com/v1alpha1 + kind: Mesh + metadata: + name: mesh + spec: + peering: + peerThroughMeshGateways: true + ``` + + + +1. In `cluster-02` apply the `Mesh` custom resource so that the servers for `cluster-02` will use their local mesh gateway to dial the servers for `cluster-01`. + + + + ```yaml + apiVersion: consul.hashicorp.com/v1alpha1 + kind: Mesh + metadata: + name: mesh + spec: + peering: + peerThroughMeshGateways: true + ``` + + ### Create a peering token @@ -167,6 +205,43 @@ Peers identify each other using the `metadata.name` values you establish when cr $ kubectl --context $CLUSTER2_CONTEXT apply --filename dialer.yaml ``` +### Configure the mesh gateway mode for traffic between services +Mesh gateways are required for service-to-service traffic between peered clusters. By default, this will mean that a +service dialing another service in a remote peer will dial the remote mesh gateway to reach that service. If you would +like to configure the mesh gateway mode such that this traffic always leaves through the local mesh gateway, you can use the `ProxyDefaults` CRD. + +1. In `cluster-01` apply the following `ProxyDefaults` CRD to configure the mesh gateway mode. + + + + ```yaml + apiVersion: consul.hashicorp.com/v1alpha1 + kind: ProxyDefaults + metadata: + name: global + spec: + meshGateway: + mode: local + ``` + + + +1. In `cluster-02` apply the following `ProxyDefaults` CRD to configure the mesh gateway mode. + + + + ```yaml + apiVersion: consul.hashicorp.com/v1alpha1 + kind: ProxyDefaults + metadata: + name: global + spec: + meshGateway: + mode: local + ``` + + + ### Export services between clusters The examples described in this section demonstrate how to export a service named `backend`. You should change instances of `backend` in the example code to the name of the service you want to export.