[BUG] The Helm chart `openziti-tunneler` version `v1.2.0` uses daemonset and ReadWriteOnce in PVC

[kinseii]

The Helm chart openziti-tunneler version v1.2.0 uses daemonset and ReadWriteOnce in PVC, which does not work together, since only one pod from the daemonset can connect to the PVC, and the rest of the pods will never start:

https://github.com/openziti/helm-charts/blob/main/charts/ziti-edge-tunnel/templates/daemonset.yaml
https://github.com/openziti/helm-charts/blob/main/charts/ziti-edge-tunnel/templates/identity-pvc.yaml#L7

I rolled back to version v1.1.1.

Please also set the key parameter to create a secret from --set-file zitiIdentity= and use the secret as a Volume.
For example: --set-file zitiIdentity=blablabla --set zitiIdentityVolume=secret or --set-file zitiIdentity=blablabla --set zitiIdentityVolume=pvc.

This way, the secret is created from the file without having to create it separately and is immediately mounted in the daemonset pods.

I can try to do some PR if that's welcome.

[qrkourier]

Hi there, @kinseii, and good find!

I don't see a Helm Chart named openziti-tunneler, and I think you're referring to the one you linked, ziti-edge-tunnel, which is the ZTHA node proxy implemented as a privileged daemonset.

I can see what you mean about the PVC access mode, and I'd welcome your pull request to make the PVC more configurable: storage class if defined, otherwise undefined, minimum size, access mode, etc.

I'm unsure about adding inputs for a wider variety of persistence methods, like Secret vs. PVC. I'd prefer to review those changes in a separate PR, if you'd like to send one for that piece.

For anyone looking for ways to proxy Ziti services in Kubernetes, there are different approaches for cluster-level proxy, node-level proxy, and pod-level proxy: https://openziti.io/docs/reference/tunnelers/kubernetes/