Skip to main content
We are excited to be a part of AWS re:Invent 2024. Visit us at booth #1844 in Las Vegas.More info
Loading
Version: Operator 3.2.2

Install the Aerospike Kubernetes Operator on OpenShift using Command Line

Configure the CLI​

From a terminal login to the OpenShift cluster and ensure that the oc and kubectl commands connect to the correct OpenShift cluster.

tip

The following instructions also work with the OpenShift command line tool - oc

Ensure the Operator package is visible​

Run the following command.

kubectl get packagemanifests aerospike-kubernetes-operator-rhmp -n openshift-marketplace

You will see output similar to:

Output:

NAME                                 CATALOG               AGE
aerospike-kubernetes-operator-rhmp   Red Hat Marketplace   22d

Create the Operator subscription​

Create a file aerospike-kubernetes-operator.yaml with the following contents:

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: aerospike-kubernetes-operator-rhmp
  namespace: openshift-operators
spec:
  channel: stable
  installPlanApproval: Automatic
  name: aerospike-kubernetes-operator-rhmp
  source: redhat-marketplace
  sourceNamespace: openshift-marketplace
  startingCSV: aerospike-kubernetes-operator-rhmp.v3.2.2

tip

We recommend setting spec.installPlanApproval to Automatic in the aerospike-kubernetes-operator.yaml file. This setting automatically upgrades the operator whenever upgrades are available.

Create this subscription using the following command:

kubectl apply -f aerospike-kubernetes-operator.yaml

Verify the Operator is Running​

Verify that the Operator's CSV is in the Succeeded phase.

$ kubectl get csv -n openshift-operators aerospike-kubernetes-operator-rhmp.v3.2.2

You will see output similar to the following:

NAME                                   DISPLAY                         VERSION   REPLACES   PHASE
aerospike-kubernetes-operator-rhmp.v3.2.2   Aerospike Kubernetes Operator   3.2.2                Succeeded

Check Operator Logs​

The Operator runs as two replicas by default, for higher availability. Run the following command to follow the logs for the Operator pods.

kubectl -n openshift-operators logs -f deployment/aerospike-operator-controller-manager manager

Output:

2023-08-01T09:07:02Z    INFO    setup   legacy OLM < 0.17 directory is present - initializing webhook server
2023-08-01T09:07:03Z    INFO    controller-runtime.metrics  Metrics server is starting to listen    {"addr": "127.0.0.1:8080"}
2023-08-01T09:07:03Z    INFO    setup   Init aerospike-server config schemas
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "4.3.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "4.5.2"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "5.6.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "4.5.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "5.2.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "5.4.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "4.0.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "4.7.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "6.0.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "5.7.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "4.1.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "5.1.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "4.5.1"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "4.6.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "5.0.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "6.1.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "6.2.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "6.4.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "6.3.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "4.2.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "4.5.3"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "5.5.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "5.3.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "4.3.1"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "4.4.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "4.8.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "4.9.0"}
2023-08-01T09:07:03Z    DEBUG   schema-map  Config schema added {"version": "7.0.0"}
2023-08-01T09:07:03Z    INFO    aerospikecluster-resource   Registering mutating webhook to the webhook server
2023-08-01T09:07:03Z    INFO    controller-runtime.webhook  Registering webhook {"path": "/mutate-asdb-aerospike-com-v1-aerospikecluster"}
2023-08-01T09:07:03Z    INFO    controller-runtime.builder  skip registering a mutating webhook, object does not implement admission.Defaulter or WithDefaulter wasn't called   {"GVK": "asdb.aerospike.com/v1, Kind=AerospikeCluster"}
2023-08-01T09:07:03Z    INFO    controller-runtime.builder  Registering a validating webhook    {"GVK": "asdb.aerospike.com/v1, Kind=AerospikeCluster", "path": "/validate-asdb-aerospike-com-v1-aerospikecluster"}
2023-08-01T09:07:03Z    INFO    controller-runtime.webhook  Registering webhook {"path": "/validate-asdb-aerospike-com-v1-aerospikecluster"}
2023-08-01T09:07:03Z    INFO    setup   Starting manager
2023-08-01T09:07:03Z    INFO    controller-runtime.webhook.webhooks Starting webhook server
2023-08-01T09:07:03Z    INFO    Starting server {"path": "/metrics", "kind": "metrics", "addr": "127.0.0.1:8080"}
2023-08-01T09:07:03Z    INFO    controller-runtime.certwatcher  Updated current TLS certificate
2023-08-01T09:07:03Z    INFO    Starting server {"kind": "health probe", "addr": "[::]:8081"}
I0801 09:07:03.213295       1 leaderelection.go:248] attempting to acquire leader lease operators/96242fdf.aerospike.com...
2023-08-01T09:07:03Z    INFO    controller-runtime.webhook  Serving webhook server  {"host": "", "port": 9443}
2023-08-01T09:07:03Z    INFO    controller-runtime.certwatcher  Starting certificate watcher

Grant permissions to the target namespaces​

The Operator is installed in the openshift-operators namespace. Grant additional permission (by configuring ServiceAccounts and RoleBindings/ClusterRoleBindings) for the target Kubernetes namespace where the Aerospike clusters are created.

There are two ways to grant permission for the target namespaces:

  1. Using kubectl
  2. Using akoctl plugin

Using kubectl​

The procedure to use the namespace aerospike is as follows:

Create the namespace​

Create the Kubernetes namespace if not already created:

kubectl create namespace aerospike

Create a service account​

kubectl -n aerospike create serviceaccount aerospike-operator-controller-manager

Create RoleBinding/ClusterRoleBinding for Aerospike cluster​

Next, create a RoleBinding or ClusterRoleBinding as per requirement to attach this service account to ClusterRole aerospike-cluster. This ClusterRole is created as part of Operator installation and grants Aerospike cluster permission to service account.

  • For using Kubernetes native Pod only network to connect to Aerospike cluster create RoleBinding:
kubectl -n aerospike create rolebinding aerospike-cluster --clusterrole=aerospike-cluster --serviceaccount=aerospike:aerospike-operator-controller-manager
  • For connecting to Aerospike cluster from outside Kubernetes create ClusterRoleBinding:
kubectl create clusterrolebinding aerospike-cluster --clusterrole=aerospike-cluster --serviceaccount=aerospike:aerospike-operator-controller-manager
tip

For attaching multiple service accounts of different namespaces in one go, add multiple --serviceaccount params in above command

Example: To attach service accounts of aerospike and aerospike1 namespace
kubectl create clusterrolebinding aerospike-cluster --clusterrole=aerospike-cluster --serviceaccount=aerospike:aerospike-operator-controller-manager --serviceaccount=aerospike1:aerospike-operator-controller-manager

If the required ClusterRoleBinding already exists in cluster, edit it to attach new service account:

kubectl edit clusterrolebinding aerospike-cluster

This command launches an editor. Append the following lines to the subjects section:

  # A new entry for aerospike.
  # Replace aerospike with your namespace
- kind: ServiceAccount
  name: aerospike-operator-controller-manager
  namespace: aerospike

Save and ensure that the changes are applied.

Using akoctl plugin​

For instructions on installing the akoctl plugin, see akoctl installation.

The procedure to use the namespace aerospike is as follows:

  • For using Kubernetes native Pod only network to connect to Aerospike cluster grant namespace scope permission:
kubectl akoctl auth create -n aerospike --cluster-scope=false
  • For connecting to Aerospike cluster from outside Kubernetes grant cluster scope permission:
kubectl akoctl auth create -n aerospike
tip

For granting permission of multiple namespaces in one go, specify comma separated namespace list in -n param

Example: To grant permission for aerospike and aerospike1 namespace
kubectl akoctl auth create -n aerospike,aerospike1

OpenShift Security Context Constraints (SCC)​

On OpenShift clusters, administrators can use security context constraints (SCCs) to control permissions for pods. These permissions control which actions a pod can perform, and which resources it can access. You can use SCCs to define a set of conditions that a pod must run with, in order to be accepted into the system. See OpenShift SC Guide for details. In order to run Aerospike Enterprise Server clusters on OpenShift, the Aerospike pods need to be granted access to some of the SCC on clusters

SCC anyuid (required)​

Aerospike Enterprise Server images are designed to run as some non-root (any) UID. On OpenShift this requires Aerospike Pods to be allowed to run with any UID requiring anyuid SCC.

This SCC should be granted to the Operator's service account for the aerospike namespace using the following command:

oc adm policy add-scc-to-user anyuid system:serviceaccount:aerospike:aerospike-operator-controller-manager

SCC hostnetwork (optional)​

This SCC allows using host networking and host ports.

This SCC should be granted to the Operator's service account for the aerospike namespace using the following command:

oc adm policy add-scc-to-user hostnetwork system:serviceaccount:aerospike:aerospike-operator-controller-manager

SCC privileged (optional)​

This SCC allows access to all privileged and host features and the ability to run as any user, any group, any FSGroup, and with any SELinux context. For example, this is required to run Index on Flash storage configuration with Aerospike primary index stored on SSD devices.

This SCC should be granted to the Operator's service account for the aerospike namespace using the following command:

oc adm policy add-scc-to-user privileged system:serviceaccount:aerospike:aerospike-operator-controller-manager
Tags:
Last updated on