You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to run the velero pod in a different cluster that the 'target' cluster we want to back up. Referring to these resources, this should be generally possible, cf. #1751 or https://velero.io/docs/v1.4/run-locally/. But to my understanding with the limitation that the velero pod will still watches for velero CRs (backup location and schedules and stuff) in the target cluster.
Is there support to configure the velero pod/deployment in a way that i looks for it's relevant CRs in the cluster the pod is deployed to, but actually backs up a remote cluster. I think this could be achieved by an option telling the pod to watch locally and to use the passed kubeconfig to connect to the target cluster, or by just providing two different kubeconfigs (operation and target cluster).
The text was updated successfully, but these errors were encountered:
This is not currently supported. In addition, this would be significantly more difficult to implement for volume backup since the node agent pod needs to be running on the same node as the pod mounting the volume being copied, otherwise it won't have access to the mount point.
I would like to run the velero pod in a different cluster that the 'target' cluster we want to back up. Referring to these resources, this should be generally possible, cf. #1751 or https://velero.io/docs/v1.4/run-locally/. But to my understanding with the limitation that the velero pod will still watches for velero CRs (backup location and schedules and stuff) in the target cluster.
Is there support to configure the velero pod/deployment in a way that i looks for it's relevant CRs in the cluster the pod is deployed to, but actually backs up a remote cluster. I think this could be achieved by an option telling the pod to watch locally and to use the passed kubeconfig to connect to the target cluster, or by just providing two different kubeconfigs (operation and target cluster).
The text was updated successfully, but these errors were encountered: