Skip to content 
Deploying ArangoDB on Kubernetes and customizing settings
Estimated reading time: 6 minutes
Introduction
Deploying an ArangoDB cluster on Kubernetes is a straightforward process thanks to the ArangoDB Operator, a powerful tool that simplifies the deployment, management, and scaling of ArangoDB clusters in a Kubernetes environment.
In this post, we’ll walk you through the steps to quickly deploy an ArangoDB cluster on Kubernetes, covering what the main components are and how to customize settings to ensure the cluster runs optimally for your needs.
The deployment steps will be followed considering that there is already a kubernetes set up and the user executing the commands has administrator privileges.
For this demonstration we will be using:
- Arangodb 3.12.4 image
- Kubernetes Server version 1.27.16
- ArangoDB Operator 1.2.46
Executing the installation steps
An ArangoDB Cluster has three main components which are the Agents, Coordinators and DB Servers, but in a Kubernetes environment these components are created as pods along with the operator pods. Therefore, the installation steps will be based on configuring yaml files and creating pods using the "kubectl" utility, as described below:
Installing the operator
kubectl apply -f $URLPREFIX/arango-crd.yaml
To use ArangoLocalStorage resources to provision Persistent Volumes on local storage, also run:
kubectl apply -f $URLPREFIX/arango-storage.yaml
kubectl apply -f $URLPREFIX/arango-storage.yaml
Confirm that the pods were created successfully
kubectl apply -f $URLPREFIX/arango-storage.yaml
kubectl apply -f $URLPREFIX/arango-storage.yaml
Storage Configuration
Create the file storage.yaml with the content below
kubectl apply -f $URLPREFIX/arango-storage.yaml
kubectl apply -f $URLPREFIX/arango-storage.yaml
Confirm that the pods were created successfully
kubectl apply -f $URLPREFIX/arango-storage.yaml
kubectl apply -f $URLPREFIX/arango-storage.yaml
ArangoDB deployment creation
After deploying the latest ArangoDB Kubernetes operator and configuring storage resources, we will create the ArangoDB database deployment itself by creating an ArangoDeployment custom resource and deploying it into our Kubernetes.
We will create a basic yaml file cluster-deployment.yaml with the content below
kubectl apply -f $URLPREFIX/arango-storage.yaml
kubectl apply -f $URLPREFIX/arango-storage.yaml
Wait for few minutes and we will find all the components pods running (3 for each of them) when confirming that the pods were created successfully. We have a working ArangoDB cluster running on kubernetes and ready to be used.
kubectl apply -f $URLPREFIX/arango-storage.yaml
kubectl apply -f $URLPREFIX/arango-storage.yaml
Customizing settings
As we showed in the previous steps, we used a basic yaml file to create the ArangoDB database deployment, it means that most settings will be the default, this is fine and may work for multiple users, but we may need to customize some settings regarding how resources are allocated or even some database parameters to support specific needs that are particular to each environment, user or application using Arangodb.
In our “cluster-deployment.yaml” we did not specify any resource limit for any of the components (agents, coordinators, DBServers), that means for example that the coordinators could use the whole memory available on the Kubernetes machine (in our case 32GB), which is something that we don’t want. The coordinator log section below highlights the statement above, we see a message that confirms the whole machine memory is available for the coordinators utilization.
In order to limit the amount of resources available for the coordinators, we modify the Arango deployment using the command “kubectl edit” to include the lines below right after the coordinators section start in the yaml configuration.
kubectl apply -f $URLPREFIX/arango-storage.yaml
kubectl apply -f $URLPREFIX/arango-storage.yaml
Each of the coordinators pods will be terminated and then started as we can see below
After having all the coordinators restarted, we look at the coordinator log again and we can see the amount of memory available for the coordinators is now only 512MB, as we specified in the deployment yaml file. The same approach can be followed for the Agents and DBServers.
Now let’s change an ArangoDB Server option, the idea is quite similar to the resource limit change we have done previously, we will need to edit the deployment yaml using the command “kubectl edit” and include the option we want to modify under the corresponding section.
For our example, we are going to enable the experimental vector index feature , available as of 3.12.4 version, by setting “--experimental-vector-index” to true, this needs to be placed under both the coordinators and dbservers sections, by including the reserved word “args” as shown below:
After saving the changes, the coordinators and dbservers pods will restart again, then we can connect to any of the coordinators to confirm that “--experimental-vector-index” is really set to true.
There we go! The experimental vector index feature was successfully enabled, by the way, you can find more information about this feature on this blog post.
Conclusion
Deploying an ArangoDB cluster on Kubernetes is a quick and efficient process, offering significant flexibility to meet the specific requirements of multiple applications. The ability to adjust resources and fine-tune ArangoDB server options ensures that your setup can be tailored to fit various business needs, performance goals, and infrastructure capabilities. Customization is relevant for maintaining optimal performance and scalability, allowing your system to evolve in line with changing demands. Associating Kubernetes and ArangoDB, you're not only simplifying deployment, but also gaining a powerful solution that adapts seamlessly to your needs.
Integrating ArangoDB with Kubernetes for Seamless Deployment
Estimated reading time: 6 minutes
Are you a database architect or DevOps architect tasked with deploying modern databases like ArangoDB on Kubernetes? Kubernetes, with its robust orchestration capabilities, provides a solid foundation for managing containerized workloads, ensuring reliability and adaptability for database deployments.
In this post, we’ll guide you through the process of deploying ArangoDB on Kubernetes, addressing common DevOps challenges like scalability, high availability, and efficient resource utilization. By the end, you'll have a practical understanding of integrating ArangoDB with Kubernetes in a way that’s both robust and future-proof.
Why ArangoDB and Kubernetes?
ArangoDB, as a multi-model database, excels at handling diverse workloads—be it document, graph, or key-value data. When paired with Kubernetes, you gain:
- Scalability: Automatically adjust resources to meet demand.
- Resilience: Ensure high availability through self-healing capabilities.
- Simplicity: Streamline deployment and updates with Infrastructure as Code (IaC).
- Automation: Minimize manual intervention with Kubernetes' built-in orchestration.
Prerequisites
Before diving into deployment, ensure you have the following ready:
- A Kubernetes Cluster: Local (e.g., Minikube) or cloud-based (e.g., AWS EKS, GKE).
- kubectl: Installed and configured to interact with your cluster.
- Helm: Installed for managing Kubernetes charts.
Step 1: Installing the ArangoDB Kubernetes Operator
The ArangoDB Kubernetes Operator simplifies the deployment and management of ArangoDB clusters. It automates tasks like scaling, failover, and configuration management.
Add the Helm Repository
Start by adding the ArangoDB Helm repository:
bash
helm repo update
Deploy the Operator
Install the ArangoDB operator in a dedicated namespace:
bash
This deploys the operator, which manages the lifecycle of your ArangoDB cluster.
Step 2: Configuring and Deploying an ArangoDB Cluster
Create the Cluster Configuration
Write a configuration file ( e.g., arangodb-cluster.yaml ) to define your cluster. This configuration outlines the desired topology, resource allocation, and environment settings.
Yaml
kind: ArangoDeployment
metadata:
name: arango-cluster
namespace: arangodb
spec:
mode: Cluster
environment: Production
image:
repository: arangodb/arangodb
tag: latest
tls:
mode: None
authentication:
jwtSecretName: arango-cluster-jwt
agents:
count: 3
resources:
requests:
memory: 1Gi
cpu: 500m
dbservers:
count: 3
resources:
requests:
memory: 2Gi
cpu: 500m
coordinators:
count: 2
resources:
requests:
memory: 1Gi
cpu: 500m
Apply the Configuration
Deploy your cluster by applying the YAML file:
bash
Verify the deployment status:
bash
Step 3: Addressing DevOps Concerns
Scalability
Kubernetes' horizontal scaling ensures that your ArangoDB cluster can handle fluctuating workloads:
bash
High Availability
With ArangoDB's fault-tolerant architecture and Kubernetes' self-healing, you minimize downtime. For example, Kubernetes automatically restarts failed pods:
bash
Backup and Recovery
Set up a backup strategy using Kubernetes CronJobs:
yaml
kind: CronJob
metadata:
name: arango-backup
namespace: arangodb
spec:
schedule: "0 2 * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: arango-backup
image: arangodb/arangodb
command: ["arangodump"]
args:
- "--output-directory=/backups"
- "--server.database=mydb"
restartPolicy: OnFailure
Step 4: Monitoring and Maintenance
Use Kubernetes-native tools like Prometheus and Grafana to monitor your ArangoDB deployment. Enable metrics collection by annotating your pods:
yaml
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "8529"
Summary
Integrating ArangoDB with Kubernetes offers an elegant solution for managing complex database workloads. By leveraging Kubernetes' orchestration capabilities, you can ensure your database is scalable, resilient, and easy to manage. Whether you're a seasoned DevOps professional or new to container orchestration, this setup will provide a reliable foundation for your ArangoDB deployment.
Happy deploying!
Red Hat Certifies ArangoDB Kubernetes Operator
Estimated reading time: 2 minutes
Hi all!
I think this year has thrown us for quite a loop, full of unexpected occurrences, both joyous and difficult. With everything going on in the world at the moment, we feel it’s more important than ever to celebrate what you can .
So with that, just a quick note from us that our Kubernetes Operator has achieved Red Hat OpenShift Operator Certification. And as far as we can tell, this means we are the first graph database to reach full certification for Red Hat OpenShift. Huzzah!
(more…)