github
/
consul
mirror of https://github.com/hashicorp/consul
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

backport of commit 7dc27c7dfd (#15552) 

This pull request was automerged via backport-assistant
pull/15553/head
hc-github-team-consul-core 2022-11-24 13:03:13 -05:00 committed by GitHub
parent ab9e13c4e0
commit 8d90259b0f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 76 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
website/content/docs/connect/cluster-peering/k8s.mdx
View File

@ -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.
<CodeBlockConfig filename="mesh.yaml">
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
kind: Mesh
metadata:
name: mesh
spec:
peering:
peerThroughMeshGateways: true
```
</CodeBlockConfig>
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`.
<CodeBlockConfig filename="mesh.yaml">
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
kind: Mesh
metadata:
name: mesh
spec:
peering:
peerThroughMeshGateways: true
```
</CodeBlockConfig>
### 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.
<CodeBlockConfig filename="proxydefaults.yaml">
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
kind: ProxyDefaults
metadata:
name: global
spec:
meshGateway:
mode: local
```
</CodeBlockConfig>
1. In `cluster-02` apply the following `ProxyDefaults` CRD to configure the mesh gateway mode.
<CodeBlockConfig filename="proxydefaults.yaml">
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
kind: ProxyDefaults
metadata:
name: global
spec:
meshGateway:
mode: local
```
</CodeBlockConfig>
### 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.