Create an Aerospike Cluster

To use the Operator to deploy an Aerospike cluster, create an Aerospike custom resource (CR) file which describes the cluster (including its number of nodes, the Aerospike configuration, system resources, etc.). Then use kubectl to apply that configuration file to your Kubernetes cluster(s).

Requirements

Before deploying your Aerospike cluster, you must install the Aerospike Kubernetes Operator on your Kubernetes cluster(s) using either:

• OLM
• Helm

Prepare the namespace

We recommend not using the Aerospike Kubernetes Operator's namespace for your clusters. We recommend using at least one namespace called aerospike for Aerospike clusters.

If this is the first cluster being launched, you need to create and provide access for the Operator to use this namespace. You can skip these instructions if you have already done this.

note

For Kubernetes 1.23 version or later, Pod Security Admission (PSA) is enabled by default. Make sure the namespace where the Aerospike Cluster is deployed has either baseline or privileged Pod Security Standard level set. The restricted level is not supported by Aerospike. The default Pod Security Standard level in Kubernetes 1.23 is privileged. For more details, see Apply Pod Security Standards

The procedure to use the namespace aerospike is as follows:

Create the namespace

Create the Kubernetes namespace if not already created:

kubectl create namespace aerospike

Create a service account

kubectl -n aerospike create serviceaccount aerospike-operator-controller-manager

Update the operator's ClusterRoleBinding

Next, add this service account to the Operator's ClusterRoleBinding. To do this, run the following command:

kubectl edit clusterrolebindings.rbac.authorization.k8s.io $(kubectl get clusterrolebindings.rbac.authorization.k8s.io  | grep aerospike-kubernetes-operator | grep -v -- "-opera-" | grep -v -- "default-ns" | cut -f 1 -d " ")

This command launches an editor. Append the following lines to the subjects section:

  # A new entry for aerospike.
  # Replace aerospike with your namespace
- kind: ServiceAccount
  name: aerospike-operator-controller-manager
  namespace: aerospike

Save and ensure that the changes are applied.

Here is a full example of the Operator's ClusterRoleBinding targeting the aerospike namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: "2022-06-16T10:48:36Z"
  labels:
    olm.owner: aerospike-kubernetes-operator.v2.2.1
    olm.owner.kind: ClusterServiceVersion
    olm.owner.namespace: test
    operators.coreos.com/aerospike-kubernetes-operator.test: ""
  name: aerospike-kubernetes-operator.v2.2.1-74b946466d
  resourceVersion: "51841234"
  uid: be546dd5-b21e-4cc3-8a07-e2fe5fe5274c
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: aerospike-kubernetes-operator.v2.2.1-74b946466d
subjects:
  - kind: ServiceAccount
    name: aerospike-operator-controller-manager
    namespace: operators

  # New entry
  - kind: ServiceAccount
    name: aerospike-operator-controller-manager
    namespace: aerospike

OpenShift Cluster Considerations

OpenShift Security Context Constraints (SCC)

On OpenShift clusters, administrators can use security context constraints (SCCs) to control permissions for pods. These permissions control which actions a pod can perform, and which resources it can access. You can use SCCs to define a set of conditions that a pod must run with, in order to be accepted into the system. See OpenShift SC Guide for details. In order to run Aerospike Enterprise Server clusters on OpenShift, the Aerospike pods need to be granted access to some of the SCC on clusters

SCC anyuid (required)

Aerospike Enterprise Server images are designed to run as some non-root (any) UID. On OpenShift this requires Aerospike Pods to be allowed to run with any UID requiring anyuid SCC.

This SCC should be granted to the Operator's service account for the aerospike namespace using the following command:

oc adm policy add-scc-to-user anyuid system:serviceaccount:aerospike:aerospike-operator-controller-manager

SCC hostnetwork (optional)

This SCC allows using host networking and host ports.

This SCC should be granted to the Operator's service account for the aerospike namespace using the following command:

oc adm policy add-scc-to-user hostnetwork system:serviceaccount:aerospike:aerospike-operator-controller-manager

SCC privileged (optional)

This SCC allows access to all privileged and host features and the ability to run as any user, any group, any FSGroup, and with any SELinux context. For example, this is required to run Index on Flash storage configuration with Aerospike primary index stored on SSD devices.

This SCC should be granted to the Operator's service account for the aerospike namespace using the following command:

oc adm policy add-scc-to-user privileged system:serviceaccount:aerospike:aerospike-operator-controller-manager

Prepare the Aerospike Cluster Configuration

The Aerospike Kubernetes Operator GitHub repo contains example YAML configuration files for the cluster deployment. These files are located in the main Aerospike Kubernetes Operator repository.

The use case for your cluster will help you determine which configuration parameters you need to set in the custom resource (CR) file.

Configure Persistent Storage

The Aerospike Operator is designed to work with dynamically-provisioned storage classes. Aerospike Server pods may have different storage volumes associated with each service.

Persistent storage on the pods uses these storage class provisioners.

Apply a sample storage class based on your Kubernetes environment:

• EKS: kubectl apply -f eks_ssd_storage_class.yaml
• GCE: kubectl apply -f gce_ssd_storage_class.yaml
• Microk8s: kubectl apply -f microk8s_filesystem_storage_class.yaml

See Storage Provisioning for more details on configuring persistent storage.

Create Secrets

Next, create Secrets to set up features like the license file (features.conf), Aerospike authentication, TLS, and the cluster admin password. See the Manage TLS Certificates section for more details.

The example Secrets directory includes a collection of example TLS certificates, security credentials, and more. Download these files into a local folder called secrets, then apply them as a Kubernetes Secret:

kubectl  -n aerospike create secret generic aerospike-secret --from-file=secrets

Create a Secret containing the password for the Aerospike cluster admin:

kubectl  -n aerospike create secret generic auth-secret --from-literal=password='admin123'

Create Aerospike Cluster Custom Resource (CR)

Refer to the cluster configuration settings for details on the Aerospike cluster custom resource (CR) file. You can find sample Aerospike cluster CR files for different configurations in the main Aerospike Kubernetes Operator repository.

You can edit the CR file at any time to make changes and manage the Aerospike cluster.

Deploy the Aerospike Cluster

Use the custom resource YAML file you created to deploy an Aerospike cluster. If you don't have a custom resource file, you can choose one of the sample files in the main Aerospike Kubernetes Operator repository.

For example, to use the dim_nostorage_cluster_cr.yaml file, download it and apply it to your cluster with:

kubectl apply -f dim_nostorage_cluster_cr.yaml

Verify Cluster Status

Use kubectl get statefulset to ensure the aerospike-kubernetes-operator creates the StatefulSets for the custom resource.

Output:

$ 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 are ready. Wait for the pods to switch to the Running state before you continue.

Output:

$ 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

If the Aerospike cluster pods do not switch to Running status in a few minutes, refer to the Troubleshooting Guide.