Hi Matt! The chart is a hosting-only, non-intercepting pod and so you would use that to expose cluster workloads e.g. the k8s API, service domain name, etc… to Ziti clients as an alternative to using a k8s LB, ingress ctrl, or node IP. The sidecar is the proven method for intercepting pod egress, and it is also able to host services for which the server is reachable by the pod.
So, you have a couple of options here. You will need to run a sidecar for each pod that needs to reach the SQL server, and you could also host a service for those pods with the sidecar. If those services running in EKS span multiple namespaces or network security zones you could install the hosting pod with Helm once for each with endpoint identities for each. If all the services are in the same namespace or network security policy then you could host them all with a single pod deployed with Helm.
Let me know if I can clarify these better! Here’s a quick take video I’m working on about the hosting use case using the Helm chart. Would love your feedback on the docs or video if you’ve got it.