I know this is an old question, but since there aren't yet any correct answers, and it's likely more people will face this issue in the future, here's my 2 cents:
You cannot download an original chart from a Kubernetes cluster, but what you can do is get all of the information that would be in said chart.
Helm creates a release secret (or configMap in Helm v2) which contains pretty much all information which was in the original chart. This is encoded, but we can make this readable.
First, go into the namespace where your install is, and run
kubectl get secrets
There will be a secret similar to this:
sh.helm.release.v1.<chart name>.v1
Provided you have sufficient access rights, you can access the contents of this secret. However, the contents have been Base64 encoded twice, and also gzipped. Hence, in order to create a readable file with all of the information you need, you can run this command:
kubectl get secret sh.helm.release.v1.<chart name>.v1 -o json | jq .data.release | tr -d '"' | base64 --decode | base64 --decode | gzip -d > output.json
Let's break this down a little.
kubectl get secret
gets the secret from the cluster
sh.helm.release.v1.<chart name>.v1
is the secret name we got by running kubectl get secrets
before
-o json
ensures we get a json output
jq .data.release
selects the part from the json output we actually want
tr -d '"'
deletes unnecessary "
characters for further processing
base64 --decode
decodes the base64 encoded data. we run this twice
gzip -d
unzips the resulting file
>output.json
ensures we write the resulting data to a file called output.json
for easier reading (otherwise you're looking at dozens to hundreds of lines of output on the terminal)
This results in a json file something like this:
{
"name": "chartName",
"info": {
"first_deployed": "2023-04-04T12:53:46.750501771Z",
"last_deployed": "2023-04-04T13:16:24.683772+02:00",
"deleted": "",
"description": "Upgrade complete",
"status": "deployed",
"notes": "this is a beautiful app for beautiful people"
},
"chart": {
"metadata": {
"name": "chartname",
"home": "link-to-homepage.com",
"sources": [
"https://github.com/link/to/source"
],
"version": "1.0.0",
"description": "this beautiful chart deploys a beautiful app for beautiful people",
"maintainers": [
{
"name": "john doe",
"email": "[email protected]"
},
{
"name": "jane doe",
"email": "[email protected]"
}
],
"icon": "link-to-icon.png",
"apiVersion": "v2",
"appVersion": "v1.0.0",
"annotations": {
"artifacthub.io/license": "Apache-2.0",
}
"dependencies": [
{
"name": "foo",
"version": "1.0.2",
"repository": "link-to-repo"
},
"type": "application"
},
"lock": null,
"templates": [
{
"name": "templates/configmap.yaml",
"data": "abc123"
},
{
"name": "templates/ingress.yaml",
"data": "abc123="
}],
"values": {
"foo": "bar"
"boolean": false
}
The dependencies
refer to Helm charts that the release you're looking at depends on.
The templates:
all specify a name
and data
. These names refer to the files that were originally in the Helm chart templates
folder, and the data
part is their contents (base64 encoded again).
The values:
section specifies whatever was in the Helm chart's values.yaml
file.
You can use these dependencies, templates and values to re-create the original Helm chart.
Note this is quite a labour-intensive way of retrieving the information, and it will cost quite a bit of time. However, it is to my knowledge the only way to retrieve this information from a cluster if the original Helm Chart is completely lost.