Skip to main content
Aerospike Vector is now live with LangChain integrationTell me more
Loading
Version: Operator 3.4.0

Configure Aerospike with AKO

Overview​

The pages in this section describe how to configure an Aerospike Database deployment with Aerospike Kubernetes Operator (AKO). See Management information on making changes to your Kubernetes cluster.

Aerospike cluster configuration settings are in the Aerospike cluster Custom Resource (CR) file. When you make changes in the CR file, AKO reads the changes and applies them to the cluster. The CR file is not required to be in any specific location on the server where you run Kubernetes, since the command to update AKO with a new version of the file passes the entire file path to AKO.

By default, and for all examples in this documentation, the CR file is named aerospike-cluster.yaml and located in the same directory where you run kubectl commands.

AKO configuration​

Kubernetes requires configurations in YAML format, while Aerospike uses its own format. AKO translates between the two formats automatically, which means you must follow the specific YAML conventions required for configuration.

See Configuration parameters for a list of all parameters and details on usage. Many parameters support dynamic configuration, to update the cluster upon changes without requiring a restart.

Features​

See the following pages for in-depth explanations and guides to configuring certain features on your Aerospike cluster.

  • Change the compute resources available to your cluster: Scaling
  • Split a single cluster across different hardware: Rack Awareness
  • Duplicate a cluster across different datacenters: XDR
  • Set up monitoring for the cluster using external tools: Monitoring
  • Set up an automatically-managed strong consistency namespace to guarantee no partial writes: Strong Consistency

Configuration change process​

In this example, we modify a parameter, triggering a rolling restart (default behavior), and check the parameter value after the restart.

1. Edit the CR file​

For this example, make a change to the number of file descriptors available to an Aerospike node. By default, this is 15000. Change the spec.aerospikeConfig.service.proto-fd-max field in the CR file to 20000.

apiVersion: asdb.aerospike.com/v1
kind: AerospikeCluster
metadata:
  name: aerocluster
  namespace: aerospike
spec:
  size: 2
  image: aerospike/aerospike-server-enterprise:7.2.0.1
  aerospikeConfig:
    service:
      proto-fd-max: 15000

Save and exit the CR file, then use kubectl to apply the change.

kubectl apply -f aerospike-cluster.yaml

2. Check the Pods​

The Kubernetes pods undergo a rolling restart.

Output:

$ kubectl get pods -n aerospike
NAME          READY   STATUS              RESTARTS   AGE
aerocluster-0-0     1/1     Running         0          3m6s
aerocluster-0-1     1/1     Running         0          3m6s
aerocluster-0-2     1/1     Running         0          30s
aerocluster-0-3     1/1     Terminating     0          30s

After all the pods have restarted, use kubectl describe to get the cluster status.

Check spec.aerospikeConfig.service.proto-fd-max under "Status."

$ kubectl -n aerospike describe aerospikecluster aerocluster
Name:         aerocluster
Namespace:    aerospike
Kind:         AerospikeCluster
...
Status:
  Aerospike Config:
    Service:
      Proto - Fd - Max:   20000
...

Restarts​

AKO pods undergo a rolling warm restart every time a static parameter is modified in the CR file and the file is applied with kubectl apply.

To trigger a warm restart on one or more pods without modifying any parameters, add an operations stanza where the kind field is set to WarmRestart. Setting the field to PodRestart triggers a cold restart. The unique ID attached to each operation prevents a restart loop, since the restart only occurs if the ID is different from the last restart operation ID.

Unchangeable Parameters​

replication-factor and strong-consistency cannot be changed using the Aerospike cluster CR file. These parameters are set the first time the pods start and must remain the same afterward.

However, you can create new pods by starting a new rack with the updated parameter value. See Scaling Namespace Storage for Aerospike on Kubernetes for more information.