3 ms·
> You could use OpenZiti together with Cilium/Calico, there are some distros, eg., https://kubezt.com/ https://kubezt.com/ which do that (though in truth, KubeZ
by hardwaresofton 2y ago
> You could use OpenZiti together with Cilium/Calico, there are some distros, eg., https://kubezt.com/ https://kubezt.com/ which do that (though in truth, KubeZT has moved to Istio for E-W, uses OpenZiti for N-S. OpenZiti does a lot of things that service mesh technologies do not, for example, extending outside of the cluster (incl. to non-K8S workloads), allowing closing of inbound FW ports, providing a private DNS outside of cluster, removing the need for VPNs, L4 loadbalancers, MPLS, SDWAN, public DNS etc.
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 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.
- PLG88 2y agoAhh, thats cool. Note, the app embedded capabilities of OpenZiti becomes very interesting in this scenario, for example, our Python SDK working with Boto3 for AWS S3 - https://blog.openziti.io/extend-access-to-a-private-s3-bucket-using-python https://blog.openziti.io/extend-access-to-a-private-s3-bucke.... 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 https://blog.openziti.io/nginx-zerotrust-api-security) and Caddy (https://blog.openziti.io/put-some-ziti-in-your-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.
- hardwaresofton 2y ago> 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 https://blog.openziti.io/nginx-zerotrust-api-security) and Caddy (https://blog.openziti.io/put-some-ziti-in-your-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.
- qrkourier 2y ago> 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). 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.