위 그림을 보면 기존 클러스터 내 서비스에 사이드카로 프록시를 붙이고, 이 프록시들이 트래픽 처리 담당 + istio control plane이 구성, 인증등은 일괄처리 하는 구조인 듯 하다.
https://istio.io/latest/docs/concepts/traffic-management/
기본적으로 istio 내부에서 모든 인바운드, 아웃바운드 트래픽을 처리하는 프록시는 Envoy 라고 한다.
메시 서비스가 송수신하는 모든 트래픽은 Envoy를 통해 프록시 처리된다. 따라서 실제 서비스를 변경하지 않고도 트래픽에 관련된 컨트롤이 가능하다.
관심사의 분리 패턴, 프록시 패턴이 적용되어있다.
가상 서비스를 이용하면 istio와 플랫폼에서 제공하는 기본 연결 및 검색 기능을 기반으로 istio 서비스 메시 내에서 요청이 서비스로 라우팅되는 방식을 구성할 수 있다.
가상 서비스가 없으면 이런일이 일어난다. Envoy는 모든 서비스 인스턴스간에 최소 요청 로드밸런싱을 통해 트래픽을 분산함. 근데 가상서비스가 있으면 하나 이상의 호스트 이름에 대한 트래픽의 규칙을 지정할 수 있음. 가상서비스에서 라우팅 규칙을 사용해 Envoy가 트래픽을 적절한 목적지로 보내는 방법을 지정할 수 있다.
쉽게 말하면 서비스 메시 내의 프록시들이 어떤 라우팅 규칙을 가져야 하는지 가상 서비스가 설정한다는 듯.
가상 서비스 사용하면 하위 집합으로 지정된 서비스의 여러 버전으로 트래픽을 보낼 수도 있다. 예를들어 요청의 20%는 새 버전의 호스트로 이동. 이런 규칙이 가능.
이렇게 새 서비스 버전으로 전송되는 트래픽 비율을 점진적으로 늘리는 카나리아 롤아웃도 가능. 이런 트래픽 라우팅은 인스턴스 배포와 완전히 별개로 이뤄짐. 왜? istio덕분에