Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved Service documentation #161

Merged
merged 1 commit into from
Jun 7, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 34 additions & 11 deletions docs/Manual/Deployment/Kubernetes/ServicesAndLoadBalancer.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,50 +39,53 @@ If you want to create external access services manually, follow the instructions
### Single server

For a single server deployment, the operator creates a single
`Service` named `<cluster-name>`. This service has a normal cluster IP
`Service` named `<deployment-name>`. This service has a normal cluster IP
address.

### Full cluster

For a full cluster deployment, the operator creates two `Services`.

- `<cluster-name>_servers` a headless `Service` intended to provide
- `<deployment-name>-int` a headless `Service` intended to provide
DNS names for all pods created by the operator.
It selects all ArangoDB & ArangoSync servers in the cluster.

- `<cluster-name>` a normal `Service` that selects only the coordinators
- `<deployment-name>` a normal `Service` that selects only the coordinators
of the cluster. This `Service` is configured with `ClientIP` session
affinity. This is needed for cursor requests, since they are bound to
a specific coordinator.

When the coordinators are asked to provide endpoints of the cluster
(e.g. when calling `client.SynchronizeEndpoints()` in the go driver)
the DNS names of the individual `Pods` will be returned
(`<pod>.<cluster-name>_servers.<namespace>.svc`)
(`<pod>.<deployment-name>-int.<namespace>.svc`)

### Full cluster with DC2DC

For a full cluster with datacenter replication deployment,
the same `Services` are created as for a Full cluster, with the following
additions:

- `<cluster-name>_sync` a normal `Service` that selects only the syncmasters
- `<deployment-name>-sync` a normal `Service` that selects only the syncmasters
of the cluster.

## Load balancer

To reach the ArangoDB servers from outside the Kubernetes cluster, you
have to deploy additional services.
If you want full control of the `Services` needed to access the ArangoDB deployment
from outside your Kubernetes cluster, set `spec.externalAccess.Type` of the `ArangoDeployment` to `None`
and create a `Service` as specified below.

You can use `LoadBalancer` or `NodePort` services, depending on your
Create a `Service` of type `LoadBalancer` or `NodePort`, depending on your
Kubernetes deployment.

This service should select:

- `arangodb_cluster_name: <cluster-name>`
- `arango_deployment: <deployment-name>`
- `role: coordinator`

For example:
The following example yields a service of type `LoadBalancer` with a specific
load balancer IP address.
With this service, the ArangoDB cluster can now be reached on `https://1.2.3.4:8529`.

```yaml
kind: Service
Expand All @@ -91,7 +94,27 @@ metadata:
name: arangodb-cluster-exposed
spec:
selector:
arangodb_cluster_name: arangodb-cluster
arango_deployment: arangodb-cluster
role: coordinator
type: LoadBalancer
loadBalancerIP: 1.2.3.4
ports:
- protocol: TCP
port: 8529
targetPort: 8529
```

The following example yields a service of type `NodePort` with the ArangoDB
cluster exposed on port 30529 of all nodes of the Kubernetes cluster.

```yaml
kind: Service
apiVersion: v1
metadata:
name: arangodb-cluster-exposed
spec:
selector:
arango_deployment: arangodb-cluster
role: coordinator
type: NodePort
ports:
Expand Down