The Velero team is excited to announce the launch of Velero v1.4.0! This release is one of our largest since v1.0.0, with many of our new features coming from community contributors.
Velero v1.4.0 now extends Velero’s support for snapshotting beyond Velero’s native VolumeSnapshotter plugins to include beta support for the Kubernetes Container Storage Interface volume snapshotting capabilities.
The Container Storage Interface (CSI) is a way for container orchestrators such as Kubernetes to provide a standard interface for storage systems, without having to create drivers for each orchestration system. While basic attach and detach volume operations are generally available in Kubernetes, the volume snapshotting APIs are still in beta. The Velero team is working with the Data Protection Working Group to ensure that the CSI snapshotting API specification is useful to end users and tool builders. We intend to trail behind the official Kubernetes support for the feature, entering general availability sometime after the feature is GA in Kubernetes itself.
Activating and using the CSI support in Velero will require enabling the EnableCSI feature flag and installing the
CSI plugin alongside the Velero server. For full details on installing and using the feature, see our
CSI beta page.
As a very brief example of the seamless integration of CSI into Velero. We will back up and restore a sample workload in the csi-app namespace that is using volumes backed by the CSI hostpath plugin driver. Installing and configuring the driver is outside the scope of this blog post, but we will cover the complete example in the future.
To backup this application, we run
$ velero backup create csi-b1 --include-namespaces csi-app --wait
Backup request "csi-b1" submitted successfully.
Waiting for backup to complete. You may safely press ctrl-c to stop waiting - your backup will continue in the background.
......
Backup completed with status: Completed. You may check for more information using the commands `velero backup describe csi-b1` and `velero backup logs csi-b1`.
Velero will detect the use of CSI volumes and invoke BackupItemAction plugins that create the CSI VolumeSnapshot and VolumesnapshotContents as part of the backup.
$ kubectl -n csi-app get volumesnapshot,volumesnapshotcontent -lvelero.io/backup-name=csi-b1 -oname
volumesnapshot.snapshot.storage.k8s.io/velero-csi-pvc-4277g
volumesnapshotcontent.snapshot.storage.k8s.io/snapcontent-bb3266bd-d36a-4e00-9ad0-bfbb98a073dd
Now to restore from this backup, we run
$ velero create restore --from-backup csi-b1 --wait
Restore request "csi-b1-20200515112009" submitted successfully.
Waiting for restore to complete. You may safely press ctrl-c to stop waiting - your restore will continue in the background.
Restore completed with status: Completed. You may check for more information using the commands `velero restore describe csi-b1-20200515112009` and `velero restore logs csi-b1-20200515112009`.
Velero will detect the CSI Snapshot API objects and invoke the RestoreItemAction plugins that create CSI VolumeSnapshotContent and statically bind to the VolumeSnapshot created during backup.
$ kubectl -n csi-app get volumesnapshot,volumesnapshotcontent -lvelero.io/restore-name=csi-b1-20200515112009 -oname
volumesnapshot.snapshot.storage.k8s.io/velero-csi-pvc-4277g
$ kubectl –n csi-app get volumesnapshot.snapshot.storage.k8s.io/velero-csi-pvc-4277g -ojson | jq .spec.source
{
"volumeSnapshotContentName": "velero-velero-csi-pvc-4277g-c6nz4"
}
Both the current Velero VolumeSnapshotter plugins and the CSI snapshotting support will be supported for the foreseeable future.
If you want to try this out and provide feedback, please install the CSI drivers and enable this feature in your testing environments. This will help both Velero and the Kubernetes communities improve data protection for everyone!
One thing users have asked for is that they would like to have more information about what’s happening during long-running backup operations. We’ve heard you! With v1.4.0, we’ve started building capabilities into Velero for tracking backup progress. To begin with, Velero will track the number of Kubernetes objects that are being processed in a running backup, and that number can be observed via the velero backup describe command, or by retrieving the backup custom resource.
This is just the beginning. We plan to further expand on backup progress reporting in future versions of Velero, especially around volume snapshot operations.
Since its inception, Velero has backed up and restored the Kubernetes API server’s preferred version of an API group. As Kubernetes evolves, however, this approach is causing backups to age out somewhat unexpectedly - as an example, in Kubernetes v1.16, the apps/v1beta1 API version was removed, making backups containing any Deployments in them unrestorable.
In order to remedy this, Rafael Brito from VMware has tackled the issue and reworked Velero’s backup logic and format. Velero v1.4.0 introduces a backwards-compatible change to the backup tarball format, in addition to a new change to the API discovery behavior that will back up all versions of each resource, rather than just the preferred version.
We’re currently experimenting with being able to restore different versions, as well as revisiting assumptions in the backup code that are now changed by this feature. If you’d like to try it out in the meantime, you can enable it with the EnableAPIGroupVersions feature flag. Be sure to provide feedback on
the issue if you interested, as well.
When deploying Velero on-premises, users have often asked for supporting a custom certificate authority. With Velero v1.4.0, this is now possible! Thanks to contributions from Samuel Lucidi and Dylan McMurray from Red Hat, Velero now supports using custom certificates for accessing object stores. For more information, please see the documentation on custom certificates.
Some users may have noticed that when restoring a backup containing CustomResourceDefinitions, the corresponding custom resources were not always restored. However, when running another restore, everything ran successfully.
With Velero v1.4.0, we’ve revisited our Kubernetes API server group discovery code and allowed the restore code to detect CustomResourceDefinition groups as they get restored, rather simply relying on time-based refreshes.
Some users of v1beta1 CustomResourceDefinitions were seeing issues with backing up and restoring the v1beta1 CustomResourceDefinitions with the Velero v1.3.x series.
Based on the user reports, we identified errors in how v1beta1 CustomResourceDefinitions were being handled at backup time. With Velero v1.4.0, v1beta1 CustomResourceDefinitions will be backed up correctly.
In order to keep up-to-date with our dependencies, we’ve moved our base container image from Ubuntu Bionic to Ubuntu Focal Fossa, the latest Long Term Support release that came out in April 2020. This brings our base installation more up-to-date, making it more secure and more maintainable.
Thanks again to all of our contributors who asked questions, filed issues, and wrote code for this release of Velero! We encourage you to try out these new features and provide feedback through our Slack channel or with an issue.
If you’d like to get involved, please join us during our online community meetings every Tuesday and catch up with past meetings on YouTube on the Velero Community Meetings playlist.
You can always find the latest project information at velero.io. Look for issues on GitHub marked Good first issue or Help wanted if you want to roll up your sleeves and write some code with us.
You can chat with us on Kubernetes Slack in the #velero channel and follow us on Twitter at @projectvelero.
To help you get started, see the documentation.