Start ArangoDB on Kubernetes in 5 minutes

Starting an ArangoDB database (either single server or full blown cluster)on Kubernetes involves a lot of resources.

The servers need to run in Pods, you need Secrets for authentication,TLS certificates and Services to enable communication with the database.

Use kube-arangodb, the ArangoDB Kubernetes Operator to greatly simplifythis process.

In this guide, we will explain what the ArangoDB Kubernetes Operator is,how to install it and how use it to deploy your first ArangoDB databasein a Kubernetes cluster.

First, you obviously need a Kubernetes cluster and the right credentialsto access it. If you already have this, you can immediately skip to thenext section. Since different cloud providers differ slightly in theirKubernetes offering, we have put together detailed tutorials for thoseplatforms we officially support, follow the link for detailed setupinstructions:

What is kube-arangodb

kube-arangodb is a set of two operators that you deploy in your Kubernetescluster to (1) manage deployments of the ArangoDB database and (2)provide PersistentVolumes on local storage of your nodes for optimalstorage performance.

Note that the operator that provides PersistentVolumes is not needed torun ArangoDB deployments. You can also use PersistentVolumes providedby other controllers.

In this guide we will focus on the ArangoDeployment operator.

Installing kube-arangodb

To install kube-arangodb in your Kubernetes cluster, make sureyou have access to this cluster and the rights to deploy resourcesat cluster level.

For now, any recent Kubernetes cluster will do (e.g. minikube).

Then run (replace <version> with the version of the operator that you want to install):

  1. kubectl apply -f https://raw.githubusercontent.com/arangodb/kube-arangodb/<version>/manifests/arango-crd.yaml
  2. kubectl apply -f https://raw.githubusercontent.com/arangodb/kube-arangodb/<version>/manifests/arango-deployment.yaml
  3. # To use `ArangoLocalStorage`, also run
  4. kubectl apply -f https://raw.githubusercontent.com/arangodb/kube-arangodb/<version>/manifests/arango-storage.yaml
  5. # To use `ArangoDeploymentReplication`, also run
  6. kubectl apply -f https://raw.githubusercontent.com/arangodb/kube-arangodb/<version>/manifests/arango-deployment-replication.yaml

The first command installs two CustomResourceDefinitions in your Kubernetes cluster:

  • ArangoDeployment is the resource used to deploy ArangoDB database.
  • ArangoDeploymentReplication is the resource used to deploy ArangoDB DC2DCreplications.The second command installs a Deployment that runs the operator that controlsArangoDeployment resources.

The optional third command installs a Deployment that runs the operator thatprovides PersistentVolumes on local disks of the cluster nodes.Use this when running on bare-metal or if there is no provisioner for faststorage in your Kubernetes cluster. Furthermore, this also installs anew custom resource definition:

  • ArangoLocalStorage is the resource used to provision PersistentVolumes on local storage.The optional fourth command installs a Deployment that runs theoperator that takes care of DC2DC replications.

Deploying your first ArangoDB database

The first database we are going to deploy is a single server database.

Create a file called single-server.yaml with the following content.

  1. apiVersion: "database.arangodb.com/v1alpha"
  2. kind: "ArangoDeployment"
  3. metadata:
  4.   name: "single-server"
  5. spec:
  6.   mode: Single

Now insert this resource in your Kubernetes cluster using:

  1. kubectl apply -f single-server.yaml

The ArangoDeployment operator in kube-arangodb will now inspect theresource you just deployed and start the process to run a single server database.

To inspect the current status of your deployment, run:

  1. kubectl describe ArangoDeployment single-server
  2. # or shorter
  3. kubectl describe arango single-server

To inspect the pods created for this deployment, run:

  1. kubectl get pods --selector=arango_deployment=single-server

The result will look similar to this:

  1. NAME                                 READY     STATUS    RESTARTS   AGE
  2. single-server-sngl-cjtdxrgl-fe06f0   1/1       Running   0          1m

Once the pod reports that it is has a Running status and is ready,your database s available.

Connecting to your database

The single server database you deployed in the previous chapter is nowavailable from within the Kubernetes cluster as well as outside it.

Access to the database from outside the Kubernetes cluster is providedusing an external-access service.By default this service is of type LoadBalancer. If this type of serviceis not supported by your Kubernetes cluster, it will be replaced bya service of type NodePort after a minute.

To see the type of service that has been created, run:

  1. kubectl get service single-server-ea

When the service is of the LoadBalancer type, use the IP addresslisted in the EXTERNAL-IP column with port 8529.When the service is of the NodePort type, use the IP addressof any of the nodes of the cluster, combine with the high (>30000) port listed in the PORT(S) column.

Now you can connect your browser to https://<ip>:<port>/.

Your browser will show a warning about an unknown certificate.Accept the certificate for now.

Then login using username root and an empty password.

If you want to delete your single server ArangoDB database, just run:

  1. kubectl delete ArangoDeployment single-server

Deploying a full blown ArangoDB cluster database

The deployment of a full blown cluster is very similar to deployinga single server database. The difference is in the mode field ofthe ArangoDeployment specification.

Create a file called cluster.yaml with the following content.

  1. apiVersion: "database.arangodb.com/v1alpha"
  2. kind: "ArangoDeployment"
  3. metadata:
  4.   name: "cluster"
  5. spec:
  6.   mode: Cluster

Now insert this resource in your Kubernetes cluster using:

  1. kubectl apply -f cluster.yaml

The same commands used in the single server deployment can be usedto inspect your cluster. Just use the correct deployment name (cluster instead of single-server).

Where to go from here