2022-06-14 22:15:14 +00:00
---
layout: docs
page_title: Cluster Peering on Kubernetes
description: >-
This page describes how to create peering connections, deploy services, export cluster services, and end peering connections for Consul cluster peering using Kubernetes (K8s).
---
# Cluster Peering on Kubernetes
2022-08-01 15:30:36 +00:00
~> **Cluster peering is currently in beta:** Functionality associated
with cluster peering is subject to change. You should never use the beta release in secure environments or production scenarios. Features in
2022-08-10 15:21:26 +00:00
beta may have performance issues, scaling issues, and limited support.<br/><br/>Cluster peering is not currently available in the HCP Consul offering.
2022-06-14 22:15:14 +00:00
2022-08-09 14:25:45 +00:00
To establish a cluster peering connection on Kubernetes, you need to enable the feature in the Helm chart and create custom resource definitions (CRDs) for each side of the peering.
2022-06-14 22:15:14 +00:00
2022-08-02 21:20:43 +00:00
The following CRDs are used to create and manage a peering connection:
2022-06-14 22:15:14 +00:00
- `PeeringAcceptor`: Generates a peering token and accepts an incoming peering connection.
- `PeeringDialer`: Uses a peering token to make an outbound peering connection with the cluster that generated the token.
## Prerequisites
2022-08-01 15:30:36 +00:00
You must implement the following requirements to create and use cluster peering connections with Kubernetes:
2022-08-02 21:20:43 +00:00
- Consul version 1.13.0 or later
2022-08-01 15:30:36 +00:00
- At least two Kubernetes clusters
- The Kubernetes clusters must be running in a flat network
2022-08-02 21:20:43 +00:00
- The network must be running on Consul on Kubernetes version 0.45 or later
2022-06-14 22:15:14 +00:00
### Helm chart configuration
2022-06-15 21:25:57 +00:00
2022-06-14 22:15:14 +00:00
To establish cluster peering through Kubernetes, deploy clusters with the following Helm values.
2022-06-23 15:38:36 +00:00
<CodeBlockConfig filename="values.yaml">
```yaml
global:
2022-08-01 19:28:50 +00:00
image: "hashicorp/consul:1.13.0"
2022-06-23 15:38:36 +00:00
peering:
enabled: true
connectInject:
enabled: true
2022-08-01 15:30:36 +00:00
controller:
2022-06-29 18:08:37 +00:00
enabled: true
2022-06-23 15:38:36 +00:00
meshGateway:
2022-06-14 22:15:14 +00:00
enabled: true
2022-06-23 15:38:36 +00:00
replicas: 1
```
</CodeBlockConfig>
2022-06-21 23:13:39 +00:00
2022-08-01 15:30:36 +00:00
Install Consul on Kubernetes on each Kubernetes cluster by applying `values.yaml` using the Helm CLI.
```shell-session
2022-06-21 23:27:06 +00:00
$ export HELM_RELEASE_NAME=cluster-name
2022-06-21 23:31:49 +00:00
```
```shell-session
2022-06-21 23:34:45 +00:00
$ helm install ${HELM_RELEASE_NAME} hashicorp/consul --version "0.45.0" --values values.yaml
2022-06-21 23:27:06 +00:00
```
2022-08-01 19:28:50 +00:00
## Create a peering token
2022-06-14 22:15:14 +00:00
To peer Kubernetes clusters running Consul, you need to create a peering token and share it with the other cluster.
2022-06-21 23:13:39 +00:00
1. In `cluster-01`, create the `PeeringAcceptor` custom resource.
2022-06-14 22:15:14 +00:00
<CodeBlockConfig filename="acceptor.yml">
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
kind: PeeringAcceptor
metadata:
name: cluster-02 ## The name of the peer you want to connect to
spec:
peer:
secret:
name: "peering-token"
key: "data"
backend: "kubernetes"
```
</CodeBlockConfig>
1. Apply the `PeeringAcceptor` resource to the first cluster.
```shell-session
2022-06-15 21:15:03 +00:00
$ kubectl apply --filename acceptor.yml
2022-06-14 22:15:14 +00:00
````
1. Save your peering token so that you can export it to the other cluster.
```shell-session
2022-06-15 21:15:03 +00:00
$ kubectl get secret peering-token --output yaml > peering-token.yml
2022-06-14 22:15:14 +00:00
```
2022-08-01 19:28:50 +00:00
## Establish a peering connection between clusters
2022-06-14 22:15:14 +00:00
1. Apply the peering token to the second cluster.
```shell-session
2022-06-15 21:15:03 +00:00
$ kubectl apply --filename peering-token.yml
2022-06-14 22:15:14 +00:00
```
2022-06-29 18:08:37 +00:00
1. In `cluster-02`, create the `PeeringDialer` custom resource.
2022-06-14 22:15:14 +00:00
<CodeBlockConfig filename="dialer.yml">
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
kind: PeeringDialer
metadata:
name: cluster-01 ## The name of the peer you want to connect to
spec:
peer:
secret:
name: "peering-token"
key: "data"
backend: "kubernetes"
```
</CodeBlockConfig>
1. Apply the `PeeringDialer` resource to the second cluster.
```shell-session
2022-06-15 21:15:03 +00:00
$ kubectl apply --filename dialer.yml
2022-06-14 22:15:14 +00:00
```
2022-08-01 19:28:50 +00:00
## Export services between clusters
2022-06-14 22:15:14 +00:00
2022-08-02 21:20:43 +00:00
1. For the service in "cluster-02" that you want to export, add the following [annotations](/docs/k8s/annotations-and-labels#consul-hashicorp-com-connect-service-upstreams) to your service's pods.
2022-06-14 22:15:14 +00:00
<CodeBlockConfig filename="backend-service.yml">
```yaml
##…
annotations:
"consul.hashicorp.com/connect-inject": "true"
"consul.hashicorp.com/transparent-proxy": "false"
##…
```
</CodeBlockConfig>
2022-06-29 18:08:37 +00:00
1. In `cluster-02`, create an `ExportedServices` custom resource.
2022-06-14 22:15:14 +00:00
<CodeBlockConfig filename="exportedsvc.yml">
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
kind: ExportedServices
metadata:
name: default ## The name of the partition containing the service
spec:
services:
2022-06-29 18:08:37 +00:00
- name: backend-service ## The name of the service you want to export
consumers:
- peer: cluster-01 ## The name of the peer that receives the service
2022-06-14 22:15:14 +00:00
```
</CodeBlockConfig>
2022-08-01 19:28:50 +00:00
1. Apply the service file and the `ExportedServices` resource for the second cluster.
```shell-session
$ kubectl apply --filename backend-service.yml --filename exportedsvc.yml
```
## Authorize services for peers
2022-06-14 22:15:14 +00:00
1. Create service intentions for the second cluster.
<CodeBlockConfig filename="intention.yml">
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceIntentions
metadata:
name: backend-deny
spec:
destination:
name: backend-service
sources:
- name: "*"
action: deny
- name: frontend-service
action: allow
```
</CodeBlockConfig>
2022-08-01 19:28:50 +00:00
1. Apply the intentions to the second cluster.
2022-06-14 22:15:14 +00:00
```shell-session
2022-08-01 19:28:50 +00:00
$ kubectl apply --filename intention.yml
2022-06-14 22:15:14 +00:00
```
2022-06-29 18:08:37 +00:00
1. For the services in `cluster-01` that you want to access the "backend-service," add the following annotations to the service file.
2022-06-14 22:15:14 +00:00
<CodeBlockConfig filename="frontend-service.yml">
```yaml
##…
annotations:
"consul.hashicorp.com/connect-inject": "true"
"consul.hashicorp.com/transparent-proxy": "false"
"consul.hashicorp.com/connect-service-upstreams": "backend-service.svc.cluster-02.peer:1234"
##…
```
</CodeBlockConfig>
1. Apply the service file to the first cluster.
```shell-session
2022-06-15 21:15:03 +00:00
$ kubectl apply --filename frontend-service.yml
2022-06-14 22:15:14 +00:00
```
1. Run the following command and check the output to confirm that you peered your clusters successfully.
```shell-session
$ curl localhost:1234
{
2022-06-28 22:54:57 +00:00
"name": "backend-service",
2022-06-14 22:15:14 +00:00
##…
2022-06-28 22:54:57 +00:00
"body": "Response from backend",
"code": 200
2022-06-14 22:15:14 +00:00
}
```
## End a peering connection
To end a peering connection, delete both the `PeeringAcceptor` and `PeeringDialer` resources.
2022-06-29 18:08:37 +00:00
To confirm that you deleted your peering connection, in `cluster-01`, query the `/health` HTTP endpoint. The peered services should no longer appear.
2022-06-14 22:15:14 +00:00
```shell-session
$ curl "localhost:8500/v1/health/connect/backend?peer=cluster-02"
```
2022-08-10 17:14:36 +00:00
## Recreate/Reset a peering connection
To recreate or reset the peering connection, a new peering token needs to be generated on the cluster where the `PeeringAcceptor` was created, which in this case is `cluster-01`.
This can be performed by creating/updating the annotation `consul.hashicorp.com/peering-version` on the `PeeringAcceptor`. If the annotation already exists, update its value to a version that is higher.
Once the above is done, repeat the steps in the peering process from saving your peering token so that you can export it to the other cluster. This will re-establish peering with the updated token.
-> **NOTE:** A new peering token is only generated upon manually setting and updating the value of the annotation `consul.hashicorp.com/peering-version`. Creating a new token will cause the previous token to expire.