Kubernetes

Memgraph can be deployed on Kubernetes. The easiest way to do that is with Helm, the package manager for Kubernetes. Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources.

Currently, we prepared and released the following charts:

• Memgraph standalone Helm chart
• Memgraph high availability Helm chart
• Memgraph Lab Helm chart

The Helm charts are published on Artifact Hub. For details on the implementation of the Helm charts, check Memgraph Helm charts repository.

Due to numerous possible use cases and deployment setups via Kubernetes, the provided Helm charts are a starting point you can modify according to your needs. This page will highlight some of the specific parts of the Helm charts that you might want to adjust.

Memgraph standalone Helm chart

Memgraph is a stateful application (database), hence the Helm chart for standalone Memgraph is configured to deploy Memgraph as a Kubernetes StatefulSet workload.

It will deploy a single Memgraph instance in a single pod.

Typically, when deploying a stateful application like Memgraph, a StatefulSet workload is used to ensure that each pod has a unique identity and stable network identity. When deploying Memgraph, it is also necessary to define a PersistentVolumeClaims to store the data directory (/var/lib/memgraph). This enables the data to be persisted even if the pod is restarted or deleted.

Storage configuration

By default, the Helm chart will create a PersistentVolumeClaim (PVC) for storage and logs. If the storage class for PVC is not defined, PVC will use the default one available in the cluster. The storage class can be configured in the values.yaml file. To avoid losing your data, make sure you have Retain reclaim policy set on your storage class. If you delete PersistentVolumeClaim without having Retain reclaim policy, you will lose your data because PersistentVolume will get deleted too. The alternative to creating a new storage class is to patch your existing storage class by applying the Retain policy. This is necessary because the default Kubernetes policy is Delete. The patching can be done using the following bash script:

#!/bin/bash
 
# Get all Persistent Volume names
PVS=$(kubectl get pv --no-headers -o custom-columns=":metadata.name")
 
# Loop through each PV and patch it
for pv in $PVS; do
  echo "Patching PV: $pv"
  kubectl patch pv $pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
done
 
echo
 
 
An example of a storage class for AWS EBS volumes: 
 
```yaml
storageClass:
  name: "gp2"
  provisioner: "kubernetes.io/aws-ebs"
  storageType: "gp2"
  fsType: "ext4"
  reclaimPolicy: "Retain"
  volumeBindingMode: "Immediate"

Default template for a storage class is part of the Helm chart and can be found in the repository. If you don’t want to create a new storage class, set storageClass.create to false.

More details on the configuration options can be found in the configuration section.

Secrets

The Helm chart allows you to use Kubernetes secrets to store Memgraph credentials. By default, the secrets are disabled. If you want to use secrets, you can enable them in the values.yaml file.

The secrets are prepared to work for environment variables MEMGRAPH_USER and MEMGRAPH_PASSWORD.

Probes

Memgraph standalone chart uses startup, readiness and liveness probes. The startup probe is used to determine when a container application has started. The liveness probe is used to determine when a container should be restarted. The readiness probe is used to determine when a container is ready to start accepting traffic. The startup probe will succeed only after the recovery of the Memgraph has finished. Liveness and readiness probes will start after the startup probe succeeds. By default, the startup probe has to succeed within 2 hours. If the recovery from backup takes longer than that, update the configuration to the value that is high enough. The liveness and readiness probe have to succeed at least once in 5 minutes for a pod to be considered ready.

System configuration

The Helm chart will set the linux kernel vm.max_map_count parameter to 262144 by default to ensure Memgraph won’t run into issues with memory mapping.

Installing Memgraph standalone Helm chart

To include a standalone Memgraph into your Kubernetes cluster, you need to add the repository and install Memgraph.

The steps below will work in the Minikube environment, but you can also use them in other Kubernetes environments with minor adjustments.

Add the repository

Add the Memgraph Helm chart repository to your local Helm setup by running the following command:

helm repo add memgraph https://memgraph.github.io/helm-charts

Make sure to update the repository to fetch the latest Helm charts available:

helm repo update

Install Memgraph

To install Memgraph Helm chart, run the following command:

helm install <release-name> memgraph/memgraph

Replace <release-name> with the name of the release you chose.

Install Memgraph standalone chart with minikube

If you are installing Memgraph standalone chart locally with minikube, we are strongly recommending to enable csi-hostpath-driver and use its storage class. Otherwise, you could have problems with attaching PVCs to pods.

1. Enable csi-hostpath-driver

minikube addons disable storage-provisioner
minikube addons disable default-storageclass
minikube addons enable volumesnapshots
minikube addons enable csi-hostpath-driver

2. Create a storage class with csi-hostpath-driver as a provider (file sc.yaml)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-hostpath-delayed
provisioner: hostpath.csi.k8s.io
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete

3. kubectl apply -f sc.yaml

4. Set storageClassName to csi-hostpath-delayed in values.yaml

Access Memgraph

Once Memgraph is installed, you can access it using the provided services and endpoints, such as various client libraries, command-line interface mgconsole or visual user interface Memgraph Lab.

Monitoring

Memgraph’s standalone chart integrates with Kubernetes monitoring tools through:

• The kube-prometheus-stack Helm chart
• Memgraph’s Prometheus exporter

The chart kube-prometheus-stack should be installed independently from HA chart with the following command:

helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
  -f kube_prometheus_stack_values.yaml \
  --namespace monitoring \
  --create-namespace

kube_prometheus_stack_values.yaml is optional. A template is available in the upstream chart’s repository. If you install the kube-prometheus-stack in a non-default namespace, allow cross-namespace scraping. You can allow this by adding the following configuration to your kube_prometheus_stack_values.yaml file:

prometheus:
  prometheusSpec:
    serviceMonitorSelectorNilUsesHelmValues: false

In order to use Memgraph’s Prometheus exporter and ServiceMonitor make sure to update values.yaml configuration file:

prometheus:
  enabled: true
  namespace: monitoring
  memgraphExporter:
    port: 9115
    pullFrequencySeconds: 5
    repository: memgraph/mg-exporter
    tag: 0.2.1
  serviceMonitor:
    kubePrometheusStackReleaseName: kube-prometheus-stack
    interval: 15s

If you set prometheus.enabled to false, resources from charts/memgraph/templates/mg-exporter.yaml will still be installed into the monitoring namespace. Refer to the configuration table later in the document for details on all parameters.

To uninstall kube-prometheus-stack, run:

helm uninstall kube-prometheus-stack --namespace monitoring

NOTE: The stack’s CRDs are not deleted automatically and must be removed manually:

kubectl delete crd alertmanagerconfigs.monitoring.coreos.com
kubectl delete crd alertmanagers.monitoring.coreos.com
kubectl delete crd podmonitors.monitoring.coreos.com
kubectl delete crd probes.monitoring.coreos.com
kubectl delete crd prometheusagents.monitoring.coreos.com
kubectl delete crd prometheuses.monitoring.coreos.com
kubectl delete crd prometheusrules.monitoring.coreos.com
kubectl delete crd scrapeconfigs.monitoring.coreos.com
kubectl delete crd servicemonitors.monitoring.coreos.com
kubectl delete crd thanosrulers.monitoring.coreos.com

Configuration options

The following table lists the configurable parameters of the Memgraph HA chart and their default values.

For the data and coordinators sections, each item in the list has the following parameters:

The args section contains a list of arguments for the instance.

For all available database settings, refer to the configuration settings docs.

Memgraph high availability Helm chart

Please continue on our Memgraph high availability Helm chart setup.

Memgraph Lab Helm chart

A Helm chart for deploying Memgraph Lab on Kubernetes.

Installing the Memgraph Lab Helm chart

To install the Memgraph Lab Helm chart, follow the steps below:

helm install <release-name> memgraph/memgraph-lab

Replace <release-name> with a name of your choice for the release.

Changing the default chart values

To change the default chart values, run the command with the specified set of flags:

helm install <resource-name> memgraph/memgraph-lab --set <flag1>=<value1>,<flag2>=<value2>,...

Or you can modify a values.yaml file and override the desired values:

helm install <resource-name> memgraph/memgraph-lab -f values.yaml

Configuration options

The following table lists the configurable parameters of the Memgraph Lab chart and their default values.

Memgraph Lab can be further configured with environment variables in your values.yaml file.

env:
  - name: QUICK_CONNECT_MG_HOST
    value: memgraph
  - name: QUICK_CONNECT_MG_PORT
    value: "7687"
  - name: KEEP_ALIVE_TIMEOUT_MS
    value: 65000

In case you added Nginx Ingress service or web server for a reverse proxy, update the following proxy timeout annotations to avoid potential timeouts:

proxy_read_timeout X;
proxy_connect_timeout X;
proxy_send_timeout X;

where X is the number of seconds the connection (request query) can be alive. Additionally, update the Memgraph Lab KEEP_ALIVE_TIMEOUT_MS environment variable to a higher value to ensure that Memgraph Lab stays connected to Memgraph when running queries over 65 seconds.

Refer to the Memgraph Lab documentation for details on how to configure Memgraph Lab.

kube