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 Oasis). With many exciting features we felt kube-arango really deserves to be released as 1.0.
ArangoDB in the Cloud Native Ecosystem
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.
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).
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.
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 Oasis (using Kubernetes and Kube-ArangoDB in the background) with a two-week free trial!