Using Helm, how do I configure the Helm Chart to automatically include the port forwarding?
Documentation I have seen so far indicate I create a Helm chart, I run ...
helm install myhelmchart... then forward the port manually...
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:80Define a job that is executed at a certain point in the lifecycle during helm install. The available hooks list also contains a post-install hook you are probably looking for. An example can be found in the official documentation.
You basically provide a Kubernetes Job, add necessary helm labels and then also an annotation like this:
apiVersion: ...
kind: ....
metadata:
annotations:
"helm.sh/hook": post-installImportant notes:
This job must use a container where kubectl is installed (check this example)
This job should look like this sample
A service account is associated to this job in order to run kubectl port-forward effectively.
Another general answer: https://stackoverflow.com/a/55078187/747579
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 kubectl apply and kubectl delete.
One trick you might find useful, though, is that kubectl port-forward can take things other than pod names as of kubectl 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
kubectl port-forward service/pouring-rat-nginx 8080:80I've found that kubectl port-forward works fine for lightweight testing and debugging and "if I send a curl request does it act the way I want". It also does things like routinely shut down after some idle time, and since it's 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 Her values.