00-installation-guide.adoc

Installation Guide

Table of Contents

• Pre-requisites
  • Kubernetes
• Installing aerospike-operator
  • Quickstart
  • Advanced installation
• Configuring aerospike-operator
• Uninstalling aerospike-operator

Pre-requisites

Kubernetes

aerospike-operator requires Kubernetes 1.13+. Running aerospike-operator in older Kubernetes versions may be possible, but it is not supported and not all features will be usable.

Installing aerospike-operator

Quickstart

In order to install aerospike-operator using the default configuration, one may run

$ kubectl create -f https://raw.githubusercontent.com/travelaudience/aerospike-operator/master/docs/examples/00-prereqs.yml
$ kubectl create -f https://raw.githubusercontent.com/travelaudience/aerospike-operator/master/docs/examples/10-aerospike-operator.yml

This will quickly get aerospike-operator up and running in one’s Kubernetes cluster. In order to understand what happens behind the scenes, or in case one wants to tweak the aerospike-operator configuration, one should read the next section carefully.

Advanced installation

To install aerospike-operator in one’s Kubernetes cluster, one must first clone the aerospike-operator repository into one’s workstation:

$ git clone https://github.com/travelaudience/aerospike-operator.git

Then, one must switch to the aerospike-operator directory created by the above command and run

$ kubectl create -f docs/examples/00-prereqs.yml

This will create a dedicated namespace for aerospike-operator, create a dedicated service account in this namespace and configure the permissions associated with the service account so that aerospike-operator can operate in RBAC-enabled clusters.

After installing the pre-requisites, one must create a deployment for aerospike-operator. One may do it by running

$ kubectl create -f docs/examples/10-aerospike-operator.yml

💡	Optionally, one may edit this file in order to tweak the default installation parameters. One should check the Configuring aerospike-operator section for further details on the available flags.

This will create a service ^[1] and a deployment for aerospike-operator:

$ kubectl -n aerospike-operator get svc
NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
aerospike-operator   ClusterIP   10.63.241.55   <none>        443/TCP   2m

$ kubectl -n aerospike-operator get deployment
NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
aerospike-operator   2         2         2            1           2m

In its turn, and upon starting, aerospike-operator will register three custom resource definitions (CRDs):

$ kubectl get crd
NAME                                                      AGE
aerospikeclusters.aerospike.travelaudience.com            2m
aerospikenamespacebackups.aerospike.travelaudience.com    2m
aerospikenamespacerestores.aerospike.travelaudience.com   2m

aerospike-operator will also create a secret containing TLS artifacts and register a validating admission webhook:

kubectl -n aerospike-operator get secrets
NAME                     TYPE                DATA    AGE
aerospike-operator-tls   kubernetes.io/tls   2       2m
(...)

$ kubectl get validatingwebhookconfiguration
NAME                                              AGE
aerospike-operator.aerospike.travelaudience.com   2m

This webhook runs within aerospike-operator itself and helps providing a richer user experience by rejecting invalid Aerospike cluster configurations upfront.

Configuring aerospike-operator

The behaviour of aerospike-operator can be tweaked using command-line flags. The following flags are supported:

Flag	Default	Deprecated	Description
--admission-enabled	true	YES	Whether to enable the validating admission webhook.
--debug	false	YES	Whether to enable debug mode.
--kubeconfig	""		Path to a kubeconfig. Only required if out-of-cluster.

To set values for these flags, one should edit the deployment created in Installing aerospike-operator and add the desired values in the .spec.template.spec.containers[0].args field of the deployment.

⚠️

When running with the --debug=true flag aerospike-operator will disable inter-pod anti-affinity, making it possible for two Aerospike pods to be co-located on the same Kubernetes node. Running aerospike-operator with this flag outside a testing environment is strongly discouraged. For this reason, this flag is now deprecated and should not be specified.

Uninstalling aerospike-operator

To completely uninstall aerospike-operator and all associated resources, one should start by deleting the deployment and pre-requisites:

$ kubectl delete -f docs/examples/10-aerospike-operator.yml
$ kubectl delete -f docs/examples/00-prereqs.yml

Then, one should delete any existing validating admission webhook configurations created by aerospike-operator:

$ kubectl delete validatingwebhookconfiguration aerospike-operator.aerospike.travelaudience.com

Finally, one should delete any custom resource definitions introduced by aerospike-operator:

$ kubectl delete crd aerospikeclusters.aerospike.travelaudience.com
$ kubectl delete crd aerospikenamespacebackups.aerospike.travelaudience.com
$ kubectl delete crd aerospikenamespacerestores.aerospike.travelaudience.com

❗	Running the commands above will PERMANENTLY DESTROY all Aerospike clusters managed by aerospike-operator. One should proceed with caution before running these commands.

---

1. Required for the embbeded validating admission webhook to work.