Use kubectl to Create an Aerospike Cluster on Kubernetes
To use the Operator to deploy an Aerospike cluster, create an Aerospike custom resource (CR) file with the cluster parameters (including the number of nodes, Aerospike configuration, system resources, etc.).
Then use kubectl
to apply that configuration file to your Kubernetes cluster(s).
The Aerospike Kubernetes Operator can deploy multiple Aerospike clusters within a single Kubernetes namespace, or in multiple namespaces.
Requirementsโ
Before deploying your Aerospike cluster, install the Aerospike Kubernetes Operator on your Kubernetes cluster(s) using either:
1. Prepare the namespaceโ
We recommend not using the Aerospike Kubernetes Operator's namespace for your clusters.
Instead, use at least one namespace called aerospike
for Aerospike clusters.
If this is the first cluster being launched, create and provide access for the Operator to use this namespace.
For Kubernetes 1.23 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
There are two ways to grant permission for the target namespaces:
Using kubectlโ
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
Create RoleBinding/ClusterRoleBinding for Aerospike clusterโ
Next, create a RoleBinding or ClusterRoleBinding as per requirement to attach this service account to ClusterRole aerospike-cluster
.
This ClusterRole is created as part of AKO installation and grants Aerospike cluster permission to service account.
- For using Kubernetes native Pod only network to connect to Aerospike cluster create RoleBinding:
kubectl -n aerospike create rolebinding aerospike-cluster --clusterrole=aerospike-cluster --serviceaccount=aerospike:aerospike-operator-controller-manager
- For connecting to Aerospike cluster from outside Kubernetes create ClusterRoleBinding:
kubectl create clusterrolebinding aerospike-cluster --clusterrole=aerospike-cluster --serviceaccount=aerospike:aerospike-operator-controller-manager
For attaching multiple service accounts of different namespaces in one go, add multiple --serviceaccount
params in above command
Example: To attach service accounts of aerospike and aerospike1 namespace
kubectl create clusterrolebinding aerospike-cluster --clusterrole=aerospike-cluster --serviceaccount=aerospike:aerospike-operator-controller-manager --serviceaccount=aerospike1:aerospike-operator-controller-manager
If the required ClusterRoleBinding already exists in cluster, edit it to attach new service account:
kubectl edit clusterrolebinding aerospike-cluster
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.
Using akoctl pluginโ
For instructions on installing the akoctl
plugin, refer to akoctl installation.
The procedure to use the namespace aerospike
is as follows:
- For using Kubernetes native Pod only network to connect to Aerospike cluster grant namespace scope permission:
kubectl akoctl auth create -n aerospike --cluster-scope=false
- For connecting to Aerospike cluster from outside Kubernetes grant cluster scope permission:
kubectl akoctl auth create -n aerospike
For granting permission of multiple namespaces in one go, specify comma separated namespace list in -n
param
Example: To grant permission for aerospike and aerospike1 namespace
kubectl akoctl auth create -n aerospike,aerospike1
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 Database 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 AKO'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
2. Prepare the Aerospike cluster configurationโ
The Aerospike Kubernetes Operator GitHub repository contains example YAML CR 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 CR file.
3. Configure persistent storageโ
The Aerospike Operator works with dynamically-provisioned storage classes. Aerospike server pods may have different storage volumes associated with each service.
Persistent storage on the pods support a variety of storage class provisioners.
Aerospike provides sample storage class files in the GitHub repository available for download here: Sample storage classes These files must be present on the server. Apply one of the following sample storage classes 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
These file paths assume that you are running commands from the folder containing the files. If not, replace the file name with the full path to the sample file.
See Storage Provisioning for more details on configuring persistent storage.
4. Create secretsโ
Create secrets to set up features like the feature-key file (features.conf
), Aerospike authentication, TLS, and the cluster admin password.
See the Manage TLS Certificates section for more details.
The example secrets directory on GitHub includes a collection of example TLS certificates and security credentials.
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'
5. Create Aerospike cluster custom resource (CR)โ
See cluster configuration settings for details on the parameters available in the Aerospike cluster 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.
6. Deploy the Aerospike clusterโ
To deploy a non-root Aerospike cluster, see Create Non-root Aerospike Cluster.
Use the custom resource YAML file (CR file) you created to deploy an Aerospike cluster. If you don't have a CR 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
7. Verify cluster statusโ
Use kubectl get statefulset
to ensure the 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.
Please 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.