Skip to main content
Version: Operator 3.3.1

Aerospike Kubernetes Operator

The Aerospike Kubernetes Operator automates the deployment and management of Aerospike Enterprise clusters on Kubernetes. The Operator has a controller that manages a Custom Resource Definition (CRD) to extend the Kubernetes API for Aerospike clusters. Aerospike cluster deployment and life cycle management are performed by updating an Aerospike cluster Custom Resource (CR), which exists as a configuration file on the server. Instead of making changes to the cluster by hand, you specify changes in the Aerospike cluster CR file and use kubectl apply to apply these changes. The Operator picks up the changes from the CR file and applies them throughout the cluster.

For example, to add Rack Awareness to your Aerospike cluster, add a rack-aware section of configuration parameters to the CR as described in Rack Awareness. Run kubectl apply -f to apply the CR, meaning that the Operator reads the CR file again and enables Rack Awareness as specified.

This documentation section includes examples of various Aerospike configuration settings you can use with your Aerospike cluster on Kubernetes. If you have questions, suggestions, or other feedback, please let us know.


Check the upgrade page for information about the latest Operator version.

What features does it provide?

The Operator gives you the following abilities:


The Aerospike Kubernetes Operator has a custom controller (written in Go) that allows us to embed specific lifecycle management logic to 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. All regular maintenance to the cluster deployment and management is done by updating the Aerospike Enterprise cluster Custom Resource (CR).

The Operator uses Kubernetes StatefulSets, a key workload API object for managing stateful applications. This ensures consistent deployment, scaling, and guarantees concerning the sequence and uniqueness of the associated Pods, such as maintaining unique, addressable identities for each.

The Operator takes a layered approach to orchestration. This allows the Operator to manage Aerospike cluster tasks outside the Aerospike deployment.