<p>Helm does not launch pods to deploy your workloads. Helm locally renders the charts into standard Kubernetes manifests, and applies them. There is no server side component to Helm (since Helm 3).</p>
<p>If you want to get logs from deployed pods, do so with standard <code>kubectl logs</code> commands against the deployed pods. If you want to view what Helm is doing, use the <code>--debug</code> parameter to Helm, which will output the manifests that Helm applied.</p>

CC BY-SA 4.0
2022-07-24T08:20:48.017Z
2022-07-24T08:20:48.017Z
Kyanar
<p>On a Linux system with background jobs and kubectl installed, there is a DIY way.</p>
<p>Make sure that your pods get one or more metadata labels that uniquely identify the pods with a Helm chart version that you're installing.
Assuming it's the label <code>chart</code> and that it gets the value <code>mychart-1.0.1</code>, and that it's the only background job you're starting:</p>
<pre class="lang-sh prettyprint-override"><code>kubectl get pods --selector chart=mychart-1.0.1 --watch --output name &gt; new_pods.csv &amp;

helm install mychart --wait mychart-1.0.1.tgz

kill %1

while read pod || [ -n &quot;$pod&quot; ]; do
  kubectl logs $pod
done &lt; &lt;(sort -u new_pods.csv)
</code></pre>
<p><code>kubectl get pods ... --watch ... &amp;</code> starts a background job that continuously outputs pod names on pod events that belong to your chart version install.</p>
<p><code>helm install --wait</code> installs the chart and blocks.</p>
<p><code>kill %1</code> kills the background pod watch. I'm assuming here that that was the only background job you started. If you have more, you need to add a bit more complexity to find out the job id of the process.</p>
<p><code>while read pod ...</code> loops through the unique-ified file that the pod watch wrote to. <em>unique-ified</em>, because the pod watch printed the same name multiple times for every state change per pod, and you wouldn't want duplicate log prints of the same pod.</p>

CC BY-SA 4.0
2024-06-22T10:57:44.303Z
2024-06-22T10:57:44.303Z
K.Sy
<p>You can try a workaround by using the --wait flag with <code>helm install</code> or <code>helm upgrade</code>. This will cause the command to wait until the deployment is complete and all of the pods are ready, and then it will print the logs for the pods.</p>
<p>example: <code>helm install my-release my-chart --wait</code></p>
<p>This will install the chart and then wait until the deployment is complete before printing the logs for the pods.</p>
<p>You can also specify a timeout for the --wait flag, like so:</p>
<pre><code>helm install my-release my-chart --wait --timeout 600
</code></pre>
<p>This will wait up to 10 minutes for the deployment to complete before timing out and returning.</p>
<p>The catch is that the <code>--wait</code> flag only works if the chart being installed or upgraded has a Deployment or StatefulSet as the primary resource type. It will not work with other resource types such as DaemonSet or Job.</p>

CC BY-SA 4.0
2022-12-22T23:42:30.947Z
2022-12-22T23:42:30.947Z
unixoid
<p>Short answer: no. You would most likely run helm commands from your own workstation.</p>
<p>For those logs to be available through &quot;kubectl logs&quot;, you would have to start a Pod, executing your &quot;helm install&quot; command. Maybe using a Job. Although this also means having some ServiceAccount with enough privileges to install objects on behalf of Helm.</p>

CC BY-SA 4.0
2022-08-04T00:06:14.167Z
I need these logs to be available in CI/CD system. Developers should watch these logs without monitoring kubernetes pods manually.
Timur
CC BY-SA 4.0
2022-08-04T19:27:24.797Z
If going through logs in Kibana (assuming you have EFK) or pod logs is not enough: in my CI, logs of the commands executed during a job are collected in a file, which is then pushed, alongside other reports into some s3 bucket.
SYN
CC BY-SA 4.0
2022-08-07T04:42:03.247Z
As I understand, it is too hard to find necessary logs in  Kibana if use EFK (we use ELK, and these logs aren't so convenient).
I thought that the task is so simple. If the helm chart installation/upgrade is failed, I want to get logs of failed pods to stdout (or names of the failed pods).
Timur
CC BY-SA 4.0
2022-08-07T07:01:08.837Z
EFK is quite simple, you would need one filter: the name of your pipelinerun. to find back its logs. Now, as I already suggested: if your end-users are not up to the task of filtering based on a single field in Kibana: then, you need to keep those logs somewhere else. Eg: s3. And you can probably shut down your EFK, being too complicated and all, .. it still consumes a lot usually.
SYN
CC BY-SA 4.0
2023-02-11T22:59:09.277Z
the log search tools are just a super inefficient workarounds for this issue, 
sure its a solution but a very ugly one
U.V.
CC BY-SA 4.0
2023-02-12T07:20:11.853Z
dude... working for a bank/insurances compaty. I have terrabytes of logs, per day. One day, a customer asked, what happened to some image? With EFK/Kibana 40+ clusters, volumes you won't ever have to deal with, ... takes a few minutes. to figure out one of their jenkins did delete that object, 4 months prior they started complaining about it. Describing EFK by "too complcated" or "inefficient" : you  really need to sell this better, no one would believe you.
SYN
CC BY-SA 4.0
2022-07-17T17:58:01.873Z
2022-07-17T17:58:01.873Z
SYN
<p>Is it possible to print to <code>helm install</code> (or <code>helm upgrade</code>) output the logs of the deploying containers (logs that are available by <code>kubectl logs</code> command)?</p>

CC BY-SA 4.0
2023-02-11T22:53:17.123Z
I am currently working on a solution within our CI/CD system to do just that.
it is what everyone really needs: To get the log output of a helmChart deployment when it fails. The challenge is to connect the dots. * extract the names from the helmchart to create the parameters for a kubectl -wait process to connnect to the pod created by the helmchart deployment. I keep you posted....
U.V.
<kubernetes><helm>
Container logs for helm install
Timur
# Container logs for helm install

(Asked by: username_0 on 2022-07-06)

Is it possible to print to `helm install` (or `helm upgrade`) output the logs of the deploying containers (logs that are available by `kubectl logs` command)?

**Tags:** kubernetes, helm

> **Comments:**
> **username_1**: I am currently working on a solution within our CI/CD system to do just that. it is what everyone really needs: To get the log output of a helmChart deployment when it fails. The challenge is to connect the dots. * extract the names from the helmchart to create the parameters for a kubectl -wait process to connnect to the pod created by the helmchart deployment. I keep you posted....  

---

## 4 answers

### Answer by username_2 on 2022-07-24. Score: 1

Helm does not launch pods to deploy your workloads. Helm locally renders the charts into standard Kubernetes manifests, and applies them. There is no server side component to Helm (since Helm 3).

If you want to get logs from deployed pods, do so with standard `kubectl logs` commands against the deployed pods. If you want to view what Helm is doing, use the `--debug` parameter to Helm, which will output the manifests that Helm applied.


---

### Answer by username_3 on 2024-06-22. Score: 0

On a Linux system with background jobs and kubectl installed, there is a DIY way.
Make sure that your pods get one or more metadata labels that uniquely identify the pods with a Helm chart version that you're installing.
Assuming it's the label chart and that it gets the value mychart-1.0.1, and that it's the only background job you're starting:
kubectl get pods --selector chart=mychart-1.0.1 --watch --output name > new_pods.csv &

helm install mychart --wait mychart-1.0.1.tgz

kill %1

while read pod || [ -n "$pod" ]; do
  kubectl logs $pod
done < <(sort -u new_pods.csv)

kubectl get pods ... --watch ... & starts a background job that continuously outputs pod names on pod events that belong to your chart version install.
helm install --wait installs the chart and blocks.
kill %1 kills the background pod watch. I'm assuming here that that was the only background job you started. If you have more, you need to add a bit more complexity to find out the job id of the process.
while read pod ... loops through the unique-ified file that the pod watch wrote to. unique-ified, because the pod watch printed the same name multiple times for every state change per pod, and you wouldn't want duplicate log prints of the same pod.


---

### Answer by username_4 on 2022-12-22. Score: 0

You can try a workaround by using the --wait flag with helm install or helm upgrade. This will cause the command to wait until the deployment is complete and all of the pods are ready, and then it will print the logs for the pods.
example: helm install my-release my-chart --wait
This will install the chart and then wait until the deployment is complete before printing the logs for the pods.
You can also specify a timeout for the --wait flag, like so:
helm install my-release my-chart --wait --timeout 600

This will wait up to 10 minutes for the deployment to complete before timing out and returning.
The catch is that the --wait flag only works if the chart being installed or upgraded has a Deployment or StatefulSet as the primary resource type. It will not work with other resource types such as DaemonSet or Job.


---

### Answer by username_5 on 2022-07-17. Score: 0

Short answer: no. You would most likely run helm commands from your own workstation.

For those logs to be available through "kubectl logs", you would have to start a Pod, executing your "helm install" command. Maybe using a Job. Although this also means having some ServiceAccount with enough privileges to install objects on behalf of Helm.

> **Comments:**
> **username_0**: I need these logs to be available in CI/CD system. Developers should watch these logs without monitoring kubernetes pods manually.  
> **username_5**: If going through logs in Kibana (assuming you have EFK) or pod logs is not enough: in my CI, logs of the commands executed during a job are collected in a file, which is then pushed, alongside other reports into some s3 bucket.  
> **username_0**: As I understand, it is too hard to find necessary logs in  Kibana if use EFK (we use ELK, and these logs aren't so convenient). I thought that the task is so simple. If the helm chart installation/upgrade is failed, I want to get logs of failed pods to stdout (or names of the failed pods).  
> **username_5**: EFK is quite simple, you would need one filter: the name of your pipelinerun. to find back its logs. Now, as I already suggested: if your end-users are not up to the task of filtering based on a single field in Kibana: then, you need to keep those logs somewhere else. Eg: s3. And you can probably shut down your EFK, being too complicated and all, .. it still consumes a lot usually.  
> **username_1**: the log search tools are just a super inefficient workarounds for this issue,  sure its a solution but a very ugly one  
> **username_5**: dude... working for a bank/insurances compaty. I have terrabytes of logs, per day. One day, a customer asked, what happened to some image? With EFK/Kibana 40+ clusters, volumes you won't ever have to deal with, ... takes a few minutes. to figure out one of their jenkins did delete that object, 4 months prior they started complaining about it. Describing EFK by "too complcated" or "inefficient" : you  really need to sell this better, no one would believe you.  

---

