We are excited to announce the availability of Aerospike Kubernetes Operator 2.0. Kubernetes is becoming an increasingly popular platform for the deployment of Aerospike, particularly within Dev/Ops flows. In the past two years with more staff remote, automation of provisioning, deployment, and management of infrastructure has become essential. Enterprises need to gain leverage in the application of their personnel and technical resources and infrastructure. The Aerospike Kubernetes Operator provides a solid base for automation when deploying and managing our database on Kubernetes platforms, both in the public cloud (AKS, EKS, and GKE) and on-premises.
In addition, our Operator provides for improved monitoring and alerting of events in the Aerospike Database. We accomplish this through the Prometheus Exporter Sidecar which can be added to the Aerospike server pods. Combining this with the control plane capabilities of Aerospike Kubernetes Operator 2.0 you have both deployment, observability, and management of Aerospike Database clusters on Kubernetes. There are a number of Grafana dashboards that are configured to work with our Prometheus feeds. Together this provides a sound basis for observability and management of Aerospike clusters on Kubernetes.The Operator supports the following capabilities:
Deploy Aerospike clusters
Scale up and down for existing Aerospike clusters
Version upgrade and downgrade
Configure persistent storage and resource allocation
Standardize and validate configurations
Cluster security management
Attach custom sidecars and init containers
New Capabilities
Warm restart of pods for cluster changes, allowing for the restart of the Aerospike service without deleting pods.
Network and Load Balancing
Support for LoadBalancer to discover Aerospike externally. The previous headless service allowed for discovery within the cluster. When configured, the Aerospike Kubernetes Operator 2.0 creates a single service for the Aerospike Cluster, with the type LoadBalancer.
Allow “hostNetwork” in the pod spec section enabling pods to use host networking. This requires the multiPodPerHost configuration to be false.
An additional “dnsPolicy” configuration added to the podSpec that defaults to ClusterFirstWithHostNet when host network is enabled and is set to ClusterFirst when host network is disabled.
TLS
Previously the operator mapped a single secret to all containers in a pod. You can now map secrets to each container within a pod.
Client certificates can be fed to the operator via files when the Custom Resource Definition AerospikeClientCertSource is set.
Rack Awareness
A common practice to support higher availability is to provision clusters to span multiple availability zones. The Aerospike Database supports this with a feature called Rack Awareness. In the new Aerospike Kubernetes Operator, the cluster can be distributed across racks whenever the cluster size is updated or the number of racks is changed. Scheduling policies such as affinity or anti-affinity can be set for each rack.
Custom InitContainer support allows custom initialization of resources like volumes and security certificates.
Storage Volumes
Prior to our 2.0 release, all storage volumes were mounted to all containers. We now provide for more fine-grained control.
Allow storage volumes to accept storage volume source, e.g. empty dir, configmap, secret, pv.
Allow storage volumes to be attached to sidecars and/or init containers.
Pod Scheduling
Control on Aerospike Pod Scheduling allows specifying affinity, anti-affinity, and tolerations for Aerospike Pods.
Allow rack-level overrides for scheduling policies.
Install, manage and upgrade the Aerospike Kubernetes Operator 2.0 with Operator Lifecycle Manager (OLM)
Support for Aerospike Enterprise Server versions 5.6.x and 5.7.x
Support for Kubernetes 1.20, 1.21 and 1.22
Breaking-changes
The Aerospike Kubernetes Operator 2.0 represents a major step forward in providing a complete control plane for Kubernetes-based Aerospike clusters. As we added new control capabilities, APIs inevitably had to change, and hence version 2.0 is not compatible with version 1.x. The cluster spec has breaking changes to accommodate increased flexibility and broader coverage of deployment options:
More storage types like secrets, config maps, and empty dirs
Selective attachment of storage to containers (including init containers)
More control over pod scheduling using affinity/anti-affinity rules and tolerations
Ability to specify labels and annotations to Aerospike pods and attached persistent volumes
RedHat OpenShift Container Platform Certification
The Aerospike Kubernetes Operator 2.0 is compatible with the RedHat OpenShift Container Platform and will be submitted for certification with this release and will be made available in the RedHat Ecosystem Catalog. The 2.0 version of our operator supports both Helm charts and OLM.
Documentation is available here:
https://aerospike.github.io/kubernetes-operator/
