I get that. Would need to check if we can integrate Ziti into Traefik in the same way we did for Nginx (https://blog.openziti.io/nginx-zerotrust-api-security) and Caddy (https://blog.openziti.io/put-some-ziti-in-your-caddy), which we did respectively using the C and Golang SDKs. Therefore you wouldn't need to change your ingress, you would just load Ziti as a module in it.
Yeah, this is why I was thinking that the easiest way to integrate would be a sidecar (and in general for random web serving payloads). I'm not ruling it out, but this was the major stopper -- it seemed easier to just rely on Cilium/Calico underneath to keep east-west comms encrypted between apps and k8s nodes.
Clarification: You could use Traefik's ingress controller in tandem with a hypothetical OpenZiti ingress controller. You'd set `ingressClass: openziti` on those Ingress resources you wish OpenZiti to handle. Nothing would prevent you from creating two Ingress resources for the same ClusterIP service: one each for Traefik and OpenZiti.
Yeah Istio is a hard no for me... And yeah I definitely appreciate that OpenZiti does a lot more than service meshes do! I personally try to avoid service meshes (if I were to use one, I'd go with linkerd).
I'm just not convinced that many people need a service mesh -- I haven't really needed one yet, but maybe I'm just not at the right scale/etc.
> Oh, I should note too, while we have a bunch of ways to deploy OpenZiti on K8S today, we are in the process of building/releasing an admission controller and an ingress controller for OpenZiti.
This is awesome -- I really like my current admission controller though (Traefik), it's FANTASTIC. I think moving ingress controllers might be a large lift for people (it would be for me).
> Whats the project you work on?
I don't really work on it actively these days (haven't in a while) but https://nimbusws.com
Looking forward to picking it back up more actively in the future though, for now I use it for some small background services.