---
title: "Create an Aerospike cluster on Kubernetes with a non-root user"
description: "Deploy a secure Aerospike cluster on Kubernetes using non-root users and configuring CRI runtimes."
---

# Create an Aerospike cluster on Kubernetes with a non-root user

> For the complete documentation index see: [llms.txt](https://aerospike.com/docs/llms.txt)
> 
> All documentation pages available in markdown.

To deploy a non-root Aerospike cluster with AKO, create an Aerospike CR file that describes the cluster. At minimum, include the cluster size, Aerospike configuration, and system resources. Then use `kubectl` to apply the CR file to your Kubernetes cluster.

## Requirements

### Configure CRI container runtimes (containerd, CRI-O)

For non-root containers to use devices, cluster administrators must opt in to the functionality by setting `device_ownership_from_security_context = true` on each worker node. The flag is available in CRI-O v1.22 release and containerd v1.6.6 and later. For more details, see [Non-root containers and devices](https://kubernetes.io/blog/2021/11/09/non-root-containers-and-devices/).

For containerd, set:

```yaml
[plugins]

  [plugins."io.containerd.grpc.v1.cri"]

  device_ownership_from_security_context = true
```

For CRI-O, set:

```yaml
[crio.runtime]

  device_ownership_from_security_context = true
```

Restart the container runtime service:

Terminal window

```shell
sudo systemctl restart containerd

# or

sudo systemctl restart crio
```

Verify that `device_ownership_from_security_context = true` is set:

Terminal window

```shell
sudo crictl info
```

```text
...

"disableHugetlbController": true,

"device_ownership_from_security_context": true,

"ignoreImageDefinedVolumes": false,

"netnsMountsUnderStateDir": false,

...
```

### Install Aerospike Kubernetes Operator

Before deploying your Aerospike cluster, install Aerospike Kubernetes Operator on your Kubernetes cluster by using either:

-   [OLM](https://aerospike.com/docs/kubernetes/4.4.x/install/olm)
-   [Helm](https://aerospike.com/docs/kubernetes/4.4.x/install/helm)

### Prepare the namespace, storage and secrets

Before creating your Aerospike cluster CR, create the required namespace, storage and secrets using either:

-   [OLM](https://aerospike.com/docs/kubernetes/4.4.x/install/deploy/kubectl)
-   [Helm](https://aerospike.com/docs/kubernetes/4.4.x/install/deploy/helm)

## Create Aerospike Cluster CR

See the [cluster configuration settings](https://aerospike.com/docs/kubernetes/4.4.x/reference/config-reference) for details on the Aerospike cluster CR file. You can find sample CR files for different configurations in [the main Aerospike Kubernetes Operator repository](https://github.com/aerospike/aerospike-kubernetes-operator/tree/v4.4.1/config/samples).

Edit the CR file to add a `securityContext` section under `podSpec`.

```yaml
...

  podSpec:

    multiPodPerHost: true

    securityContext:

      runAsUser: 1001

      runAsGroup: 1001

      fsGroup: 1001

...
```

## Deploy the Aerospike Cluster

Use `kubectl apply` to apply the CR file you created and deploy the Aerospike cluster.

Terminal window

```shell
kubectl apply -f config/samples/ssd_storage_cluster_cr.yaml
```

## Verify cluster status

Use `kubectl get statefulset` to ensure AKO creates the StatefulSets for the cluster defined in the CR file.

Terminal window

```shell
kubectl get statefulset -n aerospike

NAME      READY   AGE

aerocluster-0   2/2     24s
```

Use `kubectl get pods` to check the pods to confirm the status. This step may take time as the pods provision resources, initialize, and become ready. Wait for the pods to switch to the Running state before you continue.

Terminal window

```shell
kubectl get pods -n aerospike

NAME          READY   STATUS      RESTARTS   AGE

aerocluster-0-0     1/1     Running     0          48s

aerocluster-0-1     1/1     Running     0          48s
```

To verify the results, check the user and group ID that the container runs as. They should be set to non-zero values as configured in the `securityContext` section in the CR file.

Terminal window

```shell
kubectl exec -it aerocluster-0-0 -c aerospike-server -n aerospike -- id

uid=1001 gid=1001 groups=1001
```

Next, check that the device node permissions are accessible to `runAsUser` and `runAsGroup`:

Terminal window

```bash
kubectl exec -it aerocluster-0-0 -c aerospike-server -n aerospike -- ls -la /test/dev           # Block device path /test/dev/xvdf

total 8

drwxr-xr-x 2 root root 4096 Sep 29 18:30 .

drwxr-xr-x 3 root root 4096 Sep 29 18:30 ..

brw-rw---- 1 1001 1001 8, 64 Sep 29 18:30 xvdf
```

If the Aerospike cluster pods do not switch to Running status in a few minutes, refer to the [Troubleshooting Guide](https://aerospike.com/docs/kubernetes/4.4.x/reference/troubleshooting).