Istio 분석
네트워크 관점에서 마이크로 서비스 문제점
마이크로 서비스는 서비스간의 연결 구조가 복잡해서 서비스들이 서로 직접 호출하면 장애가 발생할 때 추적이 어렵고,
로드 밸련싱, 트래픽 관리, 인증, 권한 부여 등을 관리하는 것이 복잡해진다.
이러한 마이크로 서비스의 문제를 해결하기 위해 직접 서비스를 호출하는 것이 아니라
서비스 마다 프록시를 두고 프록시를 통해 서비스를 호출하면 트래픽을 통제할 수 있어서 마이크로 서비스의 문제를 해결할 수 있다.
마이크로 서비스의 네트워크 관리 오버헤드를 낮추기 위해 나온 아키텍처가 서비스메쉬(Service Mesh)이다.
이스티오
이스티오는 서비스 메시로 들어오고 나가는 트래픽을 관리하기 위한 게이트웨이를 제공하며,
플랫폼이나 소스코드 언어와 상관없이 서로 다른 마이크로 서비스를 연결하고 관리할 수 있고 트래픽 라우팅, 로드밸런싱, 서비스-서비스 간 인증, 모니터링 기능을 수행한다.
아키텍처
이스티오는 데이터 플레인과 컨트롤 프레인 두 개의 영역으로 구분되며,
데이터 플레인으로 엔보이 프록시를 사용하고 이스티오가 컨트롤 플레인을 담당한다.
컨트롤 플레인
서비스 메쉬 컨트롤러 구성
- Pilot(파일럿)
엔보이(envoy) 설정관리(서비스간 통신 및 트래픽 관리)
Policy 구성 - Mixer(믹서)
Telemetry 연동(각종 모니터링 지표의 수집)
Policy 체크(Service Mesh 전체에서 액세스 제어 및 정책 관리) - Citadel(시타델)
서비스 간의 인증 관리(누가 서비스에 접근할 수 있는지를 제어)
TLS(SSL)*암호화, 인증서 관리 - Galley(갤리)
이스티오 Configuration의 유효성 검사
SSL(Secure Sockets Layer): 데이터를 안전하게 전송하기 위한 인터넷 통신 프로토콜
TLS(Transport Layer Security): SSL의 차세대 버전으로 모든 종류의 인터넷 트래픽을 암호화
데이터 플레인
- 서비스 메쉬 구성
Envoy Proxy(엔보이 프록시)
:서비스간 통신 및 트래픽 제어
:URL 기반 라우팅(L7)
:로드밸런싱
:Dynamic Configuration
사이드카 프록시
프록시가 서비스 내부가 아니라 컨테이너와 분리된 사이드카(Sidecar) 형태로 실행되며
사이드카 프록시 간의 메쉬 네트워크를 형성하여
사이드카 프록시가 컨테이너를 대신하여 다른 서비스 간의 통신 및 트래픽을 제어한다.
이스티오 트래픽 관리 정책(Traffic Management)
1) Gateway
Ingress Gateway에 적용
에지 로드 밸런서 연결
서비스 메쉬로 들어오는 외부 트래픽 허용 정책설정(기본적으로 이스티오는 모든 외부 트래픽을 차단)
허용할 호스트 설정
허용할 프로토콜 , 포트 설정(HTTP:80)
2) VirtualService
Sidecar Proxy에 적용되며 Gateway 정책과 맵핑하여 설정
트래픽을 어디로 보낼지 라우팅 정책 설정
들어온 트래픽을 라우팅 규칙에 따라 적절한 서비스로 라우팅 하는 기능으로
쿠버네티스의 Service가 목적지가 되며, 실제로 Virtual Service의 기능은 URI 이나 Header 기반으로 라우팅을 하는 Ingress와 유사
가중치 비율을 적용하여 트래픽을 제어하는 기능 (A/B 테스트에 활용 가능)
3) DestinationRule
Sidecar Proxy에 적용되며 VirtualService 정책과 맵핑하여 설정
VirtualService가 라우팅해서 Service로 트래픽을 보내면, 실제로는 그 안에서 있는 Pod들에 라우팅이 되는데,
어느 Pod에 어떻게 트래픽을 보낼지 정의
서비스에 트랙픽을 보내더라도 Pod에 기술된 Label(subset)에 따라 서비스 내의 Pod를 골라서 트래픽을 보내거나, Pod간의 로드밸런싱 등 라우팅 정책 설정이 가능하다.
라우팅 이후에 적용 가능한 정책 설정
써킷 브레이커, 로드 밸런서 알고리즘, 최대 접속자수 등
4) ServiceEntry
Egress Gateway에 적용
외부로 나가는 트래픽 허용 정책 설정(기본적으로 이스티오는 모든 외부 트래픽을 차단)
허용할 프로토콜, 포트 설정 (HTTPS:443)
