Aerospike Kubernetes Operator (AKO) 4.2 continues the steady evolution of Aerospike on Kubernetes as a production-grade control plane for real-time, stateful systems.
This release focuses on three practical areas:
Expanded support for regulated and security-sensitive environments
More flexible storage scaling at the rack level
Safer operations during node maintenance and partial failures
If you operate Aerospike in Kubernetes at scale, AKO 4.2 is about tighter control, clearer recovery paths, and fewer surprises in day-2 operations.
The evolution of AKO 4.x
Over the 4.x line, we have deliberately strengthened AKO’s foundation and production posture.
In 4.0, we modernized the foundation by removing legacy APIs and dropping support for deprecated platforms, aligning with current Kubernetes versions, and tightening compatibility with Aerospike Database and Aerospike Backup Service (ABS).
In 4.1, we strengthened day-2 operations with improved observability, cleaner upgrade and PVC lifecycle handling, and more predictable backup and recovery behavior.
Now in 4.2, we extend that trajectory with expanded support for regulated environments, more flexible storage scaling at the rack level, and safer operational controls during maintenance and failure scenarios.
Enterprise and regulated environment support
For many organizations, performance and scale are only part of the equation. Security posture, compliance requirements, and deployment constraints are equally critical.
AKO 4.2 adds support for Federal Edition FIPS compliance, enabling Aerospike on Kubernetes to meet strict cryptographic standards required in government and other regulated environments. This removes friction for teams operating under federal or industry-specific mandates and expands where AKO-managed clusters can be deployed without architectural exceptions.
Beyond FIPS, 4.2 continues alignment with current Aerospike Database and ABS releases, ensuring that security, data protection, and operational controls evolve together. In enterprise environments, consistency across these layers is essential.
The result is deployment confidence. AKO is designed to meet the expectations of organizations where compliance and operational rigor are non-negotiable.
Scaling storage without redesigning your cluster
In Kubernetes, scaling stateless workloads is often as simple as adjusting replica counts or pod resources. For stateful systems backed by persistent volumes, storage growth introduces operational constraints that do not scale as cleanly as pods.
Real-world Aerospike clusters rarely grow in perfectly uniform ways. Capacity pressure often shows up at the rack or storage layer first, and operators need ways to respond without rebuilding clusters or introducing unnecessary disruption. To sidestep those obstacles, AKO 4.2 introduces vertical storage scaling using rack revision, enabling storage capacity to be increased in a more controlled and granular manner. Instead of treating scaling as an all-or-nothing cluster event, operators can evolve specific racks as requirements change.
We also added support for the hostPath volume type, expanding deployment flexibility in environments where direct host-mounted storage is preferred or required.
These enhancements make AKO better aligned with how production systems actually grow: incrementally, unevenly, and under real workload pressure.
Operate safely in real-world production environments
Kubernetes clusters are dynamic by design. Nodes are drained for maintenance. Infrastructure is upgraded. Pods fail, restart, or remain pending. In stateless systems, this is routine. In stateful, real-time systems, these transitions must be handled deliberately.
AKO 4.2 adds several capabilities that reduce risk during these events:
Pod eviction API webhook support enables safer eviction of Aerospike pods during node maintenance. Instead of abrupt termination, eviction is coordinated with cluster state and ongoing migrations, reducing the risk of data loss or unintended service disruption. For stateful systems like a database, this level of control is essential.
Wait-for-migration before pod deletion ensures that data migrations complete before a pod is removed. This reduces the risk of unintended disruption during rolling updates or node drains.
Grace period for failed or pending pods gives operators more control in degraded scenarios, avoiding premature or cascading actions while the cluster stabilizes.
Forceful removal of a rack from the roster in a running cluster provides a deterministic recovery option when infrastructure failures leave a rack permanently unavailable.
Taken together, these changes reflect a clear principle: production systems encounter imperfect conditions. AKO 4.2 provides explicit controls to protect data integrity and service availability when those conditions arise.
A control plane for real-time stateful systems
AKO has evolved beyond a deployment utility. It is the operational layer for running Aerospike safely on Kubernetes.
With 4.2, we deepen support for regulated environments, enable more flexible storage growth, and reduce operational risk during maintenance and failure scenarios. As real-time workloads continue to grow in scale and criticality, AKO will continue to evolve as the control plane for operating Aerospike with confidence in Kubernetes environments.
If you are running Aerospike in Kubernetes today, review the 4.2 release notes and upgrade guidance to take advantage of these enhancements.
