Istio와 Service Mesh
TL;DR
- Istio, Service Mesh, Sidecar, Envoy, Proxy, mTLS, VirtualService, DestinationRule, Gateway, 트래픽 관리, 카나리 배포
- Istio와 Service Mesh를 알아두면 설계 판단과 구현 선택을 더 분명하게 할 수 있다.
- 원문 전체는 아래 상세 내용에 그대로 포함했다.
1. 개념
Istio, Service Mesh, Sidecar, Envoy, Proxy, mTLS, VirtualService, DestinationRule, Gateway, 트래픽 관리, 카나리 배포
2. 배경
Istio와 Service Mesh가 등장한 배경과 문제 상황을 이해하는 데 도움이 된다.
3. 이유
Istio와 Service Mesh를 알아두면 설계 판단과 구현 선택을 더 분명하게 할 수 있다.
4. 특징
Istio와 Service Mesh의 특징, 장단점, 적용 포인트를 원문에서 자세히 확인할 수 있다.
5. 상세 내용
Istio와 Service Mesh
1. Service Mesh란?
개념
Service Mesh = 마이크로서비스 간 통신을 관리하는 인프라 계층
┌─────────────────────────────────────────────────────────┐
│ │
│ 마이크로서비스 환경의 문제: │
│ │
│ 서비스 A ←──────────────────────────→ 서비스 B │
│ │
│ 이 통신에서 해결해야 할 것들: │
│ ├── 보안: 암호화, 인증 │
│ ├── 관찰: 로깅, 메트릭, 트레이싱 │
│ ├── 신뢰성: 재시도, 타임아웃, 서킷 브레이커 │
│ ├── 트래픽 관리: 라우팅, 로드밸런싱 │
│ └── 이걸 각 서비스마다 구현? 너무 복잡! │
│ │
│ Service Mesh = 이런 "횡단 관심사"를 인프라로 분리 │
│ │
└─────────────────────────────────────────────────────────┘
Service Mesh가 없을 때 vs 있을 때
❌ 없을 때: 각 서비스가 직접 구현
┌─────────────────┐ ┌─────────────────┐
│ Service A │ │ Service B │
│ ┌─────────────┐ │ │ ┌─────────────┐ │
│ │ 비즈니스 │ │ │ │ 비즈니스 │ │
│ │ 로직 │ │ │ │ 로직 │ │
│ ├─────────────┤ │ │ ├─────────────┤ │
│ │ 암호화 │ │ │ │ 암호화 │ │
│ │ 재시도 │ │ ←───→ │ │ 재시도 │ │
│ │ 로깅 │ │ │ │ 로깅 │ │
│ │ ... │ │ │ │ ... │ │
│ └─────────────┘ │ │ └─────────────┘ │
└─────────────────┘ └─────────────────┘
✅ 있을 때: 인프라가 처리
┌─────────────────┐ ┌─────────────────┐
│ Service A │ │ Service B │
│ ┌─────────────┐ │ │ ┌─────────────┐ │
│ │ 비즈니스 │ │ │ │ 비즈니스 │ │
│ │ 로직만! │ │ │ │ 로직만! │ │
│ └──────┬──────┘ │ │ └──────┬──────┘ │
│ │ │ │ │ │
│ ┌──────▼──────┐ │ │ ┌──────▼──────┐ │
│ │ Sidecar │ │ ←───→ │ │ Sidecar │ │
│ │ Proxy │ │ │ │ Proxy │ │
│ └─────────────┘ │ │ └─────────────┘ │
└─────────────────┘ └─────────────────┘
2. Istio란?
개념
Istio = Service Mesh의 구현체 (가장 인기 있는)
다른 구현체들:
├── Istio (Google, IBM, Lyft)
├── Linkerd (CNCF)
├── Consul Connect (HashiCorp)
└── AWS App Mesh
이름의 의미
Istio = 그리스어로 "돛" (ιστίο)
Kubernetes가 "조타수"라면
Istio는 "돛" = 배를 움직이게 하는 힘
비유: K8s가 컨테이너를 관리한다면
Istio는 컨테이너 간 통신을 관리
Istio 아키텍처
┌─────────────────────────────────────────────────────────┐
│ Istio 아키텍처 │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Control Plane (Istiod) │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Pilot │ │ Citadel │ │ Galley │ │ │
│ │ │(라우팅) │ │ (보안) │ │ (설정) │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ └──────────────────────┬──────────────────────────┘ │
│ │ 설정 배포 │
│ ▼ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Data Plane │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Pod A │ │ Pod B │ │ │
│ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ │
│ │ │ │ App │ │ │ │ App │ │ │ │
│ │ │ └────┬────┘ │ │ └────┬────┘ │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ ┌────▼────┐ │◄───────►│ ┌────▼────┐ │ │ │
│ │ │ │ Envoy │ │ │ │ Envoy │ │ │ │
│ │ │ │ (사이드 │ │ │ │ (사이드 │ │ │ │
│ │ │ │ 카) │ │ │ │ 카) │ │ │ │
│ │ │ └─────────┘ │ │ └─────────┘ │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
💡 핵심 포인트:
- Control Plane: 정책 결정 (Istiod)
- Data Plane: 실제 트래픽 처리 (Envoy 프록시들)
- Pod 간 통신은 Envoy 사이드카를 통해 이루어짐!
3. Sidecar Pattern
개념
Sidecar = 오토바이 옆에 붙은 사이드카
┌─────────────────────────────────────────────────────────┐
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ 오토바이 │ │ 사이드카 │ │
│ │ (본체/앱) │ ─── │ (보조 기능) │ │
│ └──────────────────┘ └──────────────────┘ │
│ │
│ 특징: │
│ ├── 본체와 함께 이동 (같은 Pod에서 실행) │
│ ├── 본체와 독립적 (별도 컨테이너) │
│ └── 본체에 추가 기능 제공 │
│ │
└─────────────────────────────────────────────────────────┘
Istio의 Sidecar 자동 주입
# Namespace에 라벨만 추가하면 자동으로 Sidecar 주입
apiVersion: v1
kind: Namespace
metadata:
name: my-app
labels:
istio-injection: enabled # 이 라벨이 핵심!
# 이 Namespace에 배포되는 모든 Pod에
# 자동으로 Envoy 사이드카가 추가됨
Pod 배포 시:
원래 정의: App 컨테이너 1개
실제 생성: App 컨테이너 + Envoy 사이드카 = 2개
kubectl get pods
NAME READY STATUS
my-app 2/2 Running # 2개 컨테이너!
4. Envoy Proxy
이름의 의미
Envoy = 사절, 특사, 대리인
"앱을 대신해서 네트워크 통신을 처리하는 대리인"
Envoy란?
Envoy = Lyft에서 만든 고성능 프록시
┌─────────────────────────────────────────────────────────┐
│ │
│ Envoy의 역할 (사이드카로서): │
│ │
│ 1. 모든 인/아웃바운드 트래픽 가로채기 │
│ 2. 로드밸런싱 │
│ 3. TLS 종료/시작 │
│ 4. 재시도, 타임아웃, 서킷 브레이커 │
│ 5. 메트릭 수집 │
│ 6. 액세스 로깅 │
│ │
│ 앱 입장에서는 "투명하게" 동작 │
│ (앱 코드 수정 없이 위 기능들이 추가됨) │
│ │
└─────────────────────────────────────────────────────────┘
5. Istio의 핵심 기능
5.1 mTLS (Mutual TLS)
mTLS = 양방향 TLS 인증
일반 TLS: 클라이언트가 서버 인증서 확인
mTLS: 서버도 클라이언트 인증서 확인 (양방향)
┌─────────────────────────────────────────────────────────┐
│ │
│ Service A Envoy ←──► Envoy B │
│ │ │ 암호화 │ │
│ │ │ + 상호 │ │
│ │ 평문 │ 인증 │ 평문 │
│ └──► └───────────┘ ◄── │
│ │
│ Istio가 자동으로 인증서 발급/갱신 │
│ 서비스 간 통신이 자동으로 암호화 + 인증 │
│ │
└─────────────────────────────────────────────────────────┘
5.2 트래픽 관리
Istio로 할 수 있는 트래픽 관리:
1. 카나리 배포
v1: 90% ─────────────►
v2: 10% ─────────────►
2. A/B 테스트
헤더에 "beta: true" → v2로
그 외 → v1로
3. 트래픽 미러링
모든 트래픽 → v1 (실제 처리)
→ v2 (복사본, 테스트용)
4. 서킷 브레이커
연속 5번 에러 → 해당 서비스 차단
6. VirtualService와 DestinationRule
VirtualService
VirtualService = 트래픽 라우팅 규칙 정의
"어떤 요청을 어디로 보낼지"
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: my-service
spec:
hosts:
- my-service
http:
# URL 기반 라우팅
- match:
- uri:
prefix: /api/v2
route:
- destination:
host: my-service
subset: v2
# 가중치 기반 라우팅 (카나리)
- route:
- destination:
host: my-service
subset: v1
weight: 90
- destination:
host: my-service
subset: v2
weight: 10
DestinationRule
DestinationRule = 목적지 도착 후의 정책 정의
"서비스에 도착했을 때 어떻게 처리할지"
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: my-service
spec:
host: my-service
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
outlierDetection:
consecutive5xxErrors: 5
interval: 30s
baseEjectionTime: 30s
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
7. Istio Gateway
K8s Ingress vs Istio Gateway
┌─────────────────────────────────────────────────────────┐
│ │
│ K8s Ingress: │
│ ├── 클러스터 외부 → 내부 트래픽 관리 │
│ ├── 기본적인 HTTP 라우팅 │
│ └── 단순한 기능 │
│ │
│ Istio Gateway: │
│ ├── Ingress의 확장판 │
│ ├── VirtualService와 함께 사용 │
│ ├── 더 세밀한 트래픽 제어 │
│ ├── mTLS 설정 가능 │
│ └── 트래픽 미러링, 가중치 라우팅 등 │
│ │
└─────────────────────────────────────────────────────────┘
# Istio Gateway 예시
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: my-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: my-cert
hosts:
- "my-app.example.com"
8. 정리
┌─────────────────────────────────────────────────────────┐
│ │
│ Service Mesh │
│ └── 마이크로서비스 간 통신을 관리하는 인프라 계층 │
│ │
│ Istio │
│ └── Service Mesh의 가장 인기 있는 구현체 │
│ │
│ Sidecar Pattern │
│ └── 각 Pod에 프록시를 붙여서 통신을 가로채는 패턴 │
│ │
│ Envoy │
│ └── Istio가 사용하는 고성능 프록시 │
│ │
│ 핵심 리소스: │
│ ├── VirtualService: 트래픽 라우팅 규칙 │
│ ├── DestinationRule: 목적지 정책 │
│ └── Gateway: 외부 트래픽 진입점 │
│ │
│ 핵심 기능: │
│ ├── mTLS (자동 암호화) │
│ ├── 트래픽 관리 (카나리, A/B, 미러링) │
│ ├── 관찰성 (메트릭, 로깅, 트레이싱) │
│ └── 정책 (rate limit, retry, circuit breaker) │
│ │
│ 💡 핵심 포인트: │
│ "Istio는 Pod 간 통신을 제어하는 것이 핵심 목적!" │
│ 사이드카가 Pod 안에서 동작하지만, │
│ 그 목적은 Pod 밖으로 나가는/들어오는 트래픽 제어 │
│ │
└─────────────────────────────────────────────────────────┘
관련 키워드
Istio, Service Mesh, Sidecar, Envoy, Proxy, mTLS, VirtualService, DestinationRule, Gateway, 트래픽 관리, 카나리 배포