helm: Helm 2 and 3 not able to deal with large releases
- Output of
helm version: 3.2.1 - Output of
kubectl version: 1.18.2 - Cloud Provider/Platform: kind
Helm install fails with
Error: create: failed to create: Request entity too large: limit is 3145728
I don’t have junk in my directory, I simply have a large chart where multiple people are managing their dashboards and this has grown beyond helm’s current ability to manage them. This issue has existed since helm version 2.
Previously reported in:
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 1
- Comments: 21 (5 by maintainers)
Commits related to this issue
- log if error has marker related to #8281 — committed to HenryFBP/helm by HenryFBP 2 years ago
- log if error has marker related to #8281 Signed-off-by: Henry <HenryFBP@gmail.com> — committed to HenryFBP/helm by HenryFBP 2 years ago
What about adding an annotation to the release secret, such as “continued-in: sh.helm.release.v1.release.v1.part2”. A solution like this seems like it would be reverse-compatible, requiring no changes for releases that fit within a single object.
+1 as i am getting the error when deploying prometheus-stack on cluster using helm Error: create: failed to create: the server responded with the status code 413 but did not return more information (post secrets)
In my opinion, Helm’s entire attraction is the simplicity of use. Since its tied to Kubernetes on the back-end, which is currently tied to etcd, working within the available limitations seems like the only sensible approach to me, which I why I would pursue storing a release across multiple keys as a reasonable solution.
Running a stateful workload on Kubernetes just to support large helm releases is not something that I would be encouraging my users to do. Similarly, bumping etcd storage to 10x or 100x would likely come with unreasonable down-sides for general cluster stabilty.
As it stands, I’m going to be dropping my use of helm in favour of an alternative release mechanism because that’s an out that I do have.
I’d be happy if there was some documentation provided that outlined the limitation of release sizes.
https://helm.sh/docs/topics/advanced/#storage-backends
We also managed to hit the limit. Probably due the use of secrets plugin, and adding multiple certificates in secrets.yaml etc.
In our case we dont require all the advanced features of helm (maybe in future), as we use helm as a templating tool and a release pipeline to deploy and rollback(redeploy old version)
For us adding a way to just disable the history, or just keep a simple summery in the history (e.g. command line used) would probably be a solution.
As to losing 3way merge, this gives us regular deployment failures, with immutable fields etc, and we now just delete objects (sometimes namespace) and re-deploy to fix helm deployment failures, so disabling/losing this could also be a benefit.