Bump the security group across 1 directory with 4 updates

[dependabot]

Bumps the security group with 3 updates in the / directory: github.com/vmware-tanzu/velero, k8s.io/api and k8s.io/client-go.

Updates github.com/vmware-tanzu/velero from 1.14.1 to 1.15.0

Release notes

Sourced from github.com/vmware-tanzu/velero's releases.

v1.15.0

v1.15

Download

https://github.com/vmware-tanzu/velero/releases/tag/v1.15.0

Container Image

velero/velero:v1.15.0

Documentation

https://velero.io/docs/v1.15/

Upgrading

https://velero.io/docs/v1.15/upgrade-to-1.15/

Highlights

Data mover micro service

Data transfer activities for CSI Snapshot Data Movement are moved from node-agent pods to dedicate backupPods or restorePods. This brings many benefits such as:

• This avoids to access volume data through host path, while host path access is privileged and may involve security escalations, which are concerned by users.
• This enables users to to control resource (i.e., cpu, memory) allocations in a granular manner, e.g., control them per backup/restore of a volume.
• This enhances the resilience, crash of one data movement activity won't affect others.
• This prevents unnecessary full backup because of host path changes after workload pods restart.
• For more information, check the design https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/vgdp-micro-service/vgdp-micro-service.md.

Item Block concepts and ItemBlockAction (IBA) plugin

Item Block concepts are introduced for resource backups to help to achieve multiple thread backups. Specifically, correlated resources are categorized in the same item block and item blocks could be processed concurrently in multiple threads.
ItemBlockAction plugin is introduced to help Velero to categorize resources into item blocks. At present, Velero provides built-in IBAs for pods and PVCs and Velero also supports customized IBAs for any resources.
In v1.15, Velero doesn't support multiple thread process of item blocks though item block concepts and IBA plugins are fully supported. The multiple thread support will be delivered in future releases.
For more information, check the design https://github.com/vmware-tanzu/velero/blob/main/design/backup-performance-improvements.md.

Node selection for repository maintenance job

Repository maintenance are resource consuming tasks, Velero now allows you to configure the nodes to run repository maintenance jobs, so that you can run repository maintenance jobs in idle nodes or avoid them to run in nodes hosting critical workloads.
To support the configuration, a new repository maintenance configuration configMap is introduced.
For more information, check the document https://velero.io/docs/v1.15/repository-maintenance/.

Backup PVC read-only configuration

In 1.15, Velero allows you to configure the data mover backupPods to read-only mount the backupPVCs. In this way, the data mover expose process could be significantly accelerated for some storages (i.e., ceph).
To support the configuration, a new backup PVC configuration configMap is introduced.
For more information, check the document https://velero.io/docs/v1.15/data-movement-backup-pvc-configuration/.

Backup PVC storage class configuration

In 1.15, Velero allows you to configure the storageclass used by the data mover backupPods. In this way, the provision of backupPVCs don't need to adhere to the same pattern as workload PVCs, e.g., for a backupPVC, it only needs one replica, whereas, the a workload PVC may have multiple replicas.
To support the configuration, the same backup PVC configuration configMap is used.
For more information, check the document https://velero.io/docs/v1.15/data-movement-backup-pvc-configuration/.

Backup repository data cache configuration

The backup repository may need to cache data on the client side during various repository operations, i.e., read, write, maintenance, etc. The cache consumes the root file system space of the pod where the repository access happens.
In 1.15, Velero allows you to configure the total size of the cache per repository. In this way, if your pod doesn't have enough space in its root file system, the pod won't be evicted due to running out of ephemeral storage.
To support the configuration, a new backup repository configuration configMap is introduced.
For more information, check the document https://velero.io/docs/v1.15/backup-repository-configuration/.

... (truncated)

Commits

• 1d4f147 Merge pull request #8349 from blackpiglet/fix_v1.15.0_migration_case_error
• 6f79c54 Fix the KIBISHII_DIRECTORY parameter not working issue.
• 15ee6a4 Refactor the code to get the plugin images for migration cases.
• d2dec9d Merge pull request #8336 from Lyndon-Li/release-1.15
• 7cd92a5 Pin the version of Golang and base image for v1.15.0
• 706dd13 Merge pull request #8330 from Lyndon-Li/1.15-change-log
• bdd231c Merge pull request #8333 from Lyndon-Li/add-1.15-doc
• 6ffe461 add 1.15 changelog
• 9f17fb3 add doc for 1.15
• 182478f Merge pull request #8332 from Lyndon-Li/fix-doc-index-for-1.15
• Additional commits viewable in compare view

Updates k8s.io/api from 0.31.1 to 0.31.3

Commits

• b7783ab Update dependencies to v0.31.3 tag
• See full diff in compare view

Updates k8s.io/apimachinery from 0.31.1 to 0.31.3

Commits

• See full diff in compare view

Updates k8s.io/client-go from 0.31.1 to 0.31.3

Commits

• ef98edc Update dependencies to v0.31.3 tag
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[dependabot]

Looks like these dependencies are updatable in another way, so this is no longer needed.