mirror of https://github.com/status-im/consul.git
Update "technical preview" to "beta"
This commit is contained in:
parent
f74d0cef7a
commit
4fcfea8be2
|
@ -7,7 +7,7 @@ description: >-
|
|||
|
||||
# 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.
|
||||
~> **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 beta 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.
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@ description: >-
|
|||
|
||||
# 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.
|
||||
~> **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 beta 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 communicate.
|
||||
|
||||
|
@ -39,7 +39,7 @@ Regardless of whether you connect your clusters through WAN federation or cluste
|
|||
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.
|
||||
- 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 be configured to use the TCP protcol (not HTTP, HTTP 2 and gRPC).
|
||||
- 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).
|
||||
|
|
|
@ -7,10 +7,9 @@ description: >-
|
|||
|
||||
# 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.
|
||||
~> **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
|
||||
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.
|
||||
|
||||
|
@ -21,11 +20,11 @@ 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:
|
||||
You must implement the following requirements to create and use cluster peering connections with Kubernetes:
|
||||
- Consul 1.13 Alpha 2 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 v.0.45 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 v.0.45 or later
|
||||
|
||||
### Helm chart configuration
|
||||
|
||||
|
@ -40,7 +39,7 @@ To establish cluster peering through Kubernetes, deploy clusters with the follow
|
|||
enabled: true
|
||||
connectInject:
|
||||
enabled: true
|
||||
controller:
|
||||
controller:
|
||||
enabled: true
|
||||
meshGateway:
|
||||
enabled: true
|
||||
|
@ -48,10 +47,10 @@ To establish cluster peering through Kubernetes, deploy clusters with the follow
|
|||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
Install Consul on Kubernetes on each Kubernetes cluster by applying `values.yaml` using the Helm CLI.
|
||||
|
||||
```shell-session
|
||||
Install Consul on Kubernetes on each Kubernetes cluster by applying `values.yaml` using the Helm CLI.
|
||||
|
||||
```shell-session
|
||||
$ export HELM_RELEASE_NAME=cluster-name
|
||||
```
|
||||
|
||||
|
|
Loading…
Reference in New Issue