I.e. even if the communication is entirely between components inside a k8s (or borg) cluster, it should be authenticated and encrypted.
In this model, there may be a reverse proxy at the edge of the cluster, but the communication between this service and the internal services wouls still be https. With systems like cert-manager it's also incredibly easy to supply every in-cluster process with a certificate form the cluster-internal CA.
-- Googler, not related to this project
Every component needs a different tls configuration, vs one time installing istio.
Raw TCP is supported by istio even with mtls, you just have to match in your VirtualServices on SNI instead of Host header.
We routinely mix tcp and http services on the same external ports, with mtls for both.
UDP I don’t really see how is relevant to a conversation on tls
I don't really understand your point; You're trying to say managing a single helm release for istio is more effort than (in my case, for example) manually managing around 40 TLS certificates (and yes, we have an in-house PKI with our own CA that issues via ACME/certbot etc also) and the services that use them? It's clearly not?
Just templating out the config files for e.g Cassandra or ES, or Redis or whatever component takes multiple x the effort of ./helm install istio.