Istio를 도입하면 쿠버네티스에서 할 수 없는 분산 서비스 (Service Mesh) 관리에 용이합니다.
MicroService Architecture의분산 네트워크 환경(Kubernetes)에서 각 app들의 네트워크 연결을 쉽게설정할 수 있도록 지원하는 기술입니다.
한가지 명확하게 이해해야 할 것으로 Service Mesh는 kubernete에 종속( 또는 관련)된 기술이 아니며, 소프트웨어로 네트워크 설정을 쉽게 할 수 있도록 해당 클러스터에 추가되는 별도의 소프트웨어 레이어입니다.
Istio는 Envoy를 Data Plane으로 사용하고 이를 control해주는 오픈 소스 솔루션입니다. - Envoy를 이용해서Service Mash를 구현하기 위해서는 Envoy로 구성된 Data Plane을 control할 솔루션이 필요합니다.
-> Service Mesh를 활용한 네트워크 구성시 장점 Service Discovery, 써킷브레이커, 히스트릭스, 기타 연동등이 쉬움..!!
Istio Architecture
Istio는 Data Plane과 Control Plane으로 구성되어 있습니다. 위의 그림처럼 istiod는 Control Plane를 수행하며, Data Plane는 서비스에 envoy로 inject되어 있습니다.
현재 istiod는 Mixer 가 없어지고, Pilot 이 Mixer 의 기능까지도 함께 수행하는 것으로 되어 있습니다.
Istio의 세부 구조
1. Data Plane
실제로 트래픽을 받아 처리해주는 파트다.
Service의 Sidecar 형태로 구성된 Proxy들을 가리킨다.
Data Plane은 Control Plane에 의해 통제된다.
Istio에서는 envoy를 sidecar proxy로 사용한다.
1) Envoy
경량화된 L7 전용 Proxy다.
HTTP, TCP 등의 프로토콜을 지원한다.
Circuit Breaker, Retry, Timeout 등의 기능을 지원한다.
2. Control Plane
Data Plane을 컨트롤하는 구성 요소를 가리킨다.
Pilot, Mixer, Citadel, Galley 등으로 구성되어 있다.
1) Pilot
envoy에 대한 설정 관리를 하는 역할을 한다.
Traffic Management 기능을 제공한다. - Service Discovery (Envoy Endpoint를 알아내는 작업)
Traffic Retry
Circuit Breaker
Timeout
2) Pilot 대처 됨 (Mixer)
Serice Mesh 전체 영역에서 Access 제어 및 정책을 관리한다.
모니터링 지표를 수집한다.
3) Citadel
보안에 관련된 기능을 담당하는 모듈이다.
인증 기능 관리 (TLS Certification 등)
4) Galley
Istio configuration을 체크한다.
Kubernetes Yaml 파일을 istio가 이해할 수 있는 형태로 변환한다.
- Istio에서 service mesh 구현한 방식
proxy 방식의 container를 추가하여 네트워크를 구성하였다.
-> Istio의 내부 구성 방식
-> 모든 app의 로그를 쉽게 수집/시각화 가능
기능
1. 트래픽 통제
1) 트래픽 분할
서로 다른 버전의 서비스를 배포해놓고, 버전별로 트래픽의 양을 조절할 수 있는 기능입니다.
ex) 새 버전의 서비스를 배포할때, 기존 버전으로 95%의 트래픽을 보내고, 새 버전으로 5%의 트래픽만 보내서 테스트하는 것이 가능합니다.
2) 컨텐츠 기반의 트래픽 분할
단순하게 커넥션 기반으로 트래픽을 분할하는 것이 아니라, 조금 더 발전된 기능으로 네트워크 패킷의 내용을 기반으로 라우팅이 가능합니다.
ex) 아래 우측 그림과 같이 HTTP 헤더의 User-agent 필드에 따라서, 클라이언트가 안드로이드일 경우에는 안드로이드 서비스로 라우팅을 하고, IPhone일 경우에는 IOS 서비스로 라우팅을 할 수 있습니다.
2. 서비스간 안정성 제공 (Resilience)
Pilot은 트래픽 통제를 통해서 서비스 호출에 대한 안정성을 제공합니다.
1) 헬스체크 및 서비스 디스커버리
파일럿은 대상 서비스가 여러개의 인스턴스로 구성이 되어 있으면 이를 로드 밸런싱하고, 이 서비스들에 대해서 주기적으로 상태 체크를 합니다.
만약에 장애가 난 서비스가 있으면 자동으로 서비스에서 제거합니다.
2) Retry, Timeout, Circuit breaker
서비스간의 호출 안정성을 위해서, 재시도 횟수를 통제할 수 있습니다.
호출을 했을때 일정 시간 (Timeout)이상 응답이 오지 않으면 에러 처리를 할 수 있고, Mircro Service Architecture 패턴중 하나인 Circuit breaker 패턴을 지원합니다.
3. 보안
1) 통신 보안
기본적으로 envoy를 통해서 통신하는 모든 트래픽을 자동으로 TLS를 이용해서 암호화한다. 즉 서비스간의 통신이 디폴트로 암호화 됩니다.
암호화를 위해서 인증서를 사용하는데, 이 인증서는 Citadel에 저장되어 있는 인증서를 다운 받아서, 이 인증서를 이용하여 암호화된 TLS 통신을 합니다.
2) 서비스 인증과 인가
Istio는 서비스에 대한 인증 (Authentication)을 제공하는데, 크게 서비스와 서비스간 호출에서, 서비스를 인증하는 기능과, 서비스를 호출하는 클라이언트를 직접 인증 할 수 있다.
3) 서비스간 인증
서비스간 인증은 인증서를 이용하여 양방향 TLS (Mutual TLS) 인증을 이용하여, 서비스가 서로를 식별하고 인증합니다.
4) 서비스와 사용자간 인증
서비스간 인증뿐 아니라, 엔드 유저 즉 사용자 클라이언트를 인증할 수 있는 기능인데, JWT 토큰을 이용해서 서비스에 접근할 수 있는 클라이언트를 인증할 수 있습니다.
5) 인가를 통한 권한 통제 (Authorization)
인증뿐만 아니라, 서비스에 대한 접근 권한을 통제 (Authorization)이 가능합니다.
기본적으로 역할 기반의 권한 인증 (RBAC : Role based authorization control)을 지원합니다.
앞에서 인증된 사용자(End User)나 서비스는 각각 사용자 계정이나 쿠버네티스의 서비스 어카운트로 계정이 정의 되고, 이 계정에 역할(Role)을 부여해서 역할을 기반으로 서비스 접근 권한을 정의할 수 있습니다.
4. 모니터링
마이크로 서비스에서 문제점중의 하나는 서비스가 많아 지면서 어떤 서비스가 어떤 서비스를 부르는지 의존성을 알기가 어렵고, 각 서비스를 개별적으로 모니터링 하기가 어렵다는 문제가 있습니다. Istio는 네트워크 트래픽을 모니터링함으로써, 서비스간에 호출 관계가 어떻게 되고, 서비스의 응답 시간, 처리량등의 다양한 지표를 수집하여 모니터링할 수 있습니다.
-> Mixer에서 서비스 관련 지표를 수집하는 구조
서비스 A가 서비스 B를 호출할때 호출 트래픽은 각각의 envoy 프록시를 통하게 되고, 호출을 할때, 응답 시간과 서비스의 처리량이 Mixer로 전달된다. 전달된 각종 지표는 Mixer에 연결된 Logging Backend에 저장됩니다.
Mixer는 위의 그림과 같이 플러그인이 가능한 아답터 구조로, 운영하는 인프라에 맞춰서 로깅 및 모니터링 시스템을 손쉽게 변환이 가능합니다.
