Services and load balancer

The ArangoDB Kubernetes Operator will create services that can be used toreach the ArangoDB servers from inside the Kubernetes cluster.

By default, the ArangoDB Kubernetes Operator will also create an additionalservice to reach the ArangoDB deployment from outside the Kubernetes cluster.

For exposing the ArangoDB deployment to the outside, there are 2 options:

• Using a NodePort service. This will expose the deployment on a specific port (above 30.000)on all nodes of the Kubernetes cluster.
• Using a LoadBalancer service. This will expose the deployment on a load-balancerthat is provisioned by the Kubernetes cluster.

The LoadBalancer option is the most convenient, but not all Kubernetes clustersare able to provision a load-balancer. Therefore we offer a third (and default) option: Auto.In this option, the ArangoDB Kubernetes Operator tries to create a LoadBalancerservice. It then waits for up to a minute for the Kubernetes cluster to provisiona load-balancer for it. If that has not happened after a minute, the serviceis replaced by a service of type NodePort.

To inspect the created service, run:

kubectl get services <deployment-name>-ea

To use the ArangoDB servers from outside the Kubernetes clusteryou have to add another service as explained below.

Services

If you do not want the ArangoDB Kubernetes Operator to create an external-accessservice for you, set spec.externalAccess.Type to None.

If you want to create external access services manually, follow the instructions below.

Single server

For a single server deployment, the operator creates a singleService named <deployment-name>. This service has a normal cluster IPaddress.

Full cluster

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

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

• <deployment-name> a normal Service that selects only the Coordinatorsof the cluster. This Service is configured with ClientIP sessionaffinity. This is needed for cursor requests, since they are bound toa 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>.<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 followingadditions:

• <deployment-name>-sync a normal Service that selects only the syncmastersof the cluster.

Load balancer

If you want full control of the Services needed to access the ArangoDB deploymentfrom outside your Kubernetes cluster, set spec.externalAccess.type of the ArangoDeployment to Noneand create a Service as specified below.

Create a Service of type LoadBalancer or NodePort, depending on yourKubernetes deployment.

This service should select:

• arango_deployment: <deployment-name>
• role: coordinator

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

kind: Service
apiVersion: v1
metadata:
  name: arangodb-cluster-exposed
spec:
  selector:
    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 ArangoDBcluster exposed on port 30529 of all nodes of the Kubernetes cluster.

kind: Service
apiVersion: v1
metadata:
  name: arangodb-cluster-exposed
spec:
  selector:
    arango_deployment: arangodb-cluster
    role: coordinator
  type: NodePort
  ports:
  - protocol: TCP
    port: 8529
    targetPort: 8529
    nodePort: 30529