Skip to main content

2 posts tagged with "kubernetes"

View All Tags

· 4 min read

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

See our product page here:

https://aerospike.com/products/kubernetes-operator/