[Kubernetes] Istio 개념, 아키텍쳐 정리

1. 개요

기존 Monolithic Architecture의 단점을 극복하고 작은 서비스들로 하나의 서비스를 이루는 것은 각각의 서비스들을 독립적으로 관리할 수 있다는 장점이 있지만 또 어떻게 보면 수십개의 MircoService가 분리되어 관리가 힘들어질 수가 있다.

 

각 서비스들의 개수가 많아질수록 각 Node 내의 iptables 규칙 또한 증가하면서 서비스간의 통신 또한 매우 복잡해지고 오버헤드가 발생할 수 있다.

 

이와 같은 서비스 간 네트워크 트래픽 관리 및 오버헤드를 낮추기 위해 Service Mesh란 기술이 나오게 되었다.

2. 서비스 매쉬

이러한 마이크로 서비스의 문제점을 해결하기 위해 Software 계층에서, 즉 Programming Code 내부에 특정 코드를 삽입하여 관리하는 것이 아닌 Infrastructure 측면에서 이를 해결하기 위한 목적이 Service Mesh이다.

 

각 서비스들이 직접 호출하는 것이 아닌 서비스마다 Proxy를 넣는다.

⇒ Sidecar 구성 방식

 

이렇게 하면 서비스로 들어오거나, 나가는 트래픽을 네트워크 단에서 모두 통제가 가능하며, 트래픽에 대한 통제를 통해서 마이크로 서비스의 여러가지 문제점을 해결할 수 있게 된다.

 

예를 들면

1. 써킷 브레이커(호출되는 서비스가 응답이 없을 경우 프록시단에서 연결을 끊어 장애가 전파되지 않도록 설정)
2. Client의 OS (Chrome인지, iOs인지, Android인지, ..)에 따라 다른 서비스를 호출해야 한다면 Proxy 단 설정에서 이를 수행할 수도 있는 것이다.

 

이러한 설정들은 L4(TCP) 레벨에서의 조작으로는 어렵고, HTTP 헤더 기반 라우팅이나 메시지 본문 기반으로 하는 라우팅들이 필요하기 때문에 L7 계층의 지능형 라우팅이 필요할 것이다.

 

이런 마이크로서비스에 대한 문제를 소프트웨어 계층이 아니라 Proxy를 이용한 Infra 게층에서 풀어낼 수 있다는 것을 알게 되었는데, 각 Ingress가 수십, 수백개가 된다면 어떻게 관리를 해야 할까?

 

이러한 이유 때문에 중앙에서 집중 관리할 수 있는 Istio - Envoy Proxy를 많이 사용하게 되는 것이다.

 

Data Plane : 프록시들로 이루어진 Traffic들을 설정값에 따라 컨트롤하는 부분 (Envoy)

Control Plane : 프록시들에게 설정값을 전달하고 중앙 관리하는 컨트롤러 역할 (Istio)

 

 

3. Istio

Control Plane : Istio

Data Plane : Envoy Proxy

 

⇒ Data Plane의 메인 프록시로 Envoy Proxy를 사용하며 이롤 컨트롤 해주는 Control Plane의 오픈소스 솔루션이 Istio이다.

Architecture

Pilot, Galley, Citadel, Mixer, ..

 

1) 데이터 플레인

Data Plane은 Envoy를 서비스 옆에 붙여 Side Car 형식으로 배포를 하고, 서비스로 인입되고 나가는 트래픽을 Envoy를 통해 제어하게 된다.

 

Envoy는 서비스에서 서비스로 호출할 때 상대편 서비스의 IP를 알아야 하는데, 이를 Service Discovery라고 한다.

 

Envoy는 Control Plane의 Pilot이라는 컴포넌트를 통해 각 서비스의 Endpoint를 알아내게 되고, Envoy는 이 데이터를 참고하여 접근하게 된다.

2) 컨트롤 플레인

Control Plane은 Envoy를 컨트롤하는 부분이며, Pilot, Mixer, Citadel 3개의 Module로 구성되어 있다.

 

Pilot (파일럿)

Envoy에 대한 설정 관리를 하는 역할을 한다.

 

1. 서비스 디스커버리
2. 트래픽의 경로를 컨트롤 : 서비스에서 서비스로 호출되는 경로를 컨트롤할 수 있으며, 서비스간 호출이 발생할 때 재시도, 장애 전파를 막기 위한 써킷 브레이커, Timeout 등의 기능을 제공하게 된다.

 

Mixer (믹서)

Access Control, 정책 통제, 각종 모니터링 지표의 수집의 역할을 한다.

 

1. 서비스의 총 처리량을 정책으로 지정하여, 이상으로 요청을 못받게 하기
2. 특정 헤더값이 일치해야 요청을 받을 수 있게 처리하기

 

등의 다양한 정책을 수행할 수 있다.

 

서비스의 응답 시간 혹은 평균 처리량 등 지표를 수집하여 저장하는 역할 또한 수행한다.

 

 

Citadel (시타델)

보안에 관련된 기능을 담당하는 모듈이다.

⇒ 사용자 인증(Authentication), 인가(Authorization)을 담당한다.

 

Istio는 통신을 TLS(SSL) 암호화를 수행할 수 있는데, TLS 암호화 또한 사용자 인증에 필요한 인증서를 관리하는 역할 또한 수행한다.

 

 

Galley

Istio Configuration 유효성 검사

 

기능

1. 트래픽 통제
   1. 트래픽 분할
   2. 컨텐츠 기반의 트래픽 분할
2. 서비스간 안정성 제공
   1. 헬스체크 및 서비스 디스커버리
   2. Retry, Timeout, Citcuit Breaker
3. 보안
   1. 통신 보안(TLS 암호화)
   2. 서비스 인증과 인가
   3. 서비스간 인증
   4. 서비스와 사용자간 인증
   5. 인가를 통한 권한 통제
4. 모니터링모든 서비스 간 통신은 Envoy 프록시를 통하게 되며, 이에 대한 응답 시간 및 서비스 처리량이 Mixer로 전달이 되게 된다.
5. 전달된 각종 지표들은 Mixer에 연결된 Logging Backend에 저장이 된다.
6. 네트워크 트래픽을 모니터링하며, 서비스간에 호출 관계가 어떻고 서비스의 응답 시간, 처리량 등의 다양한 지표를 수집하여 모니터링할 수 있다.

 

Mixer는 플러그인이 가능한 어답터 구조로, 운영하는 인프라에 맞춰 로깅 및 모니터링 시스템을 손쉽게 변환이 가능하다.

 

Heapster, Promotheus부터 Datadog 까지 저장이 가능하게 된다.

 

이렇게 저장된 지표들은 시각화 또한 가능하게 된다.

 

Kiali라는 오픈소스는 Istio를 통해 수집되는 각종 지표를 기반으로 서비스간의 관계를 시각화하여 나타낼 수 있다.

 

다음에는 EKS Cluster 내부에 Istio로 Service Mesh를 구성한 뒤 여러가지 실습 및 패킷 분석을 해보도록 할 예정이다.

 

 

 

Ref : https://bcho.tistory.com/1293?category=731548

https://gruuuuu.github.io/cloud/service-mesh-istio/