<p>Using Helm, how do I configure the Helm Chart to automatically include the port forwarding?  </p>

<p>Documentation I have seen so far indicate I create a Helm chart, I run ...</p>

<pre><code>helm install myhelmchart
</code></pre>

<p>... then forward the port manually...</p>

<pre><code>  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=myhelmchart,app.kubernetes.io/instance=pouring-rat" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl port-forward $POD_NAME 8080:80
</code></pre>

barrypicker
<p>You can't: Helm's operation is limited to using its template language to render some set of YAML files, and submitting them to the Kubernetes server.  It kind of only does <code>kubectl apply</code> and <code>kubectl delete</code>.</p>
<p>One trick you might find useful, though, is that <code>kubectl port-forward</code> can take things other than pod names as of <code>kubectl</code> 1.10 (and this is functionality in the client, if you have a very old cluster you just need a new enough client).  It will look up an appropriate pod name for you.  So you can</p>
<pre><code>kubectl port-forward service/pouring-rat-nginx 8080:80
</code></pre>
<p>I've found that <code>kubectl port-forward</code> works fine for lightweight testing and debugging and &quot;if I send a <code>curl</code> request does it act the way I want&quot;.  It also does things like routinely shut down after some idle time, and since it is tunneling TCP over HTTP it's not the fastest thing. Setting up a LoadBalancer-type service would be a better way to set up access from outside the cluster. Knobs like the type of service and any annotations you need to control the load balancer are good things to expose through Helm values.</p>
