A
насколько я понимаю - сайдкары во внешних VMках нормальная практика, по крайней мере для миграции сервисов в кубер
https://istio.io/latest/blog/2020/workload-entry/
и еще из доки Se
к```ак понимаю - в случае MESH_EXTERNAL - политики применяются только на клиентских сервисах, но в случае с MESH_INTERNAL - политики применяются и на стороне сервера, что позволяет юзать mTLS из коробки, но без сайдкара - где эти политики будут? В целом отсюда и вопрос возник, т.е. политики должны куда то применяться и если нет сайдкара - то как они применятся на стороне сервера?
https://istio.io/latest/blog/2020/workload-entry/
If you wanted to migrate this service into Kubernetes in an active-active manner - i.e. launch a bunch of Pods, send a portion of the traffic to the Pods over Istio mutual TLS (mTLS) and send the rest to the VMs without sidecars - how would you do it? You would have needed to use a combination of a Kubernetes service, a virtual service, and a destination rule to achieve the behavior. Now, let’s say you decided to add sidecars to these VMs, one by one, such that you want only the traffic to the VMs with sidecars to use Istio mTLS. If any other Service Entry happens to include the same VM in its addresses, things start to get very complicated and error prone.
и еще из доки Se
rviceEntry.Location:
Wh```en communicating with services outside the mesh, Istio’s mTLS authentication is disabled, and policy enforcement is performed on the client-side as opposed to server-side.к```ак понимаю - в случае MESH_EXTERNAL - политики применяются только на клиентских сервисах, но в случае с MESH_INTERNAL - политики применяются и на стороне сервера, что позволяет юзать mTLS из коробки, но без сайдкара - где эти политики будут? В целом отсюда и вопрос возник, т.е. политики должны куда то применяться и если нет сайдкара - то как они применятся на стороне сервера?