Red Hat OpenShift

Log in to the web interface and add a new OpenShift Hypervisor Manager:
vProtect Node preparation
The Openshift Nodes should appear in vProtect after indexing the cluster.
Note 1: Please provide the URL to the web console and SSH credentials to the master node when creating the OpenShift hypervisor manager in vProtect UI. You can also use SSH public key authentication. This is needed for vProtect to have access to your cluster deployments. Note 2: Valid SSH admin credentials should be provided for every Openshift node by the user (called Hypervisor in the vProtect UI). If vProtect is unable to execute docker commands on the Openshift node, it means that it is logged as a user lacking admin privileges. Make sure you have added your user to the sudo/wheel group (so they can execute commands with sudo).
Persistent volumes restore/backup
There are two ways of restoring the volume content.
1.The user should deploy an automatic provisioner which will create persistent volumes dynamically. If Helm is installed, the setup is quick and easy https://github.com/helm/charts/tree/master/stable/nfs-server-provisioner.
2.The user should manually create a pool of volumes. vProtect will pick one of the available volumes to restore the content.
OpenShift troubleshooting
The user from the current context should have cluster-admin permissions.
oc adm policy add-cluster-role-to-user cluster-admin admin --as system:admin
In this case, you should stay logged in as admin for the connection to be successful.
The following error might occur if the token in the kubeconfig file is invalid:
Failure executing: GET at: [https://192.168.42.206:8443/api/v1/persistentvolumes](https://192.168.42.206:8443/api/v1/persistentvolumes "Follow link"). Message: Unauthorized! Token may have expired! Please log-in again. Unauthorized.
Solution:
In the OpenShift master node, execute oc login -u admin (or any other user with cluster-admin permissions) and index the OpenShift hypervisor manager in vProtect UI again.
If indexing/export fails because no Pods could be found, please make sure they have the app label assigned appropriately.
Limitations
Currently, we only support backups of Deployments/DeploymentConfigs (persistent volumes and metadata)
All deployment pods will be paused during the backup operation - this is required to achieve consistent backup data.
For a successful backup, every object used by the Deployment/DeploymentConfig should have an app label assigned appropriately.
Kubernetes
Proxmox VE
Last modified 1yr ago