Skip to main content
Loading
Version: Operator 2.0.0

Migrate installation from operator-sdk

Prior to Aerospike Kubernetes Operator being listed on OperatorHub, the Operator installation procedure for OLM involved using operator-sdk. We now recommend using OperatorHub as the source to install and manage version upgrades for the Operator to allow for easy and automatic upgrades to the Operator.

For this to work seamlessly, you need to migrate the Operator's installation to use OperatorHub. The procedure involves the following steps.

info

This procedure will only uninstall the Aerospike Kubernetes Operator. Existing Aerospike clusters will not be impacted.

The following steps assume that the Operator is installed in the aerospike namespace. Change the namespace parameter in the commands if that is not the case.

Uninstall the Operatorโ€‹

Unsubscribe from the Operatorโ€‹

Find the subscription for the Operator.

kubectl get subscription -n aerospike | grep aerospike-kubernetes-operator

This should output something similar to:

aerospike-kubernetes-operator-v2-0-0-sub   aerospike-kubernetes-operator   aerospike-kubernetes-operator-catalog   alpha

Use the name of the subscription from the command output above and delete it.

kubectl delete subscription aerospike-kubernetes-operator-v2-0-0-sub -n aerospike

Delete the Operator's ClusterServiceVersionโ€‹

Get the Operator's ClusterServiceVersion:

kubectl get clusterserviceversion -n aerospike | grep aerospike-kubernetes-operator

This should output something similar to:

aerospike-kubernetes-operator.v2.0.0   Aerospike Kubernetes operator   2.0.0                Succeeded

Use the name of the subscription from the command output above and delete it.

kubectl delete clusterserviceversion aerospike-kubernetes-operator.v2.0.0 -n aerospike

Delete completed jobsโ€‹

kubectl delete job $(kubectl get job -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}' -n aerospike) -n aerospike

Delete the Custom Catalog created by operator-sdkโ€‹

Operator SDK creates a custom Catalog Source for installing the Operator. This is no longer needed because the Operator is listed on the OperatorHub catalog. Find and delete it.

kubectl get CatalogSource -n aerospike | grep aerospike-kubernetes-operator

This should output something similar to:

aerospike-kubernetes-operator-catalog   aerospike-kubernetes-operator   grpc   operator-sdk   36m

Use the name of the catalog source from the command output above and delete it.

kubectl delete CatalogSource aerospike-kubernetes-operator-catalog  -n aerospike

Ensure the Operator pods have stoppedโ€‹

Ensure that Operator's pods have terminated. The following command should return no pods.

kubectl get pod -n aerospike | grep aerospike-operator-controller-manager

Ensure that Catalog Source pods have terminated. The following command should return no pods.

kubectl get pod -n aerospike | grep docker-io

Install the operator using OLMโ€‹

Please follow the installation procedure for your environment to install the Operator again from OperatorHub.

note

Ensure you do grant permission for all the namespace that are running Aerospike clusters by applying the following step after installation.

Grant permissions to the target namespacesโ€‹

The Operator is installed in the operators (openshift-operators for OpenShift/OKD) namespace and needs additional service account configured for the Kubernetes namespaces the Aerospike clusters will be created in.

For each Kubernetes namespace that has Aerospike clusters running, create a service account and attach it to the Operator's cluster role.

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

Update the operator's ClusterRoleBindingโ€‹

Next, add this service account to the Operator's ClusterRoleBinding. To do this, run the following command:

kubectl edit clusterrolebindings.rbac.authorization.k8s.io $(kubectl get clusterrolebindings.rbac.authorization.k8s.io  | grep aerospike-kubernetes-operator | grep -v -- "-opera-" | cut -f 1 -d " ")

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.

Here is a full example of the Operator's ClusterRoleBinding targeting the aerospike namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
creationTimestamp: "2022-01-16T10:48:36Z"
labels:
olm.owner: aerospike-kubernetes-operator.v2.1.0
olm.owner.kind: ClusterServiceVersion
olm.owner.namespace: test
operators.coreos.com/aerospike-kubernetes-operator.test: ""
name: aerospike-kubernetes-operator.v2.1.0-74b946466d
resourceVersion: "51841234"
uid: be546dd5-b21e-4cc3-8a07-e2fe5fe5274c
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: aerospike-kubernetes-operator.v2.1.0-74b946466d
subjects:
- kind: ServiceAccount
name: aerospike-operator-controller-manager
namespace: operators

# New entry
- kind: ServiceAccount
name: aerospike-operator-controller-manager
namespace: aerospike