Replik8s watches resource definitions and keeps a record in a persistent volume.
Replik8s is configured with the ReplicationSource resources in the replik8s.rhpds.redhat.com API group.
Example Configuration:
apiVersion: replik8s.rhpds.redhat.com/v1 kind: ReplicationSource metadata: name: operators data: spec: kubeConfig: secret: kubeconfig resources: - apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource - apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion - apiVersion: operators.coreos.com/v1alpha1 kind: InstallPlan - apiVersion: operators.coreos.com/v1 kind: Operator - apiVersion: operators.coreos.com/v1 kind: OperatorGroup - apiVersion: operators.coreos.com/v1alpha1 kind: Subscription
To create kubeconfig secret for access to source cluster:
oc create secret generic kubeconfig --from-file=kubeconfig.yaml
The ReplicationSource must be created in the same namespace as where replik8s itself is running.
Restore may be performed from either the latest version of the data within the pod or from a recovery point. Each ReplicationSource exposes the path to its data directory within its status for ease of extraction.
Example commands to extract the latest data from replik8s:
POD=$(oc get pod -l app.kubernetes.io/name=replik8s -o jsonpath={.items[0].metadata.name}) LATEST_PATH=$(oc get replicationsource -o jsonpath={.items[0].status.latestPath}) oc rsync $POD:$LATEST_PATH .
Replik8s includes the replik8s-restore
utility which may be used to restore
backups including restoring the status on resources. The effectiveness of this
command depends on the compatibility of the resources to restore.
It may be necessary to stop deployments and operators running within the
cluster before initiating a restore.
To restore with replik8s-restore
you will need a RestoreConfig resource.
For example:
apiVersion: replik8s.rhpds.redhat.com/v1 kind: RestoreConfig metadata: name: anarchy spec: resources: - apiVersion: anarchy.gpte.redhat.com/v1 kind: AnarchyAction restoreConflictStrategy: replace restoreInProgressLabels: anarchy.gpte.redhat.com/ignore: restoring restoreStatus: true - apiVersion: anarchy.gpte.redhat.com/v1 kind: AnarchyRun restoreConflictStrategy: replace restoreInProgressLabels: anarchy.gpte.redhat.com/ignore: restoring restoreStatus: true - apiVersion: anarchy.gpte.redhat.com/v1 kind: AnarchySubject restoreConflictStrategy: replace restoreInProgressLabels: anarchy.gpte.redhat.com/ignore: restoring restoreStatus: true
In this configuration the label anarchy.gpte.redhat.com/ignore
will be applied
to each resource created or replaced during the restoration process.
The Anarchy kopf operator is designed to ignore any resources with this label
so that the resources may be restored without being handled as new resources
during the restore.
Once the restore is complete the ignore label is removed so that normal
processing resumes.
A restore config may be stored in a local file or in the cluster.
If stored in the cluster then restoration may be performed with:
replik8s-restore --config NAME PATH/TO/BACKUP/DATA
If stored in a local file then restoration may be performed with:
replik8s-restore --config-path CONFIG_FILE PATH/TO/BACKUP/DATA
Finally, the replik8s-restore
command is available within the replik8s
pod to allow for restoration without needing to copy files out of the
pod first.
In order to use replik8s-restore
within the pod you will first need
to temporarily grant necessary cluster access to the replik8s pod.
For example:
oc adm policy add-cluster-role-to-user cluster-admin -z replik8s --rolebinding-name=replik8s:cluster-admin
When restoration is complete, the cluster role binding can be removed with:
oc delete clusterrolebinding replik8s:cluster-admin