Aerospike database operator for Kubernetes
The Aerospike Kubernetes Operator automates the deployment and management of Aerospike enterprise clusters on
Kubernetes. The Operator provides a controller that manages
a Custom Resource Definition (CRD)
to extend the Kubernetes API for Aerospike Enterprise clusters. Aerospike cluster deployment and life cycle management
are performed by updating an Aerospike cluster Custom Resource (CR).
For full documentation please visit the official documentation.
The goal of the Operator is to give you the ability to deploy multi-node Aerospike clusters, recover automatically from
node failures, scale up or down automatically as load changes, ensure nodes are evenly split across racks or zones,
automatically update to new versions of Aerospike and manage configuration changes in your clusters.
The Operator supports the following capabilities:
make generate
make manifests
Run the following command with the appropriate name and version for the operator’s image.
IMAGE_TAG_BASE=aerospike/aerospike-kubernetes-operator-nightly
VERSION=4.0.0
make docker-buildx IMG=${IMAGE_TAG_BASE}:${VERSION} PLATFORMS=linux/amd64
Note: Change PLATFORMS
var as per host machine or remove it to build multi-arch image
You can use the following for quickly trying out the operator without
using OLM.
Make sure cert-manager is deployed on your Kubernetes cluster using
instructions here.
To deploy the operator build in the previous step run
make deploy IMG=${IMAGE_TAG_BASE}:${VERSION}
To undeploy run
make undeploy IMG=${IMAGE_TAG_BASE}:${VERSION}
Note: This will also delete the deployed Aerospike clusters because the CRD definitions and all operator related
objects are deleted.
Operator Lifecycle Manager (OLM) is a tool to help manage the Operators running on your cluster. This is the preferred
way to manage Kubernetes operators in production. This section describes how to generate the OLM bundle and run the
operator using OLM.
Install operator-sdk version 1.39.1 using the
installation guide
Make sure the operator’s image has also been pushed.
Set up the environment with image names.
export ACCOUNT=aerospike
export IMAGE_TAG_BASE=${ACCOUNT}/aerospike-kubernetes-operator
export VERSION=4.0.0
export IMG=docker.io/${IMAGE_TAG_BASE}-nightly:${VERSION}
export BUNDLE_IMG=docker.io/${IMAGE_TAG_BASE}-bundle-nightly:${VERSION}
export CATALOG_IMG=docker.io/${IMAGE_TAG_BASE}-catalog-nightly:${VERSION}
Create the bundle
make bundle
make bundle-build bundle-push
make docker-buildx-catalog
Install OLM if not already done
operator-sdk olm install
Create aerospike namespace if it does not exist
kubectl create namespace aerospike
kubectl apply -f - <<EOF
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
name: aerospike
namespace: aerospike
spec:
displayName: Aerospike operator
publisher: Aerospike operator
sourceType: grpc
image: "${CATALOG_IMG}"
updateStrategy:
registryPoll:
interval: 10m
EOF
Targeting single namespace
kubectl apply -f - <<EOF
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: test-operator-group
namespace: test
spec:
targetNamespaces:
- aerospike
upgradeStrategy: Default
EOF
Targeting multiple namespaces
Assuming you want the operator to target two other namespaces ns1 and ns2, create operator group with MultiNamespace install mode.
```shell
kubectl apply -f - <<EOF
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: test-operator-group
namespace: test
spec:
targetNamespaces:
- ns1
- ns2
upgradeStrategy: Default
EOF
kubectl apply -f - <<EOF
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: aerospike-kubernetes-operator
namespace: test
spec:
channel: stable
installPlanApproval: Automatic
name: aerospike-kubernetes-operator
source: aerospike
sourceNamespace: aerospike
EOF
Deploy Aerospike clusters using the Operator
documentation here.
operator-sdk cleanup aerospike-kubernetes-operator --namespace=aerospike
The operator tests require the following prerequisites
kubectl
command configured to use the above clusterThe operator tests create and use 4 namespaces
Run the entire test suite
./test/test.sh -b $BUNDLE_IMG -c $CATALOG_IMG
Run tests matching a regex
./test/test.sh -b $BUNDLE_IMG -c $CATALOG_IMG '-ginkgo.focus=".*MultiCluster.*"'
The Aerospike Kubernetes Operator has a custom controller (written in go) that allows us to embed specific lifecycle
management logic to effectively manage the state of an Aerospike cluster. It does so by managing a Custom Resource
Definition (CRD) to extend the Kubernetes API for Aerospike clusters. Regular maintenance to the Aerospike cluster
deployment and management can be performed by updating an Aerospike cluster Custom Resource (CR).
The Operator is deployed with StatefulSet and operates as a headless service to handle the DNS resolution of pods in the
deployment. Kubernetes StatefulSets is the workload API object that is used to manage stateful applications. It is
important because it manages the deployment and scaling of a set of Pods, and provides guarantees about the ordering and
uniqueness of these Pods (e.g. as unique addressable identities).
A layered approach is taken to orchestration which allows the Operator to manage Aerospike Cluster tasks outside the
Aerospike deployment.