mirror of https://github.com/status-im/consul.git
Code Block fixes
This commit is contained in:
parent
923b7d0db6
commit
c5b5a6ee76
|
@ -9,7 +9,7 @@ description: >-
|
|||
|
||||
~> This page covers features that are currently in _technical preview_. Features and functionality are subject to change. You should never use the technical preview release in secure environments or production scenarios. Features in technical preview may face performance and scaling issues, with limited support options available.
|
||||
|
||||
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 for each side of the peering.
|
||||
|
||||
The following Custom Resource Definitions (CRDs) are used to create and manage a peering connection:
|
||||
|
||||
|
@ -40,6 +40,7 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a
|
|||
|
||||
1. In “cluster-01,” create the `PeeringAcceptor` custom resource.
|
||||
|
||||
<CodeBlockConfig filename="acceptor.yml">
|
||||
```yaml
|
||||
apiVersion: consul.hashicorp.com/v1alpha1
|
||||
kind: PeeringAcceptor
|
||||
|
@ -52,6 +53,7 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a
|
|||
key: "data"
|
||||
backend: "kubernetes"
|
||||
```
|
||||
</CodeBlockConfig>
|
||||
|
||||
1. Apply the `PeeringAcceptor` resource to the first cluster.
|
||||
|
||||
|
@ -59,7 +61,7 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a
|
|||
$ kubectl apply -f acceptor.yml
|
||||
````
|
||||
|
||||
1. Save your peering token so that you can export it to the second cluster.
|
||||
1. Save your peering token so that you can export it to the other cluster.
|
||||
|
||||
```shell-session
|
||||
$ kubectl get secret peering-token -o yaml > peering-token.yml
|
||||
|
@ -73,6 +75,7 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a
|
|||
|
||||
1. In “cluster-02,” create the `PeeringDialer` custom resource.
|
||||
|
||||
<CodeBlockConfig filename="dialer.yml">
|
||||
```yaml
|
||||
apiVersion: consul.hashicorp.com/v1alpha1
|
||||
kind: PeeringDialer
|
||||
|
@ -85,6 +88,7 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a
|
|||
key: "data"
|
||||
backend: "kubernetes"
|
||||
```
|
||||
</CodeBlockConfig>
|
||||
|
||||
1. Apply the `PeeringDialer` resource to the second cluster.
|
||||
|
||||
|
@ -96,16 +100,19 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a
|
|||
|
||||
1. For the service in “cluster-02” that you want to export, add the following [annotations to your service files](/docs/k8s/annotations-and-labels#consul-hashicorp-com-connect-service-upstreams).
|
||||
|
||||
<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
|
||||
|
@ -120,6 +127,7 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a
|
|||
|
||||
1. Create service intentions for the second cluster.
|
||||
|
||||
<CodeBlockConfig filename="intention.yml">
|
||||
```yaml
|
||||
apiVersion: consul.hashicorp.com/v1alpha1
|
||||
kind: ServiceIntentions
|
||||
|
@ -134,8 +142,9 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a
|
|||
- name: frontend-service
|
||||
action: allow
|
||||
```
|
||||
</CodeBlockConfig>
|
||||
|
||||
1. Apply the service file, the `ExportedServices` resource, and the intentions in the second cluster.
|
||||
1. Apply the service file, the `ExportedServices` resource, and the intentions to the second cluster.
|
||||
|
||||
```shell-session
|
||||
$ kubectl apply -f backend-service.yml; kubectl apply -f exportedsvc.yml; kubectl apply -f intention.yml
|
||||
|
@ -149,14 +158,16 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a
|
|||
|
||||
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.
|
||||
|
||||
|
@ -170,7 +181,7 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a
|
|||
$ curl localhost:1234
|
||||
{
|
||||
“name”: “backend-service”,
|
||||
…
|
||||
##…
|
||||
“body”: “Response from backend”,
|
||||
“code”: 200
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue