+ After removing the LINSTOR Operator v1 deployment, you can install + LINSTOR Operator v2. +
+ +
+ You can deploy the LINSTOR Operator v2 by using either the
+ Kustomize tool,
+ integrated with kubectl, or else by using Helm and a LINBIT Helm chart.
+
This is the last step when migrating the LINSTOR Operator from version 1 (v1) to version 2 (v2).
+ +Prerequisites
++ To install the LINSTOR Operator v2 into your current deployment, you will need to install the following + tools: +
+ + + +Deploying LINSTOR Operator v2 by Using Kustomize
+
+ You can use kubectl and the built-in kustomize feature to deploy LINSTOR Operator
+ v2.
+ For instructions on how to do this, refer to the documentation in the + LINSTOR User’s Guide. + Follow the user’s guide instructions for deploying the Operator v2, After deploying the Operator, return to + this page (Step 4) and continue to the “Deploying the LINBIT SDS Cluster” instructions below. +
+ +Deploying LINSTOR Operator v2 by Using Helm
+You can also use Helm to deploy LINSTOR Operator v2.
+ ++ Instructions on how to do this are also in the + LINSTOR User’s Guide. + Follow the user’s guide instructions for deploying the Operator v2, After deploying the Operator, return to + this page (Step 4) and continue to the “Deploying the LINBIT SDS Cluster” instructions below. +
+ +Deploying the LINBIT SDS Cluster
++ LINBIT SDS is the term that describes a LINSTOR and DRBD deployment. The LINSTOR + Operator is a part of a LINBIT SDS deployment in Kubernetes. After deploying the + LINSTOR Operator v2, you can fully deploy LINBIT SDS in your Kubernetes cluster by using the resources that + you generated in Step 2. +
+ +Creating a Secret
++ When installing the LINSTOR Operator v1 by using Helm, Helm automatically generates a passphrase for LINSTOR. + After Helm initializes LINSTOR with the passphrase, the LINSTOR controller will not be able to fully start + without supplying the passphrase. In Step 2 of the migration + instructions, you collected the passphrase from your existing Operator v1 deployment. You will use that + passphrase to create a secret that you can use to migrate your resources into the Operator v2 deployment. +
+To create the secret, enter the following commands:
+PASSPHRASE=<passphrase-collected-from-kubectl-get-secrets-command-in-step-2>
+cat << EOF | kubectl apply -f - --server-side
+apiVersion: v1
+kind: Secret
+metadata:
+ name: linstor-op-passphrase
+ namespace: linbit-sds # Change the namespace here
+data:
+ MASTER_PASSPHRASE: $PASSPHRASE
+EOF
+unset PASSPHRASEOutput from a successful kubectl apply command will show that the secret was applied.
secret/linstor-op-passphrase serverside-appliedApplying Resources
+
+ Next, apply the resources that you collected in a v2-resources.yaml file by running the
+ collection script in the Step 2
+ instructions.
+
kubectl apply -f v2-resources.yaml --server-sideOutput from a successful command will show that your resources were created.
+ +linstorcluster.piraeus.io/linstorcluster serverside-applied
+linstorsatelliteconfiguration.piraeus.io/host-networking serverside-applied
+linstorsatelliteconfiguration.piraeus.io/linstor-op-ns serverside-appliedNow the cluster will come up, using the existing data to restore the cluster state.
+ +Verifying Cluster State
+
+ Before verifying your cluster state, you can change your kubectl command context to the
+ linbit-sds namespace, by entering the following command:
+
kubectl config set-context --current --namespace=linbit-sdsNext, you can check the cluster state by using various linstor command line client commands:
kubectl exec deploy/linstor-controller -- linstor node list
+kubectl exec deploy/linstor-controller -- linstor storage-pool list
+kubectl exec deploy/linstor-controller -- linstor resource list-volumes
+kubectl exec deploy/linstor-controller -- linstor error-reports list+ You can also + provision new volumes, + to verify that the cluster is operational. +
+