home shape

Celebrating Kube-ArangoDB’s 1.0 Release!

Estimated reading time: 4 minutes

Kube-ArangoDB, ArangoDB’s Kubernetes Operator first released two years ago and as of today is operating many ArangoDB production clusters (including ArangoDB’s Managed Service ArangoGraph). With many exciting features we felt kube-arango really deserves to be released as 1.0.

ArangoDB in the Cloud Native Ecosystem

ArangoDB and Kubernetes

You might wonder why is a Kubernetes operator such a big deal for a database? First of all more and more of our users are deploying ArangoDB on Kubernetes. There seem to be two main drivers for this development: First of all, Kubernetes is becoming an abstraction layer for many companies, allowing them to operate their applications the same way irrespective of the underlying infrastructure.

Secondly, running any stateful application is still a complex task especially in a container-based environment, because of the storage requirements and potentially other requirements such as static network addresses. Running a database on Kubernetes combines all the challenges of running a stateful application, combined with a quest for optimal performance.


This is why we developed kube-arangodb our Kubernetes Operator.
A Kubernetes Operator aims at solving the above deployment and operational challenges in two ways:

First, the Kubernetes API allows us to define Custom Resources and hence allow users to interact with those new resources in Kubernetes-native ways. In case of Kube-ArangoDB, this means, for example, one uses the ArangoDeployment custom resources (amongst others) and view the ArangoDB clusters by simply

`kubectl get ArangoDeployment`

Furthermore, we can use yaml files to describe and version our resource definitions in Kubernetes-style. Consider for example:

`kubectl apply -f simple-cluster.yaml`

The second magic ingredient of a Kubernetes Operator is the Controller.

One can imagine a controller as an endless loop trying to achieve or reconcile the desired (e.g., four ArangoDB database servers) with the current state (e.g., only three ArangoDB database servers as one node in the Kubernetes cluster has failed).

ArangoDB Kubernetes Operator 1.0

Combining these two patterns an operator can mimic a human operator managing a service.

The operational knowledge of such a human operator including for example

  • upgrading a cluster
  • recovering from various failures
  • or changing configuration can be encoded in the operator and hence made easily accessible via the Kubernetes API.

So deploying a fully functional ArangoDB cluster with TLS can be as simple as `kubectl apply` or
`helm install`. And the magic continues: Kube-ArangoDB will maintain the cluster in desired state by for example restarting pods after failure. Furthermore, Kube-ArangoDB simplifies upgrading your ArangoDB cluster to a single command.

Kube-ArangoDB 1.0

What makes Kube-ArangoDB 1.0 worthy? First of all, there is a large number of users using it in production for the past two years and we have arrived at a stable feature set and API.

Furthermore, the Kubernetes Team at ArangoDB has added a number of cool features which really deserve a 1.0 release!

  • With Azure AKS and OpenShift support Kube-ArangoDB now supports all major Kubernetes cloud offerings
  • Improved Security – pods have totally restricted access, secured container context aligning with kubernetes security recommendations
  • Full automation of ArangoDB lifecycle – all aspects of cluster operations are automated, including Hotbackup and Datacenter to Datacenter replication and rolling upgrades

One further proof of the maturity of Kube-ArangoDB is the availability as a RedHat certified Operator for OpenShift.

How to get started?

So how can you get started and deploy your first cluster with Kube-ArangoDB?

Our documentation is a great starting point.

In case you don’t want to deal with Kubernetes or Kube-ArangoDB directly but still would like to get easy access to an ArangoDB cluster, feel free to try our managed service ArangoGraph(using Kubernetes and Kube-ArangoDB in the background) with a two-week free trial!

Hear More from the Author

The case for a common Metadata Layer for Machine Learning by Jörg Schad

The Case for Metadata for Machine Learning Platforms | ArangoDB

Continue Reading

An Introduction to Geo Indexes and their performance characteristics: Part II

ArangoJS 6.0.0 released: Load Balancing, Automated Failover and completely written in TypeScript

Present and Future of ArangoDB Fulltext Index

Joerg Schad

Joerg Schad

Jörg Schad is our CTO. In a previous life, he worked on Machine Learning Infrastructure in health care, distributed systems at Mesosphere, implemented distributed and in-memory databases, and conducted research in the Hadoop and Cloud area. He’s a frequent speaker at meetups, international conferences, and lecture halls.

Leave a Comment

Get the latest tutorials, blog posts and news: