Istio 톺아보기 #1 - 개요

서비스 메쉬란?

• 서비스 메쉬는 MSA(마이크로 서비스 아키텍처)환경에서 서비스 간의 통신을 제어하고 관리할 수 있는 인프라 계층을 의미한다. 즉, 서비스 내의 애플리케이션 혹은 비즈니스 로직을 수정하지 않고도 트래픽을 컨트롤할 수 있다.
  • 트래픽을 제어할 수 있는 기능으로는 Service Discovery, Load Balacning, Failure Recovery, Monitoring, Security 등을 지원한다.
• 각 서비스마다 사이드카 컨테이너로 경량 프록시(e.g. Envoy)가 주입되어 프록시간 통신을 이루도록 메쉬 네트워크가 구성된다. 그리고, 이러한 메쉬 네트워크의 구성요소인 데이터 플레인을 관려하는 컨트롤 플레인도 존재한다. (분산 애플리케이션의 특징이다.)

 

---

 

Istio란?

---

• Istio는 쿠버네티스 환경에서 프로그래매틱하게 구현할 수 있는 서비스 메쉬 네트워크다. 쿠버네티스에서 제공하는 기본 서비스 디스커버리보다 좀더 복잡하고 섬세한 네트워킹을 지원하며, Zero-trusted Network (w. mTLS) 및 L4, L7 계층의 프록시도 지원한다.
  • 토스나 두나무 같은 핀테크 기업에서 man-in-the-middle 공격을 우려하여 내부 네트워크 상에서 서비스 간에 신뢰를 하지 않는 Zero-trusted Network를 구현한다.
  • 단순 보안 뿐만이 아니라 로드밸런싱을 통해 카나리 배포, A/B 테스팅도 유연하게 달성할 수 있으며, 트래픽의 흐름을 시각화하여 Observability도 확보할 수 있는 장점도 있다.
  • 쿠버네티스 환경에서는 보통 네임스페이스 단위로 사이드카 프록시를 주입할 수 있다. 이때, 대상 네임스페이스 내의 모든 Pod의 사이드카 컨테이너에 Envoy 컨테이너가 주입된다. 사이드카가 주입되는 과정(AuthZ, AuthN 이후 Mutate, Validate 과정)에 대해서는 따로 포스팅힐 예정이다.
• Istio의 구성요소는 크게 컨트롤 플레인과 데이터 플레인으로 이루어져 있다.
  • 컨트롤 플레인은 메쉬 네트워크를 제어하는 역할을 수행한다. 1.4 버전 이전까지는 Pilot, Mixer, Citadel, Galley로 구성되어 있었지만, 1.5버전 이후로는 istiod로 통합되었다.
    • Pilot : Envoy 사이드카와 통신할 때, Envoy API를 사용하며, 트래픽 관리, 라우팅 및 서비스 상태 체크에 관련된 책임이 있다.
    • Citadel : 서비스 간의 통신 암호화를 제공한다. (사용자 인증, 인증서 및 크레덴셜 관리)
    • Galley : Istio의 구성 관리, 서비스 메쉬의 일관성을 유지하는 역할
      • 구성 유효성 검사(Validation) : 사용자가 작성한 Istio 설정(YAML, Kubernetes manifest 등)이 올바른지 사전에 검증하고, 오류가 있는 설정이 서비스 메시에 적용되는 것을 방지한다.
      • 설정 변환 및 처리(Ingestion, Processing) : Kubernetes 등 외부 시스템에서 전달받은 설정 데이터를 Istio가 이해할 수 있는 내부 포맷으로 변환하고, 필요한 전처리 작업을 수행.
      • 설정 배포(Distribution) : 검증 및 처리된 설정을 서비스 메시 내의 각 컴포넌트로 배포하여, 전체 메시 환경에서 일관된 정책과 구성이 적용되도록 관리.
    • Mixer : Policy 혹은 Telemetry 기능을 담당한다.
  • 데이터 플레인은 서비스 간 통신은 모두 Envoy 경량 프록시를 통해 이루어진다. 각 프록시는 서비스로 들어오는 인그레스 트래픽과 나가는 이그레스 트래픽을 관리한다.

 

---

 

다음 글에서는 서비스 메쉬 내에서 트래픽을 관리하기 위한 CRD를 소개할게요~!