Aerospike

Applications that need fast reads and writes across a large data set can use Aerospike, a database designed for low-latency access. Its Kubernetes operator automates deploying and maintaining the cooperating database servers, rather than leaving each server to be managed separately. This entry explains that deployment choice and what changes when moving from the older Helm chart to operator-managed clusters.

Deployment and operating notes

This historical entry describes a Helm 2-era StatefulSet with an init container and generated mesh configuration. Aerospike now documents Aerospike Kubernetes Operator (AKO) and vendor Helm charts that install the controller before deploying database clusters. That is a different management model: a running StatefulSet does not automatically become an operator-managed database when the operator is installed.

Check the operator/server compatibility and edition requirements, storage layout, namespace settings and admission-webhook dependencies before choosing a release. The current Helm installation guide requires cert-manager and calls out Pod Security Admission constraints; do not copy its namespace policy into unrelated workloads. For migration, inventory namespaces, replication factors, device or file storage, mesh addresses and client discovery. Establish a database-level backup and a tested restore path before moving data. Rehearse client failover and rolling maintenance with representative traffic. Keep the source cluster intact until record counts and application reads agree; PVC attachment alone does not establish database compatibility.