You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the problem/challenge you have
The upgradeCRDs job just runs a couple of commands to get the latest CRDs from the velero binary and kubectl apply it in the cluster. It's a small short-lived operation. But if we look at the resource requests of the upgrade job pod, it's the same as the velero server pod which by default is high (500m CPU and 128Mi of memory). Requesting such a high amount of resources is worrisome for clusters which do not have that much of reserved space available. Testing on such clusters, we'can see the upgradeJob pod getting stuck and the upgrade never going through.
Describe the solution you'd like
We should make separate sections under resources for the velero server and the upgradeJob. The upgradeJob will have much lesser resource requirements than the velero server pod.
Here's a suggestion:
We cannot add another header in the pre-existing resources tab, because this can break CLI.
Anything else you would like to add:
I have already made this change and tested it in an Azure Kubernetes Service cluster with the least possible VM Sku. And the upgradeJob indeed succeeded with the lower resource requirements.
Environment:
helm version (use helm version):
helm chart version and app version (use helm list -n <YOUR NAMESPACE>):
Kubernetes version (use kubectl version):
Kubernetes installer & version:
Cloud provider or hardware configuration:
OS (e.g. from /etc/os-release):
The text was updated successfully, but these errors were encountered:
Describe the problem/challenge you have
The upgradeCRDs job just runs a couple of commands to get the latest CRDs from the velero binary and
kubectl apply
it in the cluster. It's a small short-lived operation. But if we look at the resource requests of the upgrade job pod, it's the same as the velero server pod which by default is high (500m CPU and 128Mi of memory). Requesting such a high amount of resources is worrisome for clusters which do not have that much of reserved space available. Testing on such clusters, we'can see the upgradeJob pod getting stuck and the upgrade never going through.Describe the solution you'd like
We should make separate sections under
resources
for the velero server and the upgradeJob. The upgradeJob will have much lesser resource requirements than the velero server pod.Here's a suggestion:
Pull Request: #514
We cannot add another header in the pre-existing
resources
tab, because this can break CLI.Anything else you would like to add:
I have already made this change and tested it in an Azure Kubernetes Service cluster with the least possible VM Sku. And the upgradeJob indeed succeeded with the lower resource requirements.
Environment:
helm version
):helm list -n <YOUR NAMESPACE>
):kubectl version
):/etc/os-release
):The text was updated successfully, but these errors were encountered: