We haven’t posted for while, but this deserves your attention! Last week during KubeCon Europe in Amsterdam we released Velero v1.11, which brings significant improvements in its functionality, flexibility, and performance. In this blog post, we will discuss the new features and changes that come with Velero v1.11 and how they can benefit users.
The theme of the v1.11 release is most definitely more flexibility, not only with the features added, but also in terms of the Velero contribution, development, and quality assurance processes.
In case you missed it we have new Product Manager - Pradeep Kumar Chaturvedi and few new contributors from companies like DELL and Microsoft.
This feature implements the BackupItemAction v2. BIA v2 has two new methods: Progress() and Cancel() and modifies the Execute() return value.
The API change is needed to facilitate long-running BackupItemAction plugin actions that may not be complete when the Execute() method returns. This will allow long-running BackupItemAction plugin actions to continue in the background while the Velero moves to the following plugin or the next item. https://github.com/vmware-tanzu/velero/pull/5442
This feature implemented the RestoreItemAction v2. RIA v2 has three new methods: Progress(), Cancel(), and AreAdditionalItemsReady(), and it modifies RestoreItemActionExecuteOutput() structure in the RIA return value.
The Progress() and Cancel() methods are needed to facilitate long-running RestoreItemAction plugin actions that may not be complete when the Execute() method returns. This will allow long-running RestoreItemAction plugin actions to continue in the background while the Velero moves to the following plugin or the next item. The AreAdditionalItemsReady() method is needed to allow plugins to tell Velero to wait until the returned additional items have been restored and are ready for use in the cluster before restoring the current item.
This is intended as a replacement for the previously-approved Upload Progress Monitoring design ( Upload Progress Monitoring) to expand the supported use cases beyond snapshot upload to include what was previously called Async Backup/Restore Item Actions.
This feature provides a flexible policy to filter volumes in the backup without requiring patching any labels or annotations to the pods or volumes. This policy is configured as k8s ConfigMap and maintained by the users themselves, and it can be extended to more scenarios in the future. By now, the policy rules out volumes from backup depending on the CSI driver, NFS setting, volume size, and StorageClass setting. Please refer to Resource policies rules for the policy’s ConifgMap format. It is not guaranteed to work on unofficial third-party plugins as it may not follow the existing backup workflow code logic of Velero.
This feature adds four new resource filters for backup. The new filters are separated into cluster scope and namespace scope. Before this feature, Velero could not filter cluster scope resources precisely. This feature provides the ability and refactors existing resource filter parameters.
velero install sub-command now includes a new parameter,
--service-account-name, which allows users to specify the ServiceAccountName for the Velero and node-agent pods. This feature may be particularly useful for users who utilize IRSA (IAM Roles for Service Accounts) in Amazon EKS (Elastic Kubernetes Service).”
In Velero, some code pieces need to communicate with the k8s API server. Before v1.11, these code pieces used hard-code timeout settings. This feature adds a resource-timeout parameter in the velero server binary to make it configurable.
Before this feature, Velero restore didn’t have a restored resources list as the Velero backup. It’s not convenient for users to learn what is restored. This feature adds the resources list and the handling result of the resources (including created, updated, failed, and skipped).
Before the Velero v1.11 release, users could not choose Velero’s backup describe command’s output format. The command output format is friendly for human reading, but it’s not a structured output, and it’s not easy for other programs to get information from it. Velero v1.11 adds a JSON format output for the backup describe command.
In v1.11, Backup Controller and Restore controller are refactored with controller-runtime. Till v1.11, all Velero controllers use the controller-runtime framework.
To fix CVEs and keep pace with Golang, Velero made changes as follows:
As we continue to grow our community of contributors, we want to lower the barrier to entry for making contributions to the Velero project. We’ve made huge improvements to the developer experience during this release cycle by introducing Tilt to the developer workflow. Using Tilt enables developers to make changes to Velero and its plugins, and have those changes automatically built and deployed to your cluster. This removes the need for any manual building or pushing of images, and provides a faster and much simpler workflow. Our Tilt configuration also enables contributors to more easily debug the Velero process using Delve, which has integrations with many editors and IDEs. If you would like to try it out, please see our documentation.
Velero is better because of our contributors and maintainers. It is because of you that we can bring great software to the community. Please join us during our online community meetings every Tuesday and catch up with past meetings on YouTube on the Velero Community Meetings playlist.
For opportunities to help and be helped, visit our Community Support Q&A on GitHub.
Orlin Vasilev Velero Community Lead
Photo by Markus Spiske on Unsplash