Envoy Proxy - 사이트 카
istio는 pod에 사이드 카 컨테이너 envoy proxy를 띄워서 서비스 네트워크 컨트롤하고 모니터링 한다고 합니다. 그럼 어떻게 컨트롤 하는거야 라는 의문 생기지 않나요?
istio 가 구성된 k8s에 pod를 띄울때 위에서 말씀드린 envoy proxy로 같이 구성되어 pod가 만들어지게 됩니다. 그때 envoy proxy는 iptables라는 linux 네트워킹 도구를 이용하여 패킹 필터링 시스템으로 패킷이 통과할때 어떻게 처리 될지 규칙을 설정 할 수 있습니다. 특정 주소로부터 오거나 특정 주소로 가는 패킷을 가로채서 다른 위치로 리디렉션하는 것이 가능합니다.
모든 pod는 이런식으로 구성되어 istio의 컨트롤 플레인에 의해 네트워트 트래픽이 관리되게 됩니다. itsio 컨트롤 플레인??
k8s의 컨트롤 플레인은 아는데 이건 또 뭐지? 싶었습니다.
Control, Data Plane (K8s, Istio)
istio가 구성된 k8s 환경에는
1. k8s 컨트롤 플레인 (etcd, api서버, 클러스터 관리 등)
2. istion 컨트롤 플레인 (Pilot, Citadel, Galley)
3. istio Data plane (envoy proxy 들)
이 존재 합니다.
여기서 2,3 컨트롤, 데이터 플레인은 istio의 서비스 메시의 논리적으로 구분지어 졌습니다. 데이터 플레인은 프록시들로 구성되어 있고 프록시들이 모든 pod 서비스 간의 모든 네트워크 통신을 중개하고 제어하며 네트워크 트래픽에 대한 텔레매트리를 수집하고 보고합니다.
Istio 의 네트워크 트래픽 관리
앞서 설명드린 Istio의 네트워크 관리에서 Virtual Services를 잠시 살펴봤었죠? 이번엔 제대로 한번 살펴 보겠습니다.
Virtual Service
가상 서비스는 목적지 규칙과 함께 Istio 트래픽 라우팅 기능의 핵심 구성 요소입니다. 가상 서비스를 사용하면 Istio와 플랫폼에서 제공하는 기본 연결 및 검색을 기반으로 요청이 Istio 서비스 메시 내의 서비스로 라우팅되는 방식을 구성할 수 있습니다. 각 가상 서비스는 순서대로 평가되는 일련의 라우팅 규칙으로 구성되며, Istio는 가상 서비스에 대한 각 요청을 메시 내의 특정 실제 대상과 일치시킬 수 있습니다. 사용 사례에 따라 메시에는 여러 가상 서비스가 필요하거나 가상 서비스가 필요하지 않을 수 있습니다.
가상 서비스를 정의하면, 그 정의는 Istio의 컨트롤 플레인에 의해 처리됩니다. 여기서 Pilot 컴포넌트는 이 라우팅 정보를 가져와서 Envoy 프록시들에게 전달합니다. Pilot는 Envoy 프록시들에게 어떤 요청을 어떻게 라우팅해야 하는지에 대한 정보를 제공합니다.
Envoy 프록시들은 이 정보를 받아서 자신의 로컬 트래픽을 관리합니다. 들어오는 요청이 있을 때, Envoy는 Pilot에서 받은 라우팅 규칙을 사용하여 요청을 어떤 서비스로 전달할지 결정합니다. 이 때 iptables 네트워킹 규칙을 통해 모든 네트워크 트래픽이 Envoy 프록시를 거치도록 함으로써, Envoy 프록시는 모든 네트워크 요청과 응답을 가로채고 제어할 수 있습니다.
따라서, 가상 서비스를 통해 라우팅 규칙을 설정하면, Istio의 컨트롤 플레인(Pilot)은 그 규칙을 Envoy 프록시들에게 전달하고, Envoy 프록시들은 그 규칙을 사용하여 각자의 네트워킹 트래픽을 제어합니다. 이는 서비스 메쉬 네트워크에서 트래픽 흐름을 세밀하게 제어할 수 있게 해주며, 트래픽 분할, 캔러리 릴리스, 장애 주입 등의 고급 라우팅 시나리오를 가능하게 합니다.
istio의 샘플 프로젝트로 실습을 진행 해보겠습니다.
실습
--- revies_VirtualService.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10--- revies_destinationRule.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2위 yaml virtualservice를 보시면 host: reviews 는 reviews deploy에 연결된 서비스를 가르키고 있습니다.
현재 review의 서비스는
로 되어 있습니다. 위 virtual service의 할당에 맞게 트래픽이 9:1 로 가는 모습을 볼 수 있습니다.
하지만 해당 기능은 virtual service만의 기능이라 할 수 없습니다 k8s service api에서 제공하는 httproute도 같은 기능을 제공할 수 있으니까요! 둘 다 HTTP 트래픽을 특정 서비스로 라우팅하는데 사용할 수 있지만 virtual service는 httproute에서 사용할 수 없는 고급 기능들이 존재합니다.
기본적인 차이점
HTTPRoute는 HTTP 요청의 경로와 호스트, 헤더 등에 따라 트래픽 라우팅을 할 수 있는 기능이 있습니다.
VS.
VirtualService 는 HTTP 요청의 경로뿐만 아니라 메소드, 헤드, URI등 다양한 요청 속성에 따라 트래픽을 라우팅 할 수 있습니다.
Virtual Service 의 고급 기능
1. Canary Deployments 는 트래픽의 일부를 새 버전의 서비스로 라우팅하여 Canary 배포를 수행할 수 있습니다.
2. Traffic Shifting 를 사용하면 트래픽을 서비스의 서로 다른 버전 또는 서비스셋 사이에서 쉽게 이동할 수 있습니다.(A/B) 테스팅
3. Fault Injection 를 사용하면 의도적으로 장애를 주입하여 서비스의 복원력을 테스트 할 수 있습니다.
