vmware-tanzu
/
velero
mirror of https://github.com/vmware-tanzu/velero.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

update docs to include cpu/memory defaults for restic (#2772) 

* update docs to include cpu/memory defaults

Signed-off-by: Abigail McCarthy <mabigail@vmware.com>

* fixes from review

Signed-off-by: Abigail McCarthy <mabigail@vmware.com>

* updates from review

Signed-off-by: Abigail McCarthy <mabigail@vmware.com>

* update to use kubectl patch command

Signed-off-by: Abigail McCarthy <mabigail@vmware.com>

* update typos and add changes to 1.4 docs

Signed-off-by: Abigail McCarthy <mabigail@vmware.com>
pull/2807/head
Abigail McCarthy 2020-08-10 12:38:35 -04:00 committed by GitHub
parent 6edf279bd8
commit 4364a813c1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 182 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
site/docs/main/customize-installation.md
View File

@ -10,6 +10,8 @@
- [Enable server side features](#enable-server-side-features)
- [Enable client side features](#enable-client-side-features)
- [Customize resource requests and limits](#customize-resource-requests-and-limits)
- [Install with custom resource requests and limits](#install-with-custom-resource-requests-and-limits)
- [Update resource requests and limits after install](#update-resource-requests-and-limits-after-install)
- [Configure more than one storage location for backups or volume snapshots](#configure-more-than-one-storage-location-for-backups-or-volume-snapshots)
- [Do not configure a backup storage location during install](#do-not-configure-a-backup-storage-location-during-install)
- [Install an additional volume snapshot provider](#install-an-additional-volume-snapshot-provider)
@ -95,10 +97,76 @@ velero client config set features=
## Customize resource requests and limits
By default, the Velero deployment requests 500m CPU, 128Mi memory and sets a limit of 1000m CPU, 256Mi.
Default requests and limits are not set for the restic pods as CPU/Memory usage can depend heavily on the size of volumes being backed up.
At installation, Velero sets default resource requests and limits for the Velero pod and the restic pod, if you using the [restic integration](/docs/main/restic/).
Customization of these resource requests and limits may be performed using the [velero install][6] CLI command.
<table caption="Velero Customize resource requests and limits defaults" >
<tr><th>Setting</th><th>Velero pod defaults</th><th>restic pod defaults</th></tr>
<tr><td>CPU request</td><td>500m</td><td>500m</td></tr>
<tr><td>Memory requests</td><td>128Mi</td><td>512Mi</td></tr>
<tr><td>CPU limit</td><td>1000m (1 CPU)</td><td>1000m (1 CPU)</td></tr>
<tr><td>Memory limit</td><td>256Mi</td><td>1024Mi</td></tr>
</table>
### Install with custom resource requests and limits
You can customize these resource requests and limit when you first install using the [velero install][6] CLI command.
```
velero install \
--velero-pod-cpu-request <CPU_REQUEST> \
--velero-pod-mem-request <MEMORY_REQUEST> \
--velero-pod-cpu-limit <CPU_LIMIT> \
--velero-pod-mem-limit <MEMORY_LIMIT> \
[--use-restic] \
[--default-volumes-to-restic] \
[--restic-pod-cpu-request <CPU_REQUEST>] \
[--restic-pod-mem-request <MEMORY_REQUEST>] \
[--restic-pod-cpu-limit <CPU_LIMIT>] \
[--restic-pod-mem-limit <MEMORY_LIMIT>]
```
### Update resource requests and limits after install
After installation you can adjust the resource requests and limits in the Velero Deployment spec or restic DeamonSet spec, if you are using the restic integration.
**Velero pod**
Update the `spec.template.spec.containers.resources.limits` and `spec.template.spec.containers.resources.requests` values in the Velero deployment.
```bash
kubectl patch deployment velero -n velero --patch \
'{"spec":{"template":{"spec":{"containers":[{"name": "velero", "resources": {"limits":{"cpu": "1", "memory": "256Mi"}, "requests": {"cpu": "1", "memory": "128Mi"}}}]}}}}'
```
**restic pod**
Update the `spec.template.spec.containers.resources.limits` and `spec.template.spec.containers.resources.requests` values in the restic DeamonSet spec.
```bash
kubectl patch daemonset restic -n velero --patch \
'{"spec":{"template":{"spec":{"containers":[{"name": "restic", "resources": {"limits":{"cpu": "1", "memory": "1024Mi"}, "requests": {"cpu": "1", "memory": "512Mi"}}}]}}}}'
```
Additionally, you may want to update the the default Velero restic pod operation timeout (default 240 minutes) to allow larger backups more time to complete. You can adjust this timeout by adding the `- --restic-timeout` argument to the Velero Deployment spec.
**NOTE:** Changes made to this timeout value will revert back to the default value if you re-run the Velero install command.
1. Open the Velero Deployment spec.
```
kubectl edit deploy velero -n velero
```
1. Add `- --restic-timeout` to `spec.template.spec.containers`.
```yaml
spec:
template:
spec:
containers:
- args:
- --restic-timeout=240m
```
## Configure more than one storage location for backups or volume snapshots

60
site/docs/main/restic.md
View File

@ -1,40 +1,47 @@
# Restic Integration
Velero has support for backing up and restoring Kubernetes volumes using a free open-source backup tool called [restic][1]. This support is considered beta quality. Please see the list of [limitations](#limitations) to understand if it currently fits your use case.
Velero supports backing up and restoring Kubernetes volumes using a free open-source backup tool called [restic][1]. This support is considered beta quality. Please see the list of [limitations](#limitations) to understand if it currently fits your use case.
Velero has always allowed you to take snapshots of persistent volumes as part of your backups if you’re using one of
Velero allows you to take snapshots of persistent volumes as part of your backups if you’re using one of
the supported cloud providers’ block storage offerings (Amazon EBS Volumes, Azure Managed Disks, Google Persistent Disks).
We also provide a plugin model that enables anyone to implement additional object and block storage backends, outside the
It also provides a plugin model that enables anyone to implement additional object and block storage backends, outside the
main Velero repository.
We integrated restic with Velero so that users have an out-of-the-box solution for backing up and restoring almost any type of Kubernetes
volume*. This is a new capability for Velero, not a replacement for existing functionality. If you're running on AWS, and
taking EBS snapshots as part of your regular Velero backups, there's no need to switch to using restic. However, if you've
been waiting for a snapshot plugin for your storage platform, or if you're using EFS, AzureFile, NFS, emptyDir,
The restic intergation was added to give you an out-of-the-box solution for backing up and restoring almost any type of Kubernetes volume. This integration is an addition to Velero's capabilities, not a replacement for existing functionality. If you're running on AWS, and taking EBS snapshots as part of your regular Velero backups, there's no need to switch to using restic. However, if you need a volume snapshot plugin for your storage platform, or if you're using EFS, AzureFile, NFS, emptyDir,
local, or any other volume type that doesn't have a native snapshot concept, restic might be for you.
Restic is not tied to a specific storage platform, which means that this integration also paves the way for future work to enable
cross-volume-type data migrations. Stay tuned as this evolves!
cross-volume-type data migrations.
\* hostPath volumes are not supported, but the [new local volume type][4] is supported.
**NOTE:** hostPath volumes are not supported, but the [local volume type][4] is supported.
## Setup
## Setup restic
### Prerequisites
- Velero's restic integration requires the Kubernetes [MountPropagation feature][6], which is enabled by default in Kubernetes v1.10.0 and later.
- Understand how Velero performs [backups with the restic integration](#how-backup-and-restore-work-with-restic).
- [Download][3] the latest Velero release.
- Kubernetes v1.10.0 and later. Velero's restic integration requires the Kubernetes [MountPropagation feature][6], which is enabled by default in Kubernetes v1.10.0 and later.
### Instructions
### Install restic
Ensure you've [downloaded latest release][3].
To install restic, use the `--use-restic` flag in the `velero install` command. See the [install overview][2] for more details on other flags for the install command.
To install restic, use the `--use-restic` flag on the `velero install` command. See the [install overview][2] for more details. When using restic on a storage provider that doesn't currently have Velero support for snapshots, the `--use-volume-snapshots=false` flag prevents an unused `VolumeSnapshotLocation` from being created on installation.
```
velero install --use-restic
```
When using restic on a storage provider that doesn't currently have Velero support for snapshots, the `--use-volume-snapshots=false` flag prevents an unused `VolumeSnapshotLocation` from being created on installation.
### Configure restic DaemonSet spec
After installation, some PaaS/CaaS platforms based on Kubernetes also require modifications the restic DaemonSet spec. The steps in this section are only needed if you are installing on RancherOS, OpenShift, VMware Tanzu Kubernetes Grid Integrated Edition (formerly VMware Enterprise PKS), or Micrsoft Azure.
Please note: For some PaaS/CaaS platforms based on Kubernetes such as RancherOS, OpenShift and Enterprise PKS, some modifications are required to the restic DaemonSet spec.
**RancherOS**
The host path for volumes is not `/var/lib/kubelet/pods`, rather it is `/opt/rke/var/lib/kubelet/pods`
Update the host path for volumes in the restic DaemonSet in the Velero namespace from `/var/lib/kubelet/pods` to `/opt/rke/var/lib/kubelet/pods`.
```yaml
hostPath:
@ -48,9 +55,11 @@ hostPath:
path: /opt/rke/var/lib/kubelet/pods
```
**OpenShift**
The restic containers should be running in a `privileged` mode to be able to mount the correct hostpath to pods volumes.
To mount the correct hostpath to pods volumes, run the restic pod in `privileged` mode.
1. Add the `velero` ServiceAccount to the `privileged` SCC:
@ -58,7 +67,7 @@ The restic containers should be running in a `privileged` mode to be able to mou
$ oc adm policy add-scc-to-user privileged -z velero -n velero
```
2. For OpenShift version >= `4.1`, Modify the DaemonSet yaml to request a privileged mode:
2. For OpenShift version >= `4.1`, modify the DaemonSet yaml to request a privileged mode:
```diff
@@ -67,3 +67,5 @@ spec:
@ -78,7 +87,7 @@ The restic containers should be running in a `privileged` mode to be able to mou
-p '[{"op":"add","path":"/spec/template/spec/containers/0/securityContext","value": { "privileged": true}}]'
```
3. For OpenShift version < `4.1`, Modify the DaemonSet yaml to request a privileged mode and mount the correct hostpath to pods volumes.
3. For OpenShift version < `4.1`, modify the DaemonSet yaml to request a privileged mode and mount the correct hostpath to pods volumes.
```diff
@@ -35,7 +35,7 @@ spec:
@ -98,7 +107,7 @@ The restic containers should be running in a `privileged` mode to be able to mou
+ privileged: true
```
or
or
```shell
oc patch ds/restic \
@ -133,7 +142,7 @@ oc annotate namespace <velero namespace> openshift.io/node-selector=""
oc create -n <velero namespace> -f ds.yaml
```
**Enterprise PKS**
**VMware Tanzu Kubernetes Grid Integrated Edition (formerly VMware Enterprise PKS)**
You need to enable the `Allow Privileged` option in your plan configuration so that restic is able to mount the hostpath.
@ -144,6 +153,7 @@ hostPath:
path: /var/vcap/data/kubelet/pods
```
**Microsoft Azure**
If you are using [Azure Files][8], you need to add `nouser_xattr` to your storage class's `mountOptions`. See [this restic issue][9] for more details.
@ -156,7 +166,6 @@ kubectl patch storageclass/<YOUR_AZURE_FILE_STORAGE_CLASS_NAME> \
--patch '[{"op":"add","path":"/mountOptions/-","value":"nouser_xattr"}]'
```
You're now ready to use Velero with restic.
## To back up
@ -328,12 +337,13 @@ PVCs, such as `emptyDir` volumes, when a pod is deleted/recreated (e.g. by a Rep
volumes will be full rather than incremental, because the pod volume's lifecycle is assumed to be defined by its pod.
- Restic scans each file in a single thread. This means that large files (such as ones storing a database) will take a long time to scan for data deduplication, even if the actual
difference is small.
- If you plan to use the Velero restic integration to backup 100GB of data or more, you may need to [customize the resource limits](/docs/main/customize-installation/#customize-resource-requests-and-limits) to make sure backups complete successfully.
## Customize Restore Helper Container
Velero uses a helper init container when performing a restic restore. By default, the image for this container is `velero/velero-restic-restore-helper:<VERSION>`,
where `VERSION` matches the version/tag of the main Velero image. You can customize the image that is used for this helper by creating a ConfigMap in the Velero namespace with
the alternate image.
the alternate image.
In addition, you can customize the resource requirements for the init container, should you need.
@ -367,7 +377,7 @@ data:
# "cpuRequest" sets the request.cpu value on the restic init containers during restore.
# If not set, it will default to "100m". A value of "0" is treated as unbounded.
cpuRequest: 200m
# "memRequest" sets the request.memory value on the restic init containers during restore.
# If not set, it will default to "128Mi". A value of "0" is treated as unbounded.
memRequest: 128Mi
@ -375,7 +385,7 @@ data:
# "cpuLimit" sets the request.cpu value on the restic init containers during restore.
# If not set, it will default to "100m". A value of "0" is treated as unbounded.
cpuLimit: 200m
# "memLimit" sets the request.memory value on the restic init containers during restore.
# If not set, it will default to "128Mi". A value of "0" is treated as unbounded.
memLimit: 128Mi

74
site/docs/v1.4/customize-installation.md
View File

@ -9,6 +9,8 @@
- [Enable server side features](#enable-server-side-features)
- [Enable client side features](#enable-client-side-features)
- [Customize resource requests and limits](#customize-resource-requests-and-limits)
- [Install with custom resource requests and limits](#install-with-custom-resource-requests-and-limits)
- [Update resource requests and limits after install](#update-resource-requests-and-limits-after-install)
- [Configure more than one storage location for backups or volume snapshots](#configure-more-than-one-storage-location-for-backups-or-volume-snapshots)
- [Do not configure a backup storage location during install](#do-not-configure-a-backup-storage-location-during-install)
- [Install an additional volume snapshot provider](#install-an-additional-volume-snapshot-provider)
@ -86,10 +88,76 @@ velero client config set features=
## Customize resource requests and limits
By default, the Velero deployment requests 500m CPU, 128Mi memory and sets a limit of 1000m CPU, 256Mi.
Default requests and limits are not set for the restic pods as CPU/Memory usage can depend heavily on the size of volumes being backed up.
At installation, Velero sets default resource requests and limits for the Velero pod and the restic pod, if you using the [restic integration](/docs/main/restic/). In Velero versions before 1.4.2, restic pod defaults were not set at install.
Customization of these resource requests and limits may be performed using the [velero install][6] CLI command.
<table caption="Velero Customize resource requests and limits defaults" >
<tr><th>Setting</th><th>Velero pod defaults</th><th>restic pod defaults (Velero 1.4.2 and later)</th></tr>
<tr><td>CPU request</td><td>500m</td><td>500m</td></tr>
<tr><td>Memory requests</td><td>128Mi</td><td>512Mi</td></tr>
<tr><td>CPU limit</td><td>1000m (1 CPU)</td><td>1000m (1 CPU)</td></tr>
<tr><td>Memory limit</td><td>256Mi</td><td>1024Mi</td></tr>
</table>
### Install with custom resource requests and limits
You can customize these resource requests and limit when you first install using the [velero install][6] CLI command.
```
velero install \
--velero-pod-cpu-request <CPU_REQUEST> \
--velero-pod-mem-request <MEMORY_REQUEST> \
--velero-pod-cpu-limit <CPU_LIMIT> \
--velero-pod-mem-limit <MEMORY_LIMIT> \
[--use-restic] \
[--default-volumes-to-restic] \
[--restic-pod-cpu-request <CPU_REQUEST>] \
[--restic-pod-mem-request <MEMORY_REQUEST>] \
[--restic-pod-cpu-limit <CPU_LIMIT>] \
[--restic-pod-mem-limit <MEMORY_LIMIT>]
```
### Update resource requests and limits after install
After installation you can adjust the resource requests and limits in the Velero Deployment spec or restic DeamonSet spec, if you are using the restic integration.
**Velero pod**
Update the `spec.template.spec.containers.resources.limits` and `spec.template.spec.containers.resources.requests` values in the Velero deployment.
```bash
kubectl patch deployment velero -n velero --patch \
'{"spec":{"template":{"spec":{"containers":[{"name": "velero", "resources": {"limits":{"cpu": "1", "memory": "256Mi"}, "requests": {"cpu": "1", "memory": "128Mi"}}}]}}}}'
```
**restic pod**
Update the `spec.template.spec.containers.resources.limits` and `spec.template.spec.containers.resources.requests` values in the restic DeamonSet spec.
```bash
kubectl patch daemonset restic -n velero --patch \
'{"spec":{"template":{"spec":{"containers":[{"name": "restic", "resources": {"limits":{"cpu": "1", "memory": "1024Mi"}, "requests": {"cpu": "1", "memory": "512Mi"}}}]}}}}'
```
Additionally, you may want to update the the default Velero restic pod operation timeout to allow larger backups more time to complete. You can adjust this timeout by adding the `- --restic-timeout` argument to the Velero Deployment spec. The default is 60 minutes in Velero versions before 1.4.2, and 240 minutes in Velero 1.4.2 and later.
**NOTE:** Changes made to this timeout value will revert back to the default value if you re-run the Velero install command.
1. Open the Velero Deployment spec.
```
kubectl edit deploy velero -n velero
```
1. Add `- --restic-timeout` to `spec.template.spec.containers.args`.
```yaml
spec:
template:
spec:
containers:
- args:
- --restic-timeout=240m
```
## Configure more than one storage location for backups or volume snapshots

9
site/docs/v1.4/restic.md
View File

@ -98,7 +98,7 @@ The restic containers should be running in a `privileged` mode to be able to mou
+ privileged: true
```
or
or
```shell
oc patch ds/restic \
@ -246,12 +246,13 @@ PVCs, such as `emptyDir` volumes, when a pod is deleted/recreated (e.g. by a Rep
volumes will be full rather than incremental, because the pod volume's lifecycle is assumed to be defined by its pod.
- Restic scans each file in a single thread. This means that large files (such as ones storing a database) will take a long time to scan for data deduplication, even if the actual
difference is small.
- If you plan to use the Velero restic integration to backup 100GB of data or more, you may need to [customize the resource limits](/docs/main/customize-installation/#customize-resource-requests-and-limits) to make sure backups complete successfully.
## Customize Restore Helper Container
Velero uses a helper init container when performing a restic restore. By default, the image for this container is `velero/velero-restic-restore-helper:<VERSION>`,
where `VERSION` matches the version/tag of the main Velero image. You can customize the image that is used for this helper by creating a ConfigMap in the Velero namespace with
the alternate image.
the alternate image.
In addition, you can customize the resource requirements for the init container, should you need.
@ -285,7 +286,7 @@ data:
# "cpuRequest" sets the request.cpu value on the restic init containers during restore.
# If not set, it will default to "100m". A value of "0" is treated as unbounded.
cpuRequest: 200m
# "memRequest" sets the request.memory value on the restic init containers during restore.
# If not set, it will default to "128Mi". A value of "0" is treated as unbounded.
memRequest: 128Mi
@ -293,7 +294,7 @@ data:
# "cpuLimit" sets the request.cpu value on the restic init containers during restore.
# If not set, it will default to "100m". A value of "0" is treated as unbounded.
cpuLimit: 200m
# "memLimit" sets the request.memory value on the restic init containers during restore.
# If not set, it will default to "128Mi". A value of "0" is treated as unbounded.
memLimit: 128Mi