Can Velero be installed on GKE Autopilot ?

[sandeep-tukaram]

Does it require privileged access ? Also, it has a daemonset. Does that require special process or practices to be followed for installations ?

[blackpiglet]

Yes, but the filesystem backup/restore cannot be used on Autopilot clusters.
The reason is the Velero node-agent DaemonSet needs to mount the kubelet's pod mounting volumes as host-path to read and write data, but the Autopilot clusters don't allow using the host-path volumes.
As a result, the node-agent DaemonSet cannot start. Except that, the other parts of Velero should work fine.

[sandeep-tukaram]

Hey thanks for the details. What I'm upto is to migrate a GKE cluster to GKE autopilot. New to all this, though, Velero sounds interesting. However, I still haven't found answer to the question as to why does Velero resort to backup/restore when redoplying with modified manifest files pointing to new cluster sounds straight forward solution.

[blackpiglet]

Redeploying with modified manifest files pointing to new cluster sounds straight forward solution
I missed your meaning.
To me, that means restoring the backup to a new cluster.

Do you mean no volume data are needed, only care about the k8s resource manifests?
If that is what you mean, then you can, of course, install Velero on GKE AutoPilot clusters because you don't need the Node-Agent DaemonSet.

[sandeep-tukaram]

1. By redeploying, I mean submitting an application's Deployment manifest files, stored in the git repository, using kubectl or helm to the new cluster's API. I'm wondering why Velero uses CRDs/Controllers to backup, seems over engineering. Whats the benefit Velero's approach provides compared to using kubectl apply and helm .

2. I want to migrate both stateful (with volume data) and stateless applications, in fact, there are jobs as well. Safe to assume all kinds of varied workloads in the kubernetes cluster.

[draghuram]

@sandeep-tukaram , You should refrain from comments such as "overengineering", especially if you are new to it :-). Velero is a backup/restore tool in the first place and its main use case is disaster recovery. So it does "backup" of all the resources and PVC data on a cluster and when needed, it will "restore" them. Migration as you want to do can certanily be done by doing backup on the source cluster and doing restore on the target. Moreover, Velero started much before practices such as "gitops" became popular. Finally, you always need backup even if you deploy from git because production systems always "drift" from the deployment source, despite your best efforts.

[blackpiglet]

Then you only need to restore the volume data.
By far, this is not supported yet. There is a proposal, but not implemented yet.
#7481