Kubernetes Effortless Migration Using Velero
Tags: gcp, kubernetes, velero, migration
Published: 2023-07-07 05:15:50

#Introduction#
In the dynamic world of cloud-native applications, Kubernetes has emerged as the go-to container orchestration platform. As organizations embrace the benefits of Kubernetes, there comes a time when migrating clusters becomes a necessity. However, the process of migrating Kubernetes clusters can be complex and error-prone without the right tools. 
Enter Velero, an open-source tool that simplifies the migration process by ensuring data consistency, preserving application state, and enabling seamless cluster transitions. In this blog post, we'll explore the power of [Velero](https://velero.io) and how it can help you migrate Kubernetes clusters with ease.

In our case we will be using GKE as a source and destination cluster.

#####Setup Velero#####

First you need to setup velero in your local or cloudshell in GCP.

- 
Download velero binary from the following [link](https://github.com/vmware-tanzu/velero/releases)


- 
Copy velero binary to bin directory

```
sudo cp velero /usr/local/bin
```
#####Velero Cluster Setup#####

- 
Create a GCS Bucket
```
BUCKET=<backup-bucket>
gsutil mb gs://$BUCKET
```

- Create a Service account with for velero
```
gcloud iam service-accounts create velero --display-name “Velero service account”
```

- Set the $EMAIL variable to match its email value.

```
EMAIL=$(gcloud iam service-accounts list --filter=”displayName:Velero service account” --format ‘value(email)’)
```

- Store the project id to variable PROJECT_ID

```
PROJECT_ID=$(gcloud config get-value project)
```

- Attach necessary permissions to the service account.

```
ROLE_PERMISSIONS=(
 compute.disks.get
 compute.disks.create
 compute.disks.createSnapshot
 compute.snapshots.get
 compute.snapshots.create
 compute.snapshots.useReadOnly
 compute.snapshots.delete
 compute.zones.get
)

gcloud iam roles create velero.server \ 
--project $PROJECT_ID \ 
--title “Velero Server” \
--permissions “$(IFS=”,”; echo “${ROLE_PERMISSIONS[*]}”)”

gcloud projects add-iam-policy-binding $PROJECT_ID \
--member serviceAccount:$EMAIL \
--role projects/$PROJECT_ID/roles/velero.server


gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
```

- Install Velero into the source cluster and start the
deployment. This will create a namespace called velero.

```
velero install \ 
--provider gcp \ 
--plugins velero/velero-plugin-for-gcp:v1.7.0 \
--bucket $BUCKET \
--secret-file ./service-account.json

```

For more details on GCP plugin you can visit this [link](https://github.com/vmware-tanzu/velero-plugin-for-gcp).

####Create Velero Backup####

Login to source GKE cluster.

```
gcloud container clusters get-credentials source-cluster — zone <my-zone> --project <my-project-id>
```

```
velero backup create <backup-name>
```

you can even exclude namespaces or even backup only specific namespaces. Please visit [here](https://velero.io/docs/v1.4/resource-filtering/) for more details.

######Some examples for filtering resources######

```
     velero backup create <backup-name> --include-namespaces <namespace>
```

```
     velero backup create <backup-name> --include-resources deployments
```

To list backups
```
velero backup get
```

Describe backup
```
velero backup describe <backup-name>
```


####Create Velero Restore####

- Login to Destination Cluster

```
gcloud container clusters get-credentials destination-cluster --zone <my-zone> --project <my-project-id>
```

- Install velero plugin on the cluster by executing below command.

```
velero install \ 
--provider gcp \ 
--plugins velero/velero-plugin-for-gcp:v1.7.0 \
--bucket $BUCKET \
--secret-file ./service-account.json
```

- Create a manual restore from backup

```
velero restore create <restore-name> --from-backup <backup-name>
```

- To retrieve restores

```
velero restore get
```

- To describe and retrieve restore logs

```
velero restore describe <restore-name>

velero restore logs <restore-name>
```

- Verify all the resources whether it got
properly deployed on the destination cluster.

This is how we managed to migrated our Kubernetes clusters from different region or zones.