Istio와 Service Mesh
TL;DR
- Istio와 Service Mesh의 핵심 개념과 사용 범위를 한눈에 정리
- 등장 배경과 필요한 이유를 짚고 실무 적용 포인트를 연결
- 주요 특징과 체크리스트를 빠르게 확인
1. 개념
``` Service Mesh = 마이크로서비스 간 통신을 관리하는 인프라 계층
2. 배경
Istio와 Service Mesh이(가) 등장한 배경과 기존 한계를 정리한다.
3. 이유
이 주제를 이해하고 적용해야 하는 이유를 정리한다.
4. 특징
- 개념
- Service Mesh가 없을 때 vs 있을 때
- 이름의 의미
- Istio 아키텍처
- Istio의 Sidecar 자동 주입
5. 상세 내용
작성일: 2026-01-28 카테고리: Cloud / Kubernetes / Service Mesh 포함 내용: Istio, Service Mesh, Sidecar Pattern, Envoy, VirtualService, mTLS
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, 트래픽 관리, 카나리 배포