status-im/consul
2
0
Fork 0
mirror of https://github.com/status-im/consul.git synced 2025-02-23 02:48:19 +00:00
Code Issues Projects Releases Wiki Activity

Proofing edits

Browse Source
This commit is contained in:
boruszak 2022-08-02 16:20:43 -05:00
parent 6c5d4df590
commit 8d676619b3
3 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
website/content/docs/connect/cluster-peering/create-manage-peering.mdx
View File

@ -61,7 +61,7 @@ Next, use the peering token to establish a secure connection between the cluster
<Tabs>
<Tab heading="Consul API">
In the client agents of "cluster-02," use `peering_token.json` to establish the peering connection. This endpoint does not generate an output unless there is an error.
In one of the client agents in "cluster-02," use `peering_token.json` to establish the peering connection. 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
@ -243,7 +243,7 @@ $ curl http://127.0.0.1:8500/v1/peering/cluster-02
### Check peering connection health
After you establish a peering connection, you can check the status of your peering connection to perform health checks.
You can check the status of your peering connection to perform health checks.
<Tabs>
<Tab heading="Consul API">
@ -264,7 +264,7 @@ A successful query includes service information in the output.
### Delete 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.
You can disconnect the peered clusters by deleting their connection. Deleting a peering connection stops data replication to the peer and deletes imported data, including services and CA certificates.
<Tabs>
<Tab heading="Consul API">

4
website/content/docs/connect/cluster-peering/index.mdx
View File

@ -38,7 +38,7 @@ Regardless of whether you connect your clusters through WAN federation or cluste
## Beta release features and constraints
The cluster peering beta adds the following features and functions:
The cluster peering beta adds the following features and functionality:
- Mesh Gateways for _service to service traffic_ between clusters are available. For more information on configuring mesh gateways across peers, refer to [Service-to-service Traffic Across Peered Clusters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers).
- You can generate peering tokens, establish, list, read, and delete peerings, and manage intentions for peering connections with both the API and the UI.
@ -51,6 +51,6 @@ Not all features and functionality are available in the beta release. In particu
- Dynamic routing features such as splits, custom routes, and redirects cannot target services in a peered cluster.
- Configuring service failover across peers is not supported for service mesh.
- Consul datacenters that are already federated stay federated. You do not need to migrate WAN federated clusters to cluster peering.
- 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).
- 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).
- Accessing key/value stores across peers is not supported.
- Non-enterprise Consul instances cannot sync services with namespaces outside of the `default` namespace.

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

@ -11,9 +11,9 @@ description: >-
with cluster peering is subject to change. You should never use the beta release in secure environments or production scenarios. Features in
beta 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.
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.
The following Custom Resource Definitions (CRDs) are used to create and manage a peering connection:
The following 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.
@ -21,10 +21,10 @@ The following Custom Resource Definitions (CRDs) are used to create and manage a
## Prerequisites
You must implement the following requirements to create and use cluster peering connections with Kubernetes:
- Consul v1.13.0 or later
- Consul version 1.13.0 or later
- At least two Kubernetes clusters
- The Kubernetes clusters must be running in a flat network
- The network must be running on Consul on Kubernetes v0.45 or later
- The network must be running on Consul on Kubernetes version 0.45 or later
### Helm chart configuration
@ -128,7 +128,7 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a
## Export services between clusters
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.
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.
<CodeBlockConfig filename="backend-service.yml">