Add more details about restore workflow (#4928)
* Add more details about restore workflow Signed-off-by: Abigail McCarthy <mabigail@vmware.com>pull/4965/head
Abigail McCarthy
GitHub
parent
5c48307b5a
commit
22e0afaa2a
|
|
@ -28,15 +28,6 @@ The **schedule** operation allows you to back up your data at recurring interval
|
|||
|
||||
Velero saves backups created from a schedule with the name `<SCHEDULE NAME>-<TIMESTAMP>`, where `<TIMESTAMP>` is formatted as *YYYYMMDDhhmmss*. For more information see the [Backup Reference documentation](backup-reference.md).
|
||||
|
||||
## Restores
|
||||
|
||||
The **restore** operation allows you to restore all of the objects and persistent volumes from a previously created backup. You can also restore only a filtered subset of objects and persistent volumes. Velero supports multiple namespace remapping--for example, in a single restore, objects in namespace "abc" can be recreated under namespace "def", and the objects in namespace "123" under "456".
|
||||
|
||||
The default name of a restore is `<BACKUP NAME>-<TIMESTAMP>`, where `<TIMESTAMP>` is formatted as *YYYYMMDDhhmmss*. You can also specify a custom name. A restored object also includes a label with key `velero.io/restore-name` and value `<RESTORE NAME>`.
|
||||
|
||||
By default, backup storage locations are created in read-write mode. However, during a restore, you can configure a backup storage location to be in read-only mode, which disables backup creation and deletion for the storage location. This is useful to ensure that no backups are inadvertently created or deleted during a restore scenario.
|
||||
|
||||
You can optionally specify restore hooks to be executed during a restore or after resources are restored. For example, you might need to perform a custom database restore operation before the database application containers start. [More about restore hooks][11].
|
||||
|
||||
## Backup workflow
|
||||
|
||||
|
|
@ -54,6 +45,32 @@ By default, `velero backup create` makes disk snapshots of any persistent volume
|
|||
|
||||
![19]
|
||||
|
||||
## Restores
|
||||
|
||||
The **restore** operation allows you to restore all of the objects and persistent volumes from a previously created backup. You can also restore only a [filtered](resource-filtering.md) subset of objects and persistent volumes. Velero supports multiple namespace remapping--for example, in a single restore, objects in namespace "abc" can be recreated under namespace "def", and the objects in namespace "123" under "456".
|
||||
|
||||
The default name of a restore is `<BACKUP NAME>-<TIMESTAMP>`, where `<TIMESTAMP>` is formatted as *YYYYMMDDhhmmss*. You can also specify a custom name. A restored object also includes a label with key `velero.io/restore-name` and value `<RESTORE NAME>`.
|
||||
|
||||
By default, backup storage locations are created in read-write mode. However, during a restore, you can configure a backup storage location to be in read-only mode, which disables backup creation and deletion for the storage location. This is useful to ensure that no backups are inadvertently created or deleted during a restore scenario.
|
||||
|
||||
You can optionally specify [restore hooks][11] to be executed during a restore or after resources are restored. For example, you might need to perform a custom database restore operation before the database application containers start.
|
||||
|
||||
### Restore workflow
|
||||
|
||||
When you run `velero restore create`:
|
||||
|
||||
1. The Velero client makes a call to the Kubernetes API server to create a [`Restore`](api-types/restore.md) object.
|
||||
|
||||
1. The `RestoreController` notices the new Restore object and performs validation.
|
||||
|
||||
1. The `RestoreController` fetches the backup information from the object storage service. It then runs some preprocessing on the backed up resources to make sure the resources will work on the new cluster. For example, using the [backed-up API versions](#backed-up-api-versions) to verify that the restore resource will work on the target cluster.
|
||||
|
||||
1. The `RestoreController` starts the restore process, restoring each eligible resource one at a time.
|
||||
|
||||
By default, Velero performs a non-destructive restore, meaning that it won't delete any data on the target cluster. If a resource in the backup already exists in the target cluster, Velero will skip that resource. You can configure Velero to use an update policy instead using the [`--existing-resource-policy`](restore-reference.md#restore-existing-resource-policy) restore flag. When this flag is set to `update`, Velero will attempt to update an existing resource in the target cluster to match the resource from the backup.
|
||||
|
||||
For more details about the Velero restore process, see the [Restore Reference](restore-reference.md) page.
|
||||
|
||||
## Backed-up API versions
|
||||
|
||||
Velero backs up resources using the Kubernetes API server's *preferred version* for each group/resource. When restoring a resource, this same API group/version must exist in the target cluster in order for the restore to be successful.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ layout: docs
|
|||
|
||||
*Filter objects by namespace, type, or labels.*
|
||||
|
||||
This page describes how to use the include and exclude flags with the `velero backup` and `velero restore` commands. Velero includes all objects in a backup or restore when no filtering options are used.
|
||||
This page describes how to use the include and exclude flags with the `velero backup` and `velero restore` commands. By default Velero includes all objects in a backup or restore when no filtering options are used.
|
||||
|
||||
## Includes
|
||||
|
||||
|
|
|
|||
|
|
@ -3,27 +3,12 @@ title: "Restore Reference"
|
|||
layout: docs
|
||||
---
|
||||
|
||||
## Restoring Into a Different Namespace
|
||||
|
||||
Velero can restore resources into a different namespace than the one they were backed up from. To do this, use the `--namespace-mappings` flag:
|
||||
|
||||
```bash
|
||||
velero restore create RESTORE_NAME \
|
||||
--from-backup BACKUP_NAME \
|
||||
--namespace-mappings old-ns-1:new-ns-1,old-ns-2:new-ns-2
|
||||
```
|
||||
## What happens when user removes restore objects
|
||||
A **restore** object represents the restore operation. There are two types of deletion for restore objects:
|
||||
1. Deleting with **`velero restore delete`**.
|
||||
This command will delete the custom resource representing it, along with its individual log and results files. But, it will not delete any objects that were created by it from your cluster.
|
||||
2. Deleting with **`kubectl -n velero delete restore`**.
|
||||
This command will delete the custom resource representing the restore, but will not delete log/results files from object storage, or any objects that were created during the restore in your cluster.
|
||||
The page outlines how to use the `velero restore` command, configuration options for restores, and describes the main process Velero uses to perform restores.
|
||||
|
||||
## Restore command-line options
|
||||
To see all commands for restores, run : `velero restore --help`
|
||||
To see all options associated with a specific command, provide the --help flag to that command. For example, **`velero restore create --help`** shows all options associated with the **create** command.
|
||||
To see all commands for restores, run `velero restore --help`.
|
||||
|
||||
To list all options of restore, use **`velero restore --help`**
|
||||
To see all options associated with a specific command, provide the `--help` flag to that command. For example, `velero restore create --help` shows all options associated with the `create` command.
|
||||
|
||||
```Usage:
|
||||
velero restore [command]
|
||||
|
|
@ -36,57 +21,127 @@ Available Commands:
|
|||
logs Get restore logs
|
||||
```
|
||||
|
||||
## What happens to NodePorts when restoring Services
|
||||
## Detailed Restore workflow
|
||||
|
||||
**Auto assigned** NodePorts **deleted** by default and Services get new **auto assigned** nodePorts after restore.
|
||||
The following is an overview of Velero's restore process that starts after you run `velero restore create`.
|
||||
|
||||
**Explicitly specified** NodePorts auto detected using **`last-applied-config`** annotation and **preserved** after restore. NodePorts can be explicitly specified as .spec.ports[*].nodePort field on Service definition.
|
||||
1. The Velero client makes a call to the Kubernetes API server to create a [`Restore`](api-types/restore.md) object.
|
||||
|
||||
#### Always Preserve NodePorts
|
||||
1. The `RestoreController` notices the new Restore object and performs validation.
|
||||
|
||||
It is not always possible to set nodePorts explicitly on some big clusters because of operation complexity. Official Kubernetes documents states that preventing port collisions is responsibility of the user when explicitly specifying nodePorts:
|
||||
1. The `RestoreController` fetches basic information about the backup being restored, like the [BackupStorageLocation](locations.md) (BSL). It also fetches a tarball of the cluster resources in the backup, any volumes that will be restored using Restic, and any volume snapshots to be restored.
|
||||
|
||||
```
|
||||
If you want a specific port number, you can specify a value in the `nodePort` field. The control plane will either allocate you that port or report that the API transaction failed. This means that you need to take care of possible port collisions yourself. You also have to use a valid port number, one that's inside the range configured for NodePort use.
|
||||
1. The `RestoreController` then extracts the tarball of backup cluster resources to the /tmp folder and performs some pre-processing on the resources, including:
|
||||
|
||||
https://kubernetes.io/docs/concepts/services-networking/service/#nodeport
|
||||
* Sorting the resources to help Velero decide the [restore order](#resource-restore-order) to use.
|
||||
|
||||
* Attempting to discover the resources by their Kubernetes [Group Version Resource (GVR)](https://kubernetes.io/docs/reference/using-api/api-concepts/). If a resource is not discoverable, Velero will exclude it from the restore. See more about how [Velero backs up API versions](#backed-up-api-versions).
|
||||
|
||||
* Applying any configured [resource filters](resource-filtering.md).
|
||||
|
||||
* Verify the target namespace, if you have configured [`--namespace-mappings`](#restoring-into-a-different-namespace) restore option.
|
||||
|
||||
|
||||
1. The `RestoreController` begins restoring the eligible resources one at a time. Velero extracts the current resource into a Kubernetes resource object. Depending on the type of resource and restore options you specified, Velero will make the following modifications to the resource or preparations to the target cluster before attempting to create the resource:
|
||||
|
||||
* The `RestoreController` makes sure the target namespace exists. If the target namespace does not exist, then the `RestoreController` will create a new one on the cluster.
|
||||
|
||||
* If the resource is a Persistent Volume (PV), the `RestoreController` will [rename](#persistent-volume-rename) the PV and [remap](#restoring-into-a-different-namespace) its namespace.
|
||||
|
||||
* If the resource is a Persistent Volume Claim (PVC), the `RestoreController` will modify the [PVC metadata](#pvc-restore).
|
||||
|
||||
* Execute the resource’s `RestoreItemAction` [custom plugins](custom-plugins/), if you have configured one.
|
||||
|
||||
* Update the resource object’s namespace if you've configured [namespace remapping](#restoring-into-a-different-namespace).
|
||||
|
||||
* The `RestoreController` adds a `velero.io/backup-name` label with the backup name and a `velero.io/restore-name` with the restore name to the resource. This can help you easily identify restored resources and which backup they were restored from.
|
||||
|
||||
1. The `RestoreController` creates the resource object on the target cluster. If the resource is a PV then the `RestoreController` will restore the PV data from the [durable snapshot](#durable-snapshot-pv-restore), [Restic](#restic-pv-restore), or [CSI snapshot](#csi-pv-restore) depending on how the PV was backed up.
|
||||
|
||||
If the resource already exists in the target cluster, which is determined by the Kubernetes API during resource creation, the `RestoreController` will skip the resource. The only [exception](#restore-existing-resource-policy) are Service Accounts, which Velero will attempt to merge differences between the backed up ServiceAccount into the ServiceAccount on the target cluster. You can [change the default existing resource restore policy](#restore-existing-resource-policy) to update resources instead of skipping them using the `--existing-resource-policy`.
|
||||
|
||||
1. Once the resource is created on the target cluster, Velero may take some additional steps or wait for additional processes to complete before moving onto the next resource to restore.
|
||||
|
||||
* If the resource is a Pod, the `RestoreController` will execute any [Restore Hooks](restore-hooks.md) and wait for the hook to finish.
|
||||
* If the resource is a PV restored by Restic, the `RestoreController` waits for Restic’s restore to complete. The `RestoreController` sets a timeout for any resources restored with Restic during a restore. The default timeout is 4 hours, but you can configure this be setting using `--restic-timeout` restore option.
|
||||
* If the resource is a Custom Resource Definition, the `RestoreController` waits for its availability in the cluster. The timeout is 1 minute.
|
||||
|
||||
If any failures happen finishing these steps, the `RestoreController` will log an error in the restore result and will continue restoring.
|
||||
|
||||
## Restore order
|
||||
|
||||
By default, Velero will restore resources in the following order:
|
||||
|
||||
* Custom Resource Definitions
|
||||
* Mamespaces
|
||||
* StorageClasses
|
||||
* VolumeSnapshotClass
|
||||
* VolumeSnapshotContents
|
||||
* VolumeSnapshots
|
||||
* PersistentVolumes
|
||||
* PersistentVolumeClaims
|
||||
* Secrets
|
||||
* ConfigMaps
|
||||
* ServiceAccounts
|
||||
* LimitRanges
|
||||
* Pods
|
||||
* ReplicaSets
|
||||
* Clusters
|
||||
* ClusterResourceSets
|
||||
|
||||
It's recommended that you use the default order for your restores. You are able to customize this order if you need to by setting the `--restore-resource-priorities` flag on the Velero server and specifying a different resource order. This customized order will apply to all future restores. You don't have to specify all resources in the `--restore-resource-priorities` flag. Velero will append resources not listed to the end of your customized list in alphabetical order.
|
||||
|
||||
```shell
|
||||
velero server \
|
||||
--restore-resource-priorities=customresourcedefinitions,namespaces,storageclasses,\
|
||||
volumesnapshotclass.snapshot.storage.k8s.io,volumesnapshotcontents.snapshot.storage.k8s.io,\
|
||||
volumesnapshots.snapshot.storage.k8s.io,persistentvolumes,persistentvolumeclaims,secrets,\
|
||||
configmaps,serviceaccounts,limitranges,pods,replicasets.apps,clusters.cluster.x-k8s.io,\
|
||||
clusterresourcesets.addons.cluster.x-k8s.io
|
||||
```
|
||||
|
||||
The clusters which are not explicitly specifying nodePorts still may need to restore original NodePorts in case of disaster. Auto assigned nodePorts most probably defined on Load Balancers which located front side of cluster. Changing all these nodePorts on Load Balancers is another operation complexity after disaster if nodePorts are changed.
|
||||
|
||||
Velero has a flag to let user deciding the preservation of nodePorts. **`velero restore create`** sub command has **`--preserve-nodeports`** flag to **preserve** Service nodePorts **always** regardless of nodePorts **explicitly specified** or **not**. This flag used for preserving the original nodePorts from backup and can be used as **`--preserve-nodeports`** or **`--preserve-nodeports=true`**
|
||||
## Restoring Persistent Volumes and Persistent Volume Claims
|
||||
|
||||
If this flag given and/or set to true, Velero does not remove the nodePorts when restoring Service and tries to use the nodePorts which written on backup.
|
||||
Velero has three approaches when restoring a PV, depending on how the backup was taken.
|
||||
|
||||
Trying to preserve nodePorts may cause **port conflicts** when restoring on situations below:
|
||||
1. When restoring a snapshot, Velero statically creates the PV and then binds it to a restored PVC. Velero's PV rename and remap process is used only in this case because this is the only case where Velero creates the PV resource directly.
|
||||
1. When restoring with Restic, Velero uses Kubernetes’ [dynamic provision process](https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/) to provision the PV after creating the PVC. In this case, the PV object is not actually created by Velero.
|
||||
1. When restoring with the [CSI plugin](csi.md), the PV is created from a CSI snapshot by the CSI driver. Velero doesn’t create the PV directly. Instead Velero creates a PVC with its DataSource referring to the CSI VolumeSnapshot object.
|
||||
|
||||
- If the nodePort from the backup already allocated on the target cluster then Velero prints error log as shown below and continue to restore operation.
|
||||
### Snapshot PV Restore
|
||||
|
||||
```
|
||||
time="2020-11-23T12:58:31+03:00" level=info msg="Executing item action for services" logSource="pkg/restore/restore.go:1002" restore=velero/test-with-3-svc-20201123125825
|
||||
PV data backed up by durable snapshots is restored by VolumeSnapshot plugins. Velero calls the plugins’ interface to create a volume from a snapshot. The plugin returns the volume’s `volumeID`. This ID is created by storage vendors and will be updated in the PV object created by Velero, so that the PV object is connected to the volume restored from a snapshot.
|
||||
|
||||
time="2020-11-23T12:58:31+03:00" level=info msg="Restoring Services with original NodePort(s)" cmd=_output/bin/linux/amd64/velero logSource="pkg/restore/service_action.go:61" pluginName=velero restore=velero/test-with-3-svc-20201123125825
|
||||
### Restic PV Restore
|
||||
|
||||
time="2020-11-23T12:58:31+03:00" level=info msg="Attempting to restore Service: hello-service" logSource="pkg/restore/restore.go:1107" restore=velero/test-with-3-svc-20201123125825
|
||||
For more information on Restic restores, see the [Restic integration](restic.md#restore) page.
|
||||
|
||||
time="2020-11-23T12:58:31+03:00" level=error msg="error restoring hello-service: Service \"hello-service\" is invalid: spec.ports[0].nodePort: Invalid value: 31536: provided port is already allocated" logSource="pkg/restore/restore.go:1170" restore=velero/test-with-3-svc-20201123125825
|
||||
```
|
||||
### CSI PV Restore
|
||||
|
||||
A PV backed up by CSI snapshots is restored by the [CSI plugin](csi). This happens when restoring the PVC object that has been snapshotted by CSI. The CSI VolumeSnapshot object name is specified with the PVC during backup as the annotation `velero.io/volume-snapshot-name`. After validating the VolumeSnapshot object, Velero updates the PVC by adding a `DataSource` field and setting its value to the VolumeSnapshot name.
|
||||
|
||||
### Persistent Volume Rename
|
||||
|
||||
- If the nodePort from the backup is not in the nodePort range of target cluster then Velero prints error log as below and continue to restore operation. Kubernetes default nodePort range is 30000-32767 but on the example cluster nodePort range is 20000-22767 and tried to restore Service with nodePort 31536
|
||||
When restoring PVs, if the PV being restored does not exist on the target cluster, Velero will create the PV using the name from the backup. Velero will rename a PV before restoring if both of the following conditions are met:
|
||||
|
||||
```
|
||||
time="2020-11-23T13:09:17+03:00" level=info msg="Executing item action for services" logSource="pkg/restore/restore.go:1002" restore=velero/test-with-3-svc-20201123130915
|
||||
1. The PV already exists on the target cluster.
|
||||
1. The PV’s claim namespace has been [remapped](#restoring-into-a-different-namespace).
|
||||
|
||||
time="2020-11-23T13:09:17+03:00" level=info msg="Restoring Services with original NodePort(s)" cmd=_output/bin/linux/amd64/velero logSource="pkg/restore/service_action.go:61" pluginName=velero restore=velero/test-with-3-svc-20201123130915
|
||||
If both conditions are met, Velero will create the PV with a new name. The new name is the prefix `velero-clone-` and a random UUID. Velero also preserves the original name of the PV by adding an annotation `velero.io/original-pv-name` to the restored PV object.
|
||||
|
||||
time="2020-11-23T13:09:17+03:00" level=info msg="Attempting to restore Service: hello-service" logSource="pkg/restore/restore.go:1107" restore=velero/test-with-3-svc-20201123130915
|
||||
If you attempt to restore the PV's referenced PVC into its original namespace without remapping the namespace, Velero will not rename the PV. If a PV's referenced PVC exists already for that namespace, the restored PV creation attempt will fail, with an `Already Exist` error from the Kubernetes API Server.
|
||||
|
||||
time="2020-11-23T13:09:17+03:00" level=error msg="error restoring hello-service: Service \"hello-service\" is invalid: spec.ports[0].nodePort: Invalid value: 31536: provided port is not in the valid range. The range of valid ports is 20000-22767" logSource="pkg/restore/restore.go:1170" restore=velero/test-with-3-svc-20201123130915
|
||||
```
|
||||
### PVC Restore
|
||||
|
||||
## Changing PV/PVC Storage Classes
|
||||
PVC objects are created the same way as other Kubernetes resources during a restore, with some specific changes:
|
||||
* For a dynamic binding PVCs, Velero removes the fields related to bindings from the PVC object. This enables the default Kubernetes [dynamic binding process](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#binding) to be used for this PVC. The fields include:
|
||||
* volumeName
|
||||
* pv.kubernetes.io/bind-completed annotation
|
||||
* pv.kubernetes.io/bound-by-controller annotation
|
||||
* For a PVC that is bound by Velero Restore, if the target PV has been renamed by the [PV restore process](#persistent-volume-rename), the RestoreController renames the `volumeName` field of the PVC object.
|
||||
|
||||
### Changing PV/PVC Storage Classes
|
||||
|
||||
Velero can change the storage class of persistent volumes and persistent volume claims during restores. To configure a storage class mapping, create a config map in the Velero namespace like the following:
|
||||
|
||||
|
|
@ -115,7 +170,7 @@ data:
|
|||
<old-storage-class>: <new-storage-class>
|
||||
```
|
||||
|
||||
## Changing PVC selected-node
|
||||
### Changing PVC selected-node
|
||||
|
||||
Velero can update the selected-node annotation of persistent volume claim during restores, if selected-node doesn't exist in the cluster then it will remove the selected-node annotation from PersistentVolumeClaim. To configure a node mapping, create a config map in the Velero namespace like the following:
|
||||
|
||||
|
|
@ -142,3 +197,76 @@ data:
|
|||
# node name and the value is the new node name.
|
||||
<old-node-name>: <new-node-name>
|
||||
```
|
||||
|
||||
## Restoring into a different namespace
|
||||
|
||||
Velero can restore resources into a different namespace than the one they were backed up from. To do this, use the `--namespace-mappings` flag:
|
||||
|
||||
```bash
|
||||
velero restore create <RESTORE_NAME> \
|
||||
--from-backup <BACKUP_NAME> \
|
||||
--namespace-mappings old-ns-1:new-ns-1,old-ns-2:new-ns-2
|
||||
```
|
||||
|
||||
For example, A Persistent Volume object has a reference to the Persistent Volume Claim’s namespace in the field `Spec.ClaimRef.Namespace`. If you specify that Velero should remap the target namespace during the restore, Velero will change the `Spec.ClaimRef.Namespace` field on the PV object from `old-ns-1` to `new-ns-1`.
|
||||
|
||||
## Restore existing resource policy
|
||||
|
||||
By default, Velero is configured to be non-destructive during a restore. This means that it will never overwrite data that already exists in your cluster. When Velero attempts to create a resource during a restore, the resource being restored is compared to the existing resources on the target cluster by the Kubernetes API Server. If the resource already exists in the target cluster, Velero skips restoring the current resource and moves onto the next resource to restore, without making any changes to the target cluster.
|
||||
|
||||
An exception to the default restore policy is ServiceAccounts. When restoring a ServiceAccount that already exists on the target cluster, Velero will attempt to merge the fields of the ServiceAccount from the backup into the existing ServiceAccount. Secrets and ImagePullSecrets are appended from the backed-up ServiceAccount. Velero adds any non-existing labels and annotations from the backed-up ServiceAccount to the existing resource, leaving the existing labels and annotations in place.
|
||||
|
||||
You can change this policy for a restore by using the `--existing-resource-policy` restore flag. The available options are `none` (default) and `update`. If you choose to `update` existing resources during a restore (`--existing-resource-policy=update`), Velero will attempt to update an existing resource to match the resource being restored:
|
||||
|
||||
* If the existing resource in the target cluster is the same as the resource Velero is attempting to restore, Velero will add a `velero.io/backup-name` label with the backup name and a `velero.io/restore-name` label with the restore name to the existing resource. If patching the labels fails, Velero adds a restore error and continues restoring the next resource.
|
||||
|
||||
* If the existing resource in the target cluster is different from the backup, Velero will first try to patch the existing resource to match the backup resource. If the patch is successful, Velero will add a `velero.io/backup-name` label with the backup name and a `velero.io/restore-name` label with the restore name to the existing resource. If the patch fails, Velero adds a restore warning and tries to add the `velero.io/backup-name` and `velero.io/restore-name` labels on the resource. If the labels patch also fails, then Velero logs a restore error and continues restoring the next resource.
|
||||
|
||||
You can also configure the existing resource policy in a [Restore](api-types/restore.md) object.
|
||||
|
||||
## Removing a Restore object
|
||||
|
||||
There are two ways to delete a Restore object:
|
||||
|
||||
1. Deleting with `velero restore delete` will delete the Custom Resource representing the restore, along with its individual log and results files. It will not delete any objects that were created by the restore in your cluster.
|
||||
2. Deleting with `kubectl -n velero delete restore` will delete the Custom Resource representing the restore. It will not delete restore log or results files from object storage, or any objects that were created during the restore in your cluster.
|
||||
|
||||
## What happens to NodePorts when restoring Services
|
||||
|
||||
During a restore, Velero deletes **Auto assigned** NodePorts by default and Services get new **auto assigned** nodePorts after restore.
|
||||
|
||||
Velero auto detects **explicitly specified** NodePorts using **`last-applied-config`** annotation and they are **preserved** after restore. NodePorts can be explicitly specified as `.spec.ports[*].nodePort` field on Service definition.
|
||||
|
||||
### Always Preserve NodePorts
|
||||
|
||||
It is not always possible to set nodePorts explicitly on some big clusters because of operational complexity. As the Kubernetes [NodePort documentation](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport) states, "if you want a specific port number, you can specify a value in the `nodePort` field. The control plane will either allocate you that port or report that the API transaction failed. This means that you need to take care of possible port collisions yourself. You also have to use a valid port number, one that's inside the range configured for NodePort use.""
|
||||
|
||||
The clusters which are not explicitly specifying nodePorts may still need to restore original NodePorts in the event of a disaster. Auto assigned nodePorts are typically defined on Load Balancers located in front of cluster. Changing all these nodePorts on Load Balancers is another operation complexity you are responsible for updating after disaster if nodePorts are changed.
|
||||
|
||||
Use the `velero restore create ` command's `--preserve-nodeports` flag to preserve Service nodePorts always, regardless of whether nodePorts are explicitly specified or not. This flag is used for preserving the original nodePorts from a backup and can be used as `--preserve-nodeports` or `--preserve-nodeports=true`. If this flag is present, Velero will not remove the nodePorts when restoring a Service, but will try to use the nodePorts from the backup.
|
||||
|
||||
Trying to preserve nodePorts may cause port conflicts when restoring on situations below:
|
||||
|
||||
- If the nodePort from the backup is already allocated on the target cluster then Velero prints error log as shown below and continues the restore operation.
|
||||
|
||||
```
|
||||
time="2020-11-23T12:58:31+03:00" level=info msg="Executing item action for services" logSource="pkg/restore/restore.go:1002" restore=velero/test-with-3-svc-20201123125825
|
||||
|
||||
time="2020-11-23T12:58:31+03:00" level=info msg="Restoring Services with original NodePort(s)" cmd=_output/bin/linux/amd64/velero logSource="pkg/restore/service_action.go:61" pluginName=velero restore=velero/test-with-3-svc-20201123125825
|
||||
|
||||
time="2020-11-23T12:58:31+03:00" level=info msg="Attempting to restore Service: hello-service" logSource="pkg/restore/restore.go:1107" restore=velero/test-with-3-svc-20201123125825
|
||||
|
||||
time="2020-11-23T12:58:31+03:00" level=error msg="error restoring hello-service: Service \"hello-service\" is invalid: spec.ports[0].nodePort: Invalid value: 31536: provided port is already allocated" logSource="pkg/restore/restore.go:1170" restore=velero/test-with-3-svc-20201123125825
|
||||
```
|
||||
|
||||
- If the nodePort from the backup is not in the nodePort range of target cluster then Velero prints error log as below and continues with the restore operation. Kubernetes default nodePort range is 30000-32767 but on the example cluster nodePort range is 20000-22767 and tried to restore Service with nodePort 31536.
|
||||
|
||||
```
|
||||
time="2020-11-23T13:09:17+03:00" level=info msg="Executing item action for services" logSource="pkg/restore/restore.go:1002" restore=velero/test-with-3-svc-20201123130915
|
||||
|
||||
time="2020-11-23T13:09:17+03:00" level=info msg="Restoring Services with original NodePort(s)" cmd=_output/bin/linux/amd64/velero logSource="pkg/restore/service_action.go:61" pluginName=velero restore=velero/test-with-3-svc-20201123130915
|
||||
|
||||
time="2020-11-23T13:09:17+03:00" level=info msg="Attempting to restore Service: hello-service" logSource="pkg/restore/restore.go:1107" restore=velero/test-with-3-svc-20201123130915
|
||||
|
||||
time="2020-11-23T13:09:17+03:00" level=error msg="error restoring hello-service: Service \"hello-service\" is invalid: spec.ports[0].nodePort: Invalid value: 31536: provided port is not in the valid range. The range of valid ports is 20000-22767" logSource="pkg/restore/restore.go:1170" restore=velero/test-with-3-svc-20201123130915
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in New Issue