mirrors/kube-arangodb
1
0
Fork 0
mirror of https://github.com/arangodb/kube-arangodb.git synced 2024-12-15 17:51:03 +00:00
Code Activity

Merge branch 'master' into feature/replication-status

Browse source
This commit is contained in:
Ewout Prangsma 2018-06-05 16:49:04 +02:00
commit cdd74f4374
No known key found for this signature in database
GPG key ID: 4DBAD380D93D0698
1 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
docs/Manual/Deployment/Kubernetes/DeploymentReplicationResource.md
View file

@ -187,7 +187,7 @@ add a name of a non-existing `Secret` to the `spec.sync.externalAccess.accessPac
In response, a `Secret` is created in that Kubernetes cluster, with the given name, that contains a `accessPackage.yaml` data field
that contains a Kubernetes resource specification that can be inserted into the other Kubernetes cluster.
The process for creating and using an access package to authentication at the source cluster is as follows:
The process for creating and using an access package for authentication at the source cluster is as follows:
- Edit the `ArangoDeployment` resource of the source cluster, set `spec.sync.externalAccess.accessPackageSecretNames` to `["my-access-package"]`
- Wait for the `ArangoDeployment` operator to create a `Secret` named `my-access-package`.
@ -203,5 +203,5 @@ kubectl get secret my-access-package --template='{{index .data "accessPackage.ya
kubectl apply -f accessPackage.yaml
```
As a result, the destination Kubernetes cluster will have 2 additional `Secrets`. One containing a client authentication certificate
formatted ad a keyfile. Another containing the public key of the TLS CA certificate of the source cluster.
As a result, the destination Kubernetes cluster will have 2 additional `Secrets`. One contains a client authentication certificate
formatted as a keyfile. Another contains the public key of the TLS CA certificate of the source cluster.