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.
- Uninstall the Operator
- Ensure the Operator pods have stopped
- Install the operator using OLM
- Grant permissions to the target namespaces
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.
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