status-im
/
consul
mirror of https://github.com/status-im/consul.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #13433 from hashicorp/docs-cluster-peering-technical-preview 

docs: Cluster Peering for OSS Technical Preview
This commit is contained in:
Tu Nguyen 2022-06-22 00:10:11 -07:00 committed by GitHub
parent 1e3f6f9c92 5469fa6d3f
commit 81c1092531
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
10 changed files with 1337 additions and 82 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
website/content/api-docs/health.mdx
View File

@ -235,7 +235,7 @@ The table below shows this endpoint's support for
- `near` `(string: "")` - Specifies a node name to sort the node list in
ascending order based on the estimated round trip time from that node. Passing
`?near=_agent` uses the agent's node for the sort.
**Note** that using `near` will ignore
~> **Note:** Using `near` will ignore
[`use_streaming_backend`](/docs/agent/config/config-files#use_streaming_backend) and always
use blocking queries, because the data required to sort the results is not available
to the streaming backend.
@ -259,6 +259,8 @@ The table below shows this endpoint's support for
- `filter` `(string: "")` - Specifies the expression used to filter the
queries results prior to returning the data.
- `peer` `(string: "")` - Specifies the imported service's peer. Applies only to imported services.
- `ns` `(string: "")` <EnterpriseAlert inline /> - Specifies the namespace of the service.
You can also [specify the namespace through other methods](#methods-to-specify-namespace).
@ -431,8 +433,8 @@ gateway](/docs/connect/gateways/ingress-gateway) for a service in a given datace
Parameters and response format are the same as
[`/health/service/:service`](/api-docs/health#list-nodes-for-service).
**Note** that unlike `/health/connect/:service` and `/health/service/:service` this
endpoint does not support the [streaming backend](/api-docs/features/blocking#streaming-backend).
~> **Note:** Unlike `/health/connect/:service` and `/health/service/:service` this
endpoint does not support the `peer` query parameter and the [streaming backend](/api-docs/features/blocking#streaming-backend).
## List Checks in State

319
website/content/api-docs/peering.mdx Normal file
View File

@ -0,0 +1,319 @@
---
layout: api
page_title: Cluster Peering - HTTP API
description: The /peering endpoints allow for managing cluster peerings.
---
# Cluster Peering - HTTP API
~> **Cluster peering is currently in technical preview:** Functionality associated
with cluster peering is subject to change. You should never use the technical
preview release in secure environments or production scenarios. Features in
technical preview may have performance issues, scaling issues, and limited support.
The functionality described here is available only in
[Consul](https://www.hashicorp.com/products/consul/) version 1.13.0 and later.
## Generate a Peering Token
This endpoint generates a peering token.
| Method | Path | Produces |
| ------- | -------------------- | ------------------ |
| `POST` | `/peering/token` | `application/json` |
The table below shows this endpoint's support for
[blocking queries](/api-docs/features/blocking),
[consistency modes](/api-docs/features/consistency),
[agent caching](/api-docs/features/caching), and
[required ACLs](/api#authentication).
| Blocking Queries | Consistency Modes | Agent Caching | ACL Required |
| ---------------- | ----------------- | ------------- | ---------------- |
| `NO` | `none` | `none` | `none` |
### JSON Request Body Schema
- `PeerName` `(string: <required>)` - The name assigned to the peer cluster.
The `PeerName` is used to reference the peer cluster in service discovery queries
and configuration entries such as `service-intentions`. This field must be a
valid DNS hostname label.
- `Partition` `(string: "")` - <EnterpriseAlert inline /> The admin partition that the
peering token is generated from. Uses `default` when not specified.
- `Datacenter` `(string: "")` - Specifies the datacenter where the peering token is generated. Defaults to the
agent's datacenter when not specified.
- `Token` `(string: "")` - Specifies the ACL token to use in the request. Takes precedence
over the token specified in the `token` query parameter, `X-Consul-Token` request header,
and `CONSUL_HTTP_TOKEN` environment variable.
- `Meta` `(map<string|string>: <optional>)` - Specifies KV metadata to associate with
the peering. This parameter is not required and does not directly impact the cluster
peering process.
### Sample Payload
```json
{
"PeerName": "cluster-02",
"Meta": {
"env": "production"
}
}
```
### Sample Request
```shell-session
$ curl --request POST \
--header "X-Consul-Token: 5cdcae6c-0cce-4210-86fe-5dff3b984a6e" \
--data @payload.json \
http://127.0.0.1:8500/v1/peering/token
```
### Sample Response
```json
{
"PeeringToken": "eyJDQSI6bnVsbCwiU2V..."
}
```
## Establish a Peering Connection
This endpoint establishes a peering connection with a given peering token.
| Method | Path | Produces |
| ------- | -------------------- | ------------------ |
| `POST` | `/peering/establish` | `application/json` |
This endpoint returns no data. Success or failure is indicated by the status
code returned.
The table below shows this endpoint's support for
[blocking queries](/api-docs/features/blocking),
[consistency modes](/api-docs/features/consistency),
[agent caching](/api-docs/features/caching), and
[required ACLs](/api#authentication).
| Blocking Queries | Consistency Modes | Agent Caching | ACL Required |
| ---------------- | ----------------- | ------------- | ---------------- |
| `NO` | `none` | `none` | `none` |
### JSON Request Body Schema
- `PeerName` `(string: <required>)` - The name assigned to the peer cluster.
The `PeerName` is used to reference the peer cluster in service discovery queries
and configuration entries such as `service-intentions`. This field must be a
valid DNS hostname label.
- `Partition` `(string: "")` - <EnterpriseAlert inline /> The admin partition
that peers to the cluster that generated the peering token. Uses `default`
when not specified.
- `PeeringToken` `(string: <required>)` - The peering token fetched from the
peer cluster.
- `Datacenter` `(string: "")` - Specifies the datacenter where the peering token is generated. Defaults to the
agent's datacenter when not specified.
- `Token` `(string: "")` - Specifies the ACL token to use in the request. Takes precedence
over the token specified in the `token` query parameter, `X-Consul-Token` request header,
and `CONSUL_HTTP_TOKEN` environment variable.
- `Meta` `(map<string|string>: <optional>)` - Specifies KV metadata to associate with
the peering. This parameter is not required and does not directly impact the cluster
peering process.
### Sample Payload
```json
{
"PeerName": "cluster-01",
"PeeringToken": "eyJDQSI6bnVsbCwiU2V...",
"Meta": {
"env": "production"
}
}
```
### Sample Request
```shell-session
$ curl --request POST \
--header "X-Consul-Token: 5cdcae6c-0cce-4210-86fe-5dff3b984a6e" \
--data @payload.json \
http://127.0.0.1:8500/v1/peering/establish
```
### Sample Response
```json
{}
```
## Read a Peering Connection
This endpoint returns information about a peering connection for the specified peer name.
| Method | Path | Produces |
| ------ | ------------------ | ------------------ |
| `GET` | `/peering/:name` | `application/json` |
The table below shows this endpoint's support for
[blocking queries](/api-docs/features/blocking),
[consistency modes](/api-docs/features/consistency),
[agent caching](/api-docs/features/caching), and
[required ACLs](/api#authentication).
| Blocking Queries | Consistency Modes | Agent Caching | ACL Required |
| ---------------- | ----------------- | ------------- | ------------ |
| `NO` | `consistent` | `none` | `none` |
### Path Parameters
- `name` `(string: <required>)` - Specifies the peering to read.
### Query Parameters
- `partition` `(string: "")` <EnterpriseAlert inline /> - Specifies the partition of the peering
to read. If not specified will default to `default`.
### Sample Request
```shell-session
$ curl --header "X-Consul-Token: b23b3cad-5ea1-4413-919e-c76884b9ad60" \
http://127.0.0.1:8500/v1/peering/cluster-02
```
### Sample Response
```json
{
"ID": "462c45e8-018e-f19d-85eb-1fc1bcc2ef12",
"Name": "cluster-02",
"State": "INITIAL",
"PeerID": "e83a315c-027e-bcb1-7c0c-a46650904a05",
"PeerServerName": "server.dc1.consul",
"PeerServerAddresses": [
"10.0.0.1:8300"
],
"CreateIndex": 89,
"ModifyIndex": 89
}
```
## Delete a Peering Connection
Call this endpoint to delete a peering connection. Consul deletes all data imported from the peer in the background. The peering connection is removed after all associated data has been deleted.
Operators can still read the peering connections while the data is being removed. A `DeletedAt`
field will be populated with the timestamp of when the peering was marked for deletion.
| Method | Path | Produces |
| -------- | ------------------ | -------- |
| `DELETE` | `/peering/:name` | N/A |
This endpoint returns no data. Success or failure is indicated by the status
code returned.
The table below shows this endpoint's support for
[blocking queries](/api-docs/features/blocking),
[consistency modes](/api-docs/features/consistency),
[agent caching](/api-docs/features/caching), and
[required ACLs](/api#authentication).
| Blocking Queries | Consistency Modes | Agent Caching | ACL Required |
| ---------------- | ----------------- | ------------- | ------------- |
| `NO` | `none` | `none` | `none` |
### Path Parameters
- `name` `(string: <required>)` - Specifies the name of the peering to delete.
- `partition` `(string: "")` <EnterpriseAlert inline /> - Specifies the partition of the peering
to delete. Uses `default` when not specified.
### Sample Request
```shell-session
$ curl --request DELETE \
--header "X-Consul-Token: b23b3cad-5ea1-4413-919e-c76884b9ad60" \
http://127.0.0.1:8500/v1/peering/cluster-02
```
### Sample Read Output After Deletion Prior to Removal
```json
{
"ID": "462c45e8-018e-f19d-85eb-1fc1bcc2ef12",
"Name": "cluster-02",
"State": "TERMINATED",
"PeerID": "e83a315c-027e-bcb1-7c0c-a46650904a05",
"PeerServerName": "server.dc1.consul",
"PeerServerAddresses": [
"10.0.0.1:8300"
],
"DeletedAt": "2022-12-14T23:00:00Z",
"CreateIndex": 89,
"ModifyIndex": 89
}
```
## List all Peerings
This endpoint lists all the peerings.
@include 'http_api_results_filtered_by_acls.mdx'
| Method | Path | Produces |
| ------ | ------------- | ------------------ |
| `GET` | `/peerings` | `application/json` |
The table below shows this endpoint's support for
[blocking queries](/api-docs/features/blocking),
[consistency modes](/api-docs/features/consistency),
[agent caching](/api-docs/features/caching), and
[required ACLs](/api#authentication).
| Blocking Queries | Consistency Modes | Agent Caching | ACL Required |
| ---------------- | ----------------- | ------------- | ------------- |
| `NO` | `consistent` | `none` | `none` |
### Sample Request
```shell-session
$ curl --header "X-Consul-Token: 0137db51-5895-4c25-b6cd-d9ed992f4a52" \
http://127.0.0.1:8500/v1/peerings
```
### Sample Response
```json
[
{
"ID": "462c45e8-018e-f19d-85eb-1fc1bcc2ef12",
"Name": "cluster-02",
"State": "ACTIVE",
"Partition": "default",
"PeerID": "e83a315c-027e-bcb1-7c0c-a46650904a05",
"PeerServerName": "server.dc1.consul",
"PeerServerAddresses": [
"10.0.0.1:8300"
],
"CreateIndex": 89,
"ModifyIndex": 89
},
{
"ID": "1460ada9-26d2-f30d-3359-2968aa7dc47d",
"Name": "cluster-03",
"State": "INITIAL",
"Partition": "default",
"Meta": {
"env": "production"
},
"CreateIndex": 109,
"ModifyIndex": 119
},
]
```

147
website/content/docs/connect/cluster-peering/create-manage-peering.mdx Normal file
View File

@ -0,0 +1,147 @@
---
layout: docs
page_title: Create and Manage Peering Connections
description: >-
This page describes how to use the Consul CLI to create, manage, and delete peering connections for cluster peering.
---
# Create and Manage Peering Connections
~> **Cluster peering is currently in technical preview:** Functionality associated with cluster peering is subject to change. You should never use the technical preview release in secure environments or production scenarios. Features in technical preview may have performance issues, scaling issues, and limited support.
A peering token enables cluster peering between different datacenters. Once you generate a peering token, you can use it to establish a connection between clusters. Then you can export services and authorize other clusters to call those services.
To peer clusters, you must complete the following steps in order:
1. Create a peering token
1. Establish a connection between clusters
1. Export service endpoints
1. Authorize connections between peers
## Create a peering token
You can generate peering tokens and initiate connections using the Consul API on any available agent. However, we recommend performing these operations through a client agent in the partition you want to connect.
To begin the cluster peering process, generate a peering token in one of your clusters. The other cluster uses this token to establish the peering connection.
In `cluster-01`, issue a request for a peering token using the [HTTP API](/api-docs/peering).
```shell-session
$ curl --request POST --data '{"PeerName":"cluster-02"}' --url http://localhost:8500/v1/peering/token
```
The CLI outputs the peering token, which is a base64-encoded string containing the token details.
Create a JSON file that contains the first cluster's name and the peering token.
<CodeBlockConfig filename="peering_token.json" hideClipboard>
```json
{
"PeerName": "cluster-01",
"PeeringToken": "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbiIsImF1ZCI6IlNvbHIifQ.5T7L_L1MPfQ_5FjKGa1fTPqrzwK4bNSM812nW6oyjb8"
}
```
</CodeBlockConfig>
## Establish a connection between clusters
Next, use the peering token to establish a secure connection between the clusters. In the client agents of “cluster-02,” establish the peering connection using the HTTP API. This endpoint does not generate an output unless there is an error.
```shell-session
$ curl --request POST --data @peering_token.json http://127.0.0.1:8500/v1/peering/establish
```
In the peer parameter, specify a name for the first cluster. The `PeeringToken` parameter should include the entire peering token created in the first cluster.
When you connect server agents through cluster peering, they will peer their default partitions. To establish peering connections for other partitions through server agents, you must specify the partitions you want to peer using the `Partition` field of the request body.
## Export service endpoints
After you establish a connection between the clusters, you need to create a configuration entry that defines the services that are available for other clusters. Consul uses this configuration entry to advertise service information and support service mesh connections across clusters.
First, create a configuration entry and specify the `Kind` as `“exported-services”`.
<CodeBlockConfig filename="peering-config.hcl" highlight="1" hideClipboard>
```hcl
Kind = "exported-services"
Services = [
{
## The name and namespace of the service to export.
Name = "service-name"
Namespace = "default"
## The list of peer clusters to export the service to.
Consumers = [
{
## The peer name to reference in config is the one set
## during the peering process.
Peer = "cluster-02"
}
]
```
</CodeBlockConfig>
Then, add the configuration entry to your cluster.
```shell-session
$ consul config write peering-config.hcl
```
Before you proceed, wait for the clusters to sync and make services available to their peers. You can issue an endpoint query to [check the peered cluster status](#check-peered-cluster-status).
## Authorize connections from peers
Before you can call services from peered clusters, you must set service intentions that authorize those clusters to use specific services. Consul prevents services from being exported to unauthorized clusters.
First, create a configuration entry and specify the `Kind` as `“service-intentions”`. Declare the service on "cluster-02" that can access the service in "cluster-01." The following example sets service intentions so that "frontend-service" can access "backend-service."
<CodeBlockConfig filename="peering-intentions.hcl" highlight="1" hideClipboard>
```hcl
Kind = "service-intentions"
Name = "backend-service"
Sources = [
{
Name = "frontend-service"
Peer = "cluster-02"
Action = "allow"
}
]
```
</CodeBlockConfig>
If the peer’s name is not specified in `Peer`, then Consul assumes that the service is in the local cluster.
Then, add the configuration entry to your cluster.
```shell-session
$ consul config write peering-intentions.hcl
```
## Check peered cluster status
To confirm that you peered your clusters, you can [query the `/health/service` endpoint](/api-docs/health) of one cluster from the other cluster. For example, in "cluster-02," query the endpoint and add the `peer=cluster-01` query parameter to the end of the URL.
```shell-session
$ curl \
"http://127.0.0.1:8500/v1/health/service/service-name?peer=cluster-01"
```
A successful query will include service information in the output.
## Remove peering connections
After you create a peering connection between clusters in different datacenters, you can disconnect the peered clusters. Deleting a peering connection stops data replication to the peer and deletes imported data, including services and CA certificates.
In “cluster-01,” request the deletion via the HTTP API.
```shell-session
$ curl --request DELETE http://127.0.0.1:8500/v1/peering/cluster-02
```

50
website/content/docs/connect/cluster-peering/index.mdx Normal file
View File

@ -0,0 +1,50 @@
---
layout: docs
page_title: What is Cluster Peering?
description: >-
This page details the cluster peering process for connecting Consul clusters across datacenters, including differences between cluster peering and the similar concept of WAN federation.
---
# What is Cluster Peering?
~> **Cluster peering is currently in technical preview**: Functionality associated with cluster peering is subject to change. You should never use the technical preview release in secure environments or production scenarios. Features in technical preview may have performance issues, scaling issues, and limited support.
You can create peering connections between two or more independent clusters so that services deployed to different partitions or datacenters can to communicate.
## Overview
Cluster peering allows Consul clusters in different datacenters to communicate with each other. The cluster peering process consists of the following steps:
1. Create a peering token to share with other clusters
1. Establish a connection between clusters
1. Make services available to other clusters
For detailed instructions on setting up cluster peering with the Consul CLI, refer to [Create and Manage Peering Connections](/docs/connect/cluster-peering/create-manage-peering).
### Differences between WAN federation and cluster peering
WAN federation and cluster peering are different ways to connect clusters. The most important distinction is that WAN federation assumes clusters are owned by the same operators, so it maintains and replicates global states such as ACLs and configuration entries. As a result, WAN federation requires a _primary datacenter_ to serve as an authority for replicated data.
Regardless of whether you connect your clusters through WAN federation or cluster peering, human and machine users can use either method to discover services in other clusters or dial them through the service mesh.
| | WAN Federation | Cluster Peering |
| :----------------------------------------------- | :------------: | :-------------: |
| Connects clusters across datacenters | &#9989; | &#9989; |
| Shares support queries and service endpoints | &#9989; | &#9989; |
| Connects clusters owned by different operators | &#10060; | &#9989; |
| Functions without declaring primary datacenter | &#10060; | &#9989; |
| Shares key/value stores | &#9989; | &#10060; |
| Uses gossip protocol | &#9989; | &#10060; |
## Technical preview constraints
Not all features and functionality are available in the technical preview release. In particular, consider the following technical constraints:
- Consul ACLs must be disabled or the ACL `default_policy` must be set to `allow`.
- Mesh gateways for _server to server traffic_ are not available. However, mesh gateways for _service to service traffic_ between clusters are available.
- Services exported to peered clusters must not be configured as HTTP.
- Support for dynamic routing such as splits, custom routes, or redirects is not available.
- The `consul intention CLI` command is not supported. To manage intentions that specify services in peered clusters, use [configuration entries](/docs/connect/config-entries/service-intentions).
- [L7 permissions](/docs/connect/l7-traffic) are not supported.
- Configuring service failover across peers is not supported.
- Accessing key/value stores across peers is not supported.
- Consul datacenters that are already federated stay federated.
- Non-enterprise Consul instances cannot sync services with namespaces outside of the `default` namespace.

232
website/content/docs/connect/cluster-peering/k8s.mdx Normal file
View File

@ -0,0 +1,232 @@
---
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
~> **Cluster peering is currently in technical preview:** Functionality associated
with cluster peering is subject to change. You should never use the technical
preview release in secure environments or production scenarios. Features in
technical preview may have performance issues, scaling issues, and limited support.
To establish a cluster peering connection on Kubernetes, you need to enable the feature in the Helm chart and create custom resource definitions for each side of the peering.
The following Custom Resource Definitions (CRDs) are used to create and manage a peering connection:
- `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
To create and use cluster peering connections with Kubernetes, you need at least two Kubernetes clusters running in a flat network with Consul on Kubernetes v.0.45 or later.
### Helm chart configuration
To establish cluster peering through Kubernetes, deploy clusters with the following Helm values.
<CodeTabs heading="values.yaml">
<CodeBlockConfig lineNumbers>
```yaml
global:
image: "hashicorp/consul:1.13.0-alpha2"
peering:
enabled: true
connectInject:
enabled: true
meshGateway:
enabled: true
replicas: 1
```
</CodeBlockConfig>
</CodeTabs>
Install Consul on Kubernetes on each Kubernetes cluster by applying `values.yaml` using the Helm CLI.
```shell-session
$ export HELM_RELEASE_NAME=cluster-name
```
```shell-session
$ helm install ${HELM_RELEASE_NAME} hashicorp/consul --version "0.45.0" --values values.yaml
```
## Create a peering connection
To peer Kubernetes clusters running Consul, you need to create a peering token and share it with the other cluster.
1. In `cluster-01`, create the `PeeringAcceptor` custom resource.
<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
$ kubectl apply --filename acceptor.yml
````
1. Save your peering token so that you can export it to the other cluster.
```shell-session
$ kubectl get secret peering-token --output yaml > peering-token.yml
```
1. Apply the peering token to the second cluster.
```shell-session
$ kubectl apply --filename peering-token.yml
```
1. In “cluster-02,” create the `PeeringDialer` custom resource.
<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
$ kubectl apply --filename dialer.yml
```
## Deploy and export cluster services
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. This service is referred to as "backend-service" in the following steps.
<CodeBlockConfig filename="backend-service.yml">
```yaml
##…
annotations:
"consul.hashicorp.com/connect-inject": "true"
"consul.hashicorp.com/transparent-proxy": "false"
##…
```
</CodeBlockConfig>
1. In “cluster-02,” create an `ExportedServices` custom resource.
<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:
name: backend-service ## The name of the service you want to export
consumers:
peerName: cluster-01 ## The name of the peer that receives the service
```
</CodeBlockConfig>
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>
1. Apply the service file, the `ExportedServices` resource, and the intentions to the second cluster.
```shell-session
$ kubectl apply --filename backend-service.yml --filename exportedsvc.yml --filename intention.yml
```
1. To confirm that you peered your clusters, in “cluster-01,” query the `/health` HTTP endpoint.
```shell-session
$ curl "localhost:8500/v1/health/connect/backend?peer=cluster-02"
```
1. For the services in “cluster-01” that you want to access the “backend-service,” add the following annotations to the service file.
<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
$ kubectl apply --filename frontend-service.yml
```
1. Run the following command and check the output to confirm that you peered your clusters successfully.
```shell-session
$ curl localhost:1234
{
“name”: “backend-service”,
##…
“body”: “Response from backend”,
“code”: 200
}
```
## End a peering connection
To end a peering connection, delete both the `PeeringAcceptor` and `PeeringDialer` resources.
To confirm that you deleted your peering connection, in “cluster-01,” query the `/health` HTTP endpoint. The peered services should no longer appear.
```shell-session
$ curl "localhost:8500/v1/health/connect/backend?peer=cluster-02"
```

591
website/content/docs/connect/config-entries/exported-services.mdx
View File

@ -8,22 +8,20 @@ description: >-
# Exported Services
<EnterpriseAlert />
This topic describes the `exported-services` configuration entry type. The `exported-services` configuration entry enables Consul to export service instances to other clusters from a single file and connect services across clusters. For additional information, refer to [Cluster Peering](/docs/connect/cluster-peering) and [Admin Partitions](/docs/enterprise/admin-partitions).
This topic describes the `exported-services` configuration entry type. The `exported-services` configuration entry enables Consul to export service instances to other admin partitions from a single file. This enables your services to be networked across admin partitions. See [Admin Partitions](/docs/enterprise/admin-partitions) for additional information.
-> **v1.11.0+:** This config entry is supported in Consul Enterprise versions 1.11.0+.
-> **v1.11.0+:** This config entry is supported in Consul versions 1.11.0+.
## Introduction
You can configure Consul to export services contained in an admin partition to one or more additional partitions by declaring the `exported-services` configuration entry in the `kind` field. This enables you to route traffic between services in different clusters that share a single set of Consul servers.
To configure Consul to export services contained in a Consul Enterprise admin partition or Consul OSS datacenter to one or more additional clusters, create a new configuration entry and declare `exported-services` in the `kind` field. This configuration entry enables you to route traffic between services in different clusters.
You can configure the settings defined in the `exported-services` configuration entry to apply to all namespaces and federated datacenters.
You can configure the settings defined in the `exported-services` configuration entry to apply to all namespaces in a Consul Enterprise admin partition.
## Requirements
- A Consul Enterprise binary
- A corresponding partition that the configuration entry can export to. For example, the `exported-services` configuration entry for a partition named `frontend` requires an existing `frontend` partition.
- A 1.11.0+ Consul Enteprise binary or a 1.13.0+ Consul OSS binary.
- **Enterprise Only**: A corresponding partition that the configuration entry can export from. For example, the `exported-services` configuration entry for a partition named `frontend` requires an existing `frontend` partition.
## Usage
@ -37,6 +35,56 @@ You can configure the settings defined in the `exported-services` configuration
Configure the following parameters to define a `exported-services` configuration entry:
<Tabs>
<Tab heading="Consul OSS">
<CodeTabs heading="Exported services configuration syntax" tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
```hcl
Kind = "exported-services"
Name = "default"
Services = [
{
Name = "<name of service to export>"
Consumers = [
{
PeerName = "<name of the peered cluster that dials the exported service>"
}
]
}
]
```
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
kind: ExportedServices
metadata:
name: default
spec:
services:
- name: <name of service to export>
consumers:
- peerName: <name of the peered cluster that dials the exported service>
```
```json
"Kind": "exported-services",
"Name": "default",
"Services": [
{
"Name": "<name of service to export>",
"Consumers": [
{
"PeerName": "<name of the peered cluster that dials the exported service>"
}
]
}
]
```
</CodeTabs>
</Tab>
<Tab heading="Consul Enterprise (Peers)">
<CodeTabs heading="Exported services configuration syntax" tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
```hcl
@ -49,8 +97,8 @@ Services = [
Namespace = "<namespace in the partition containing the service to export>"
Consumers = [
{
Partition = "<name of the partition that will dial the exported service>"
},
PeerName = "<name of the peered cluster that dials the exported service>"
}
]
}
]
@ -66,7 +114,7 @@ spec:
- name: <name of service to export>
namespace: <namespace in the partition containing the service to export>
consumers:
- partition: <name of the partition that will dial the exported service>
- peerName: <name of the peered cluster that dials the exported service>
```
```json
@ -75,18 +123,73 @@ spec:
"Name": "<partition containing services to export>",
"Services": [
{
"Consumers": [
{
"Partition": "<name of partition that will dial the exported service>"
}
],
"Name": "<name of service to export>",
"Namespace": "<namespace in the partition containing the service to export>"
"Consumers": [
{
"PeerName": "<name of the peered cluster that dials the exported service>"
}
]
}
]
```
</CodeTabs>
</Tab>
<Tab heading="Consul Enterprise (Partitions)">
<CodeTabs heading="Exported services configuration syntax" tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
```hcl
Kind = "exported-services"
Partition = "<partition containing services to export>"
Name = "<partition containing services to export>"
Services = [
{
Name = "<name of service to export>"
Namespace = "<namespace in the partition containing the service to export>"
Consumers = [
{
Partition = "<name of the partition that dials the exported service>"
}
]
}
]
```
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
kind: ExportedServices
metadata:
name: <partition containing services to export>
spec:
services:
- name: <name of service to export>
namespace: <namespace in the partition containing the service to export>
consumers:
- partition: <name of the partition that dials the exported service>
```
```json
"Kind": "exported-services",
"Partition": "<partition containing services to export>",
"Name": "<partition containing services to export>",
"Services": [
{
"Name": "<name of service to export>",
"Namespace": "<namespace in the partition containing the service to export>"
"Consumers": [
{
"Partition": "<name of partition that dials the exported service>"
}
]
}
]
```
</CodeTabs>
</Tab>
</Tabs>
### Configuration Parameters
@ -94,25 +197,113 @@ The following table describes the parameters associated with the `exported-servi
| Parameter | Description | Required | Default |
| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------- |
| `Kind` | String value that enables the configuration entry. The value should always be `exported-services` (HCL and JSON) or `ExportedServices` (YAML) | Required | None |
| `Partition` | String value that specifies the name of the partition that contains the services you want to export. | Required | None |
| `Name` | String value that specifies the name of the partition that contains the services you want to export. | Required | None |
| `Services` | List of objects that specify which services to export. See [`Services`](#services) for details. | Required | None |
| `Meta` | Object that defines a map of the max 64 key/value pairs. | Optional | None |
| `Kind` | String value that enables the configuration entry. The value should always be `exported-services` (HCL and JSON) or `ExportedServices` (YAML) | Required | None |
| `Partition` | <EnterpriseAlert inline /> String value that specifies the name of the partition that contains the services you want to export. | Required | None |
| `Name` | String value that specifies the name of the partition that contains the services you want to export. Must be `default` in Consul OSS. | Required | None |
| `Services` | List of objects that specify which services to export. For details, refer to [`Services`](#services). | Required | None |
| `Meta` | Object that defines a map of the max 64 key/value pairs. | Optional | None |
### Services
The `Services` parameter contains one or more lists of parameters that specify which services to export, which namespaces the services reside, and the destination partition for the exported services. Each list in the `Services` block must contain the following parameters:
The `Services` parameter contains a list of one or more parameters that specify which services to export, which namespaces the services reside, and the destination cluster for the exported services. Each item in the `Services` list must contain the following parameters:
- `Name`: Specifies the name of the service to export. You can use a asterisk wildcard (`*`) to include all services in the namespace.
- `Namespace`: Specifies the namespace containing the services to export. You can use a asterisk wildcard (`*`) to include all namespaces in the partition.
- `Consumers`: Specifies one ore more objects that identify a destination partition for the exported services.
- `Name`: Specifies the name of the service to export. You can use an asterisk wildcard (`*`) to include all services in the namespace.
- `Namespace`: <EnterpriseAlert inline /> Specifies the namespace containing the services to export. You can use an asterisk wildcard (`*`) to include all namespaces in the partition.
- `Consumers`: Specifies one or more objects that identify a destination cluster for the exported services.
## Example
### Consumers
The following example configures the agent to export the `billing` service from the `default` namespace of the `finance` admin partition to the `frontend` and `backend` partitions. Additionally, all services in all namespaces within the `finance` partition will be exported to the `monitoring` partition.
The `Consumers` parameter contains a list of one or more parameters that specify the destination cluster for
an exported service. Each item in the `Consumers` list must contain exactly one of the following parameters:
<CodeTabs heading="Example exported services configuration" tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
- `PeerName`: Specifies the name of the peered cluster to export the service to.
A asterisk wildcard (`*`) cannot be specified as the `PeerName`. Added in Consul 1.13.0.
- `Partition`: <EnterpriseAlert inline /> Specifies an admin partition in the datacenter to export the service to.
A asterisk wildcard (`*`) cannot be specified as the `Partition`.
## Examples
### Exporting services to peered clusters
<Tabs>
<Tab heading="Consul OSS">
The following example configures Consul to export the `payments` and `refunds` services to the peered `web-shop` cluster.
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
```hcl
Kind = "exported-services"
Name = "default"
Services = [
{
Name = "payments"
Consumers = [
{
PeerName = "web-shop"
},
]
},
{
Name = "refunds"
Consumers = [
{
PeerName = "web-shop"
}
]
}
]
```
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
Kind: ExportedServices
metadata:
name: default
spec:
services:
- name: payments
consumers:
- peerName: web-shop
- name: refunds
consumers:
- peerName: web-shop
```
```json
"Kind": "exported-services",
"Name": "default",
"Services": [
{
"Name": "payments",
"Consumers": [
{
"PeerName": "web-shop"
},
],
},
{
"Name": "refunds",
"Consumers": [
{
"PeerName": "web-shop"
}
]
}
]
```
</CodeTabs>
</Tab>
<Tab heading="Consul Enterprise (Peers)">
The following example configures Consul to export the `payments` and `refunds` services from the `billing` namespace of the `finance` admin partition to the `web-shop` peer.
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
```hcl
Kind = "exported-services"
@ -121,23 +312,20 @@ Name = "finance"
Services = [
{
Name = "billing"
Namespace = "default"
Name = "payments"
Namespace = "billing"
Consumers = [
{
Partition = "frontend"
PeerName = "web-shop"
},
{
Partition = "backend"
}
]
},
{
Name = "*"
Namespace = "*"
Name = "refunds"
Namespace = "billing"
Consumers = [
{
Partition = "monitoring"
PeerName = "web-shop"
}
]
}
@ -151,15 +339,14 @@ metadata:
name: finance
spec:
services:
- name: mesh-gateway
namespace: default
- name: payments
namespace: billing
consumers:
- partition: default
- name: billing
namespace: default
- peerName: web-shop
- name: refunds
namespace: billing
consumers:
- partition: frontend
- partition: backend
- peerName: web-shop
```
```json
@ -168,41 +355,327 @@ spec:
"Name": "finance",
"Services": [
{
"Name": "payments",
"Namespace": "billing"
"Consumers": [
{
"Partition": "frontend"
"PeerName": "web-shop"
},
{
"Partition": "backend"
}
],
"Name": "billing",
"Namespace": "default"
},
{
"Name": "refunds",
"Namespace": "billing",
"Consumers": [
{
"Partition": "monitoring"
"PeerName": "web-shop"
}
],
"Name": "*",
"Namespace": "*"
]
}
]
```
</CodeTabs>
</Tab>
<Tab heading="Consul Enterprise (Partitions)">
The following example configures Consul to export the `payments` and `refunds` services from the `billing` namespace of the `finance` admin partition to the `web-shop` partition.
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
```hcl
Kind = "exported-services"
Partition = "finance"
Name = "finance"
Services = [
{
Name = "payments"
Namespace = "billing"
Consumers = [
{
Partition = "web-shop"
},
]
},
{
Name = "refunds"
Namespace = "billing"
Consumers = [
{
Partition = "web-shop"
}
]
}
]
```
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
Kind: ExportedServices
metadata:
name: finance
spec:
services:
- name: payments
namespace: billing
consumers:
- partition: web-shop
- name: refunds
namespace: billing
consumers:
- partition: web-shop
```
```json
"Kind": "exported-services",
"Partition": "finance",
"Name": "finance",
"Services": [
{
"Name": "payments",
"Namespace": "billing"
"Consumers": [
{
"Partition": "web-shop"
},
],
},
{
"Name": "refunds",
"Namespace": "billing",
"Consumers": [
{
"Partition": "web-shop"
}
]
}
]
```
</CodeTabs>
</Tab>
</Tabs>
### Exporting all services
<Tabs>
<Tab heading="Consul OSS">
The following example configures Consul to export all services in the datacenter to the peered `monitoring` and `platform` clusters.
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
```hcl
Kind = "exported-services"
Name = "default"
Services = [
{
Name = "*"
Consumers = [
{
PeerName = "monitoring"
},
{
PeerName = "platform"
}
]
}
]
```
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
Kind: ExportedServices
metadata:
name: default
spec:
services:
- name: *
consumers:
- peerName: monitoring
- peerName: platform
```
```json
"Kind": "exported-services",
"Name": "default",
"Services": [
{
"Name": "*",
"Namespace": "*"
"Consumers": [
{
"PeerName": "monitoring"
},
{
"PeerName": "platform"
}
]
}
]
```
</CodeTabs>
</Tab>
<Tab heading="Consul Enterprise (Peers)">
The following example configures Consul to export all services in all namespaces of the `finance` partition to the peered `monitoring` and `platform` clusters.
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
```hcl
Kind = "exported-services"
Partition = "finance"
Name = "finance"
Services = [
{
Name = "*"
Namespace = "*"
Consumers = [
{
PeerName = "monitoring"
},
{
PeerName = "platform"
}
]
}
]
```
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
Kind: ExportedServices
metadata:
name: finance
spec:
services:
- name: *
namespace: *
consumers:
- peerName: monitoring
- peerName: platform
```
```json
"Kind": "exported-services",
"Partition": "finance",
"Name": "finance",
"Services": [
{
"Name": "*",
"Namespace": "*"
"Consumers": [
{
"PeerName": "monitoring"
},
{
"PeerName": "platform"
}
]
}
]
```
</CodeTabs>
</Tab>
<Tab heading="Consul Enterprise (Partitions)">
The following example configures Consul to export all services in all namespaces of the `finance` partition to the `monitoring` and `platform` partitions.
<CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
```hcl
Kind = "exported-services"
Partition = "finance"
Name = "finance"
Services = [
{
Name = "*"
Namespace = "*"
Consumers = [
{
Partition = "monitoring"
},
{
Partition = "platform"
}
]
}
]
```
```yaml
apiVersion: consul.hashicorp.com/v1alpha1
Kind: ExportedServices
metadata:
name: finance
spec:
services:
- name: *
namespace: *
consumers:
- partition: monitoring
- partition: platform
```
```json
"Kind": "exported-services",
"Partition": "finance",
"Name": "finance",
"Services": [
{
"Name": "*",
"Namespace": "*"
"Consumers": [
{
"Partition": "monitoring"
},
{
"Partition": "platform"
}
]
}
]
```
</CodeTabs>
</Tab>
</Tabs>
## Reading Services
When an exported service has been imported to another partition, you can use the `health` REST API endpoint to query the service on the consumer partition. The following example queries the `finance` partition for the imported `billing` service:
When an exported service has been imported to another cluster, you can use the `health` REST API endpoint to query the service on the consumer cluster.
<Tabs>
<Tab heading="Consul OSS">
The following example queries the `finance` peer for the imported `payments` service:
```shell-session
$ curl 'localhost:8500/v1/health/connect/billing?partition=finance'
$ curl 'localhost:8500/v1/health/service/payments?peer=finance'
```
</Tab>
An ACL token with `service:write` permissions is required for the partition from which the query is made. If the call in the previous example is made from a service named `web` in a partition named `frontend`, then the request will require a token with `write` permissions to `web` in the `frontend` partition.
<Tab heading="Consul Enterprise">
Exports are available to all services in the consumer partition. In the previous example, any service with `write` permissions for the `frontend` partition will be able to read exports.
The following example queries the `finance` partition for the imported `payments` service:
See [Health HTTP Endpoint](/api-docs/health) for additional information.
```shell-session
$ curl 'localhost:8500/v1/health/service/payments?partition=finance'
```
</Tab>
</Tabs>
An ACL token with `service:write` permissions is required for the cluster the query is made from. If the call in the previous example is made from a service named `web` in a partition named `frontend`, then the request requires a token with `write` permissions to `web` in the `frontend` partition.
Exports are available to all services in the consumer cluster. In the previous example, any service with `write` permissions for the `frontend` partition can read exports.
For additional information, refer to [Health HTTP Endpoint](/api-docs/health).

30
website/content/docs/connect/config-entries/service-intentions.mdx
View File

@ -446,27 +446,37 @@ spec:
},
},
{
name: 'Namespace',
enterprise: true,
type: 'string',
name: 'Peer',
type: 'string: ""',
description: {
hcl:
"The namespace of the source service. Defaults to the namespace of the destination service (i.e. the config entry's namespace)",
"Specifies the [peer](/docs/connect/cluster-peering/index.mdx) of the source service. `Peer` is mutually exclusive with `Partition`.",
yaml:
'The namespace of the source service. Defaults to the namespace of the destination service (i.e. `spec.destination.namespace`)',
"Specifies the [peer](/docs/connect/cluster-peering/index.mdx) of the source service. `peer` is mutually exclusive with `partition`.",
},
},
{
name: 'Namespace',
enterprise: true,
type: 'string: ""',
description: {
hcl:
"The namespace of the source service. If `Peer` is empty, `Namespace` defaults to the namespace of the destination service (i.e. the config entry's namespace).",
yaml:
'The namespace of the source service. If `peer` is empty, `namespace` defaults to the namespace of the destination service (i.e. `spec.destination.namespace`).',
},
},
{
name: 'Partition',
enterprise: true,
type: 'string',
type: 'string: ""',
description: {
hcl:
"Specifies the admin partition of the source service. Defaults to the destination service's partition, i.e., the configuration entry's partition",
"Specifies the admin partition of the source service. If `Peer` is empty, `Partition` defaults to the destination service's partition (i.e. the configuration entry's partition). `Partition` is mutually exclusive with `Peer`.",
yaml:
"Specifies the admin partition of the source service. Defaults to the destination service's partition, i.e. `spec.destination.partition`",
"Specifies the admin partition of the source service. If `peer` is empty, `partition` defaults to the destination service's partition (i.e. `spec.destination.partition`). `partition` is mutually exclusive with `peer`.",
},
},
},
{
name: 'Action',
type: 'string: ""',
@ -501,7 +511,7 @@ spec:
intention behavior is defined by the default [ACL policy](/docs/agent/config/config-files#acl_default_policy).<br><br>
This should be omitted for an L4 intention as it is mutually exclusive with
the \`action\` field.<br><br>
Setting \`permissions\` is not valid if a wildcard is used for the \`spec.destination.name\` or \`spec.destination.namespace\`
Setting \`permissions\` is not valid if a wildcard is used for the \`spec.destination.name\` or \`spec.destination.namespace\`
because they can only be applied to services with a compatible protocol.`,
},
},

21
website/content/docs/connect/registration/service-registration.mdx
View File

@ -35,13 +35,13 @@ port = <port where services can discover and connect to proxied services>
"destination_service_name": "<name of the service that the proxy represents>",
"<additional proxy parameters>" : "<additional parameter values>"
},
"port": <port where services can discover and connect to proxied services>
"port": <port where services can discover and connect to proxied services>
}
```
</CodeTabs>
The following table describes the parameters that must be added to the service definition to declare the service as a proxy.
The following table describes the parameters that must be added to the service definition to declare the service as a proxy.
| Parameter | Description | Required | Default |
| --- | --- | --- | --- |
@ -82,8 +82,8 @@ proxy = {
### Sidecar Proxy Configuration
Many service mesh proxies are deployed as sidecars.
Sidecar proxies are co-located with the single service instance they represent and proxy all inbound traffic to.
Many service mesh proxies are deployed as sidecars.
Sidecar proxies are co-located with the single service instance they represent and proxy all inbound traffic to.
Specify the following parameters in the `proxy` code block to configure a sidecar proxy in its own service registration:
@ -99,7 +99,7 @@ The following example includes values for all available options when registering
<CodeTabs heading="Example that includes all configuration options when registering a proxy instance">
```hcl
```hcl
kind = "connect-proxy"
name = "redis-proxy"
port = 8181
@ -166,6 +166,7 @@ You can configure the service mesh proxy to create listeners for upstream servic
| --- | --- | --- | --- |
|`destination_name` | String value that specifies the name of the service or prepared query to route the service mesh to. The prepared query should be the name or the ID of the prepared query. | Required | None |
| `destination_namespace` | String value that specifies the namespace containing the upstream service. <EnterpriseAlert inline /> | Optional | `default` |
| `destination_peer` | String value that specifies the name of the peer cluster containing the upstream service. | Optional | None |
| `destination_partition` | String value that specifies the name of the admin partition containing the upstream service. | Optional | `default` |
| `local_bind_port` | Integer value that specifies the port to bind a local listener to. The application will make outbound connections to the upstream from the local port. | Required | None |
| `local_bind_address` | String value that specifies the address to bind a local listener to. The application will make outbound connections to the upstream service from the local bind address. | Optional | `127.0.0.1` |
@ -265,7 +266,7 @@ You can configure which mode a proxy operates in by specifying `"direct"` or `"t
* `transparent`: In this mode, inbound and outbound application traffic is captured and redirected through the proxy. This mode does not enable the traffic redirection. It directs Consul to configure Envoy as if traffic is already being redirected.
* `direct`: In this mode, the proxy's listeners must be dialed directly by the local application and other proxies.
You can also specify an empty string (`""`), which configures the proxy to operate in the default mode. The default mode is inherited from parent parameters in the following order of precedence:
You can also specify an empty string (`""`), which configures the proxy to operate in the default mode. The default mode is inherited from parent parameters in the following order of precedence:
1. Proxy service's `Proxy` configuration
1. The `service-defaults` configuration for the service.
@ -294,12 +295,12 @@ registrations](/docs/discovery/services#service-definition-parameter-case).
- `outbound_listener_port` `(int: 15001)` - The port the proxy should listen on for outbound traffic.
This must be the port where outbound application traffic is captured and redirected to.
- `dialed_directly` `(bool: false)` - Determines whether this proxy instance's IP address can be dialed
directly by transparent proxies. Typically transparent proxies dial upstreams using the "virtual"
tagged address, which load balances across instances. Dialing individual instances can be helpful
in cases like stateful services such as a database cluster with a leader.
directly by transparent proxies. Transparent proxies typically dial upstreams using the "virtual"
tagged address, which load balances across instances. A database cluster with a leader is an example
where dialing individual instances can be helpful.
~> **Note:** Dynamic routing rules such as failovers and redirects do not apply to services dialed directly.
Additionally, the connection is proxied using a TCP proxy with a connection timeout of 5 seconds.
Additionally, the connection is proxied using a TCP proxy with a connection timeout of 5 seconds.
### Mesh Gateway Configuration Reference

4
website/data/api-docs-nav-data.json
View File

@ -89,6 +89,10 @@
"title": "Catalog",
"path": "catalog"
},
{
"title": "Cluster Peering",
"path": "peering"
},
{
"title": "Config",
"path": "config"

17
website/data/docs-nav-data.json
View File

@ -321,6 +321,23 @@
}
]
},
{
"title": "Cluster Peering",
"routes": [
{
"title": "What is Cluster Peering",
"path": "connect/cluster-peering"
},
{
"title": "Create and Manage Peering Connections",
"path": "connect/cluster-peering/create-manage-peering"
},
{
"title": "Cluster Peering on Kubernetes",
"path": "connect/cluster-peering/k8s"
}
]
},
{
"title": "Nomad",
"path": "connect/nomad"