- Authors
- Name
- Youngju Kim
- @fjvbn20031
- 들어가며
- 사이드카 방식의 한계
- Ambient Mesh 아키텍처
- ztunnel: 노드 수준 L4 프록시
- Waypoint Proxy: 네임스페이스 수준 L7 프록시
- HBONE 터널링 프로토콜
- 트래픽 인터셉션
- 워크로드 등록
- 성능 비교: 사이드카 vs Ambient
- 제한사항과 현재 상태
- 마무리
들어가며
Istio Ambient Mesh는 사이드카 프록시 없이 서비스 메시 기능을 제공하는 새로운 데이터 플레인 모드입니다. 기존 사이드카 방식의 근본적인 한계를 해결하기 위해 설계되었습니다.
이 글에서는 Ambient Mesh의 내부 아키텍처, 핵심 컴포넌트, 그리고 사이드카 방식과의 차이점을 심층적으로 분석합니다.
사이드카 방식의 한계
리소스 오버헤드
기존 사이드카 모드:
┌─────────────────────────────────┐
│ Pod │
│ ┌───────────┐ ┌─────────────┐ │
│ │ App │ │ istio-proxy │ │ ← 파드당 약 100MB RAM, 0.1 CPU
│ │ │ │ (Envoy) │ │
│ └───────────┘ └─────────────┘ │
└─────────────────────────────────┘
100개 파드 = 약 10GB 추가 메모리
시작 지연
사이드카 주입은 파드 시작 시간에 영향을 미칩니다:
- istio-init 컨테이너가 iptables 규칙 설정 (1-2초)
- istio-proxy가 istiod에서 구성 수신 대기 (2-5초)
- 전체 시작 시간에 3-7초 추가
업그레이드 복잡성
사이드카 업그레이드 시 모든 파드를 재시작해야 합니다:
- 롤링 업데이트로 파드를 하나씩 재생성
- 대규모 클러스터에서 수 시간 소요
- 애플리케이션 가용성에 영향
Ambient Mesh 아키텍처
┌─────────────────────────────────────────────────────────┐
│ Control Plane │
│ istiod │
└─────────────────────┬───────────────────────────────────┘
│ xDS
┌───────────┼───────────┐
▼ ▼ ▼
┌─────────────┐ ┌──────────┐ ┌──────────┐
│ ztunnel │ │ ztunnel │ │ waypoint │
│ (Node 1) │ │ (Node 2) │ │ proxy │
│ DaemonSet │ │ DaemonSet│ │(per-ns) │
└──────┬──────┘ └────┬─────┘ └────┬─────┘
│ │ │
┌────┴────┐ ┌────┴────┐ │
│ Pod A │ │ Pod B │ │
│(no scar)│ │(no scar)│ │
└─────────┘ └─────────┘ │
│ │ │
└──── HBONE tunnel ────────┘
ztunnel: 노드 수준 L4 프록시
개요
ztunnel(Zero Trust Tunnel)은 각 노드에 DaemonSet으로 배포되는 경량 L4 프록시입니다:
- Rust로 작성: 높은 성능과 낮은 메모리 사용량
- L4 전용: TCP 수준의 처리만 담당
- 노드당 하나: 해당 노드의 모든 파드 트래픽을 처리
ztunnel의 핵심 기능
ztunnel 기능:
├── 1. mTLS 암호화/복호화
│ ├── 워크로드 인증서 관리 (SDS)
│ └── 모든 파드 간 통신 암호화
│
├── 2. L4 인가
│ ├── AuthorizationPolicy (L4 규칙만)
│ └── 소스/대상 ID 기반 접근 제어
│
├── 3. HBONE 터널링
│ ├── HTTP/2 CONNECT 기반 터널
│ └── 포트 15008에서 수신
│
└── 4. L4 텔레메트리
├── TCP 연결 메트릭
└── 바이트 전송량 추적
ztunnel 내부 동작
[아웃바운드 트래픽 처리]
App (Pod A, Node 1) → reviews:9080
│
[1] 트래픽 인터셉션 (eBPF 또는 iptables)
→ 트래픽을 로컬 ztunnel로 리다이렉트
│
[2] ztunnel이 대상 확인
├── Kubernetes Service 해석
└── 대상 Pod의 노드 위치 확인
│
[3] HBONE 터널 수립
├── 대상 노드의 ztunnel과 mTLS 연결
├── HTTP/2 CONNECT로 터널 생성
└── 포트 15008 사용
│
[4] 암호화된 트래픽 전송
│
[인바운드 트래픽 처리]
│
[5] 대상 노드의 ztunnel이 HBONE 터널 수신
│
[6] mTLS 복호화 및 인가 확인
├── 소스 SPIFFE ID 검증
└── AuthorizationPolicy 평가
│
[7] 평문으로 대상 Pod에 전달
ztunnel의 인증서 관리
ztunnel은 해당 노드의 모든 파드에 대한 인증서를 관리합니다:
ztunnel (Node 1)
├── Pod A의 인증서: spiffe://cluster.local/ns/prod/sa/frontend
├── Pod B의 인증서: spiffe://cluster.local/ns/prod/sa/reviews
└── Pod C의 인증서: spiffe://cluster.local/ns/prod/sa/ratings
인증서 획득 방식:
1. ztunnel이 istiod에 각 워크로드의 인증서 요청
2. Kubernetes ServiceAccount 토큰으로 인증
3. SDS를 통해 인증서 수신 및 갱신
Waypoint Proxy: 네임스페이스 수준 L7 프록시
개요
waypoint proxy는 L7 기능이 필요할 때만 배포되는 Envoy 기반 프록시입니다:
L4만 필요한 경우:
Pod → ztunnel → ztunnel → Pod
(mTLS + L4 인가만)
L7이 필요한 경우:
Pod → ztunnel → waypoint proxy → ztunnel → Pod
(HTTP 라우팅, L7 인가, 폴트 인젝션 등)
Waypoint Proxy 배포
Kubernetes Gateway API를 사용하여 waypoint proxy를 생성합니다:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: waypoint
namespace: production
labels:
istio.io/waypoint-for: service
spec:
gatewayClassName: istio-waypoint
listeners:
- name: mesh
port: 15008
protocol: HBONE
또는 istioctl을 사용:
istioctl waypoint apply --namespace production
Waypoint Proxy가 처리하는 기능
Waypoint Proxy (Envoy):
├── L7 트래픽 관리
│ ├── VirtualService (HTTP 라우팅)
│ ├── 가중치 기반 트래픽 분할
│ ├── 리트라이, 타임아웃
│ ├── 폴트 인젝션
│ └── 트래픽 미러링
│
├── L7 보안
│ ├── AuthorizationPolicy (L7 규칙)
│ ├── RequestAuthentication (JWT)
│ └── HTTP 헤더/경로 기반 인가
│
└── L7 관찰성
├── HTTP 메트릭 (istio_requests_total 등)
├── 분산 트레이싱 스팬
└── 액세스 로깅
HBONE 터널링 프로토콜
HBONE 개요
HBONE(HTTP-Based Overlay Network Environment)은 Ambient Mesh의 핵심 통신 프로토콜입니다:
HBONE 터널 구조:
┌──────────────────────────────────────┐
│ TCP Connection (port 15008) │
│ ┌────────────────────────────────┐ │
│ │ TLS (mTLS) │ │
│ │ ┌──────────────────────────┐ │ │
│ │ │ HTTP/2 CONNECT │ │ │
│ │ │ ┌────────────────────┐ │ │ │
│ │ │ │ Tunneled TCP Data │ │ │ │
│ │ │ └────────────────────┘ │ │ │
│ │ └──────────────────────────┘ │ │
│ └────────────────────────────────┘ │
└──────────────────────────────────────┘
HBONE vs 사이드카 방식 비교
| 특성 | 사이드카 (iptables) | HBONE (Ambient) |
|---|---|---|
| 트래픽 인터셉션 | iptables REDIRECT | eBPF 또는 iptables |
| 프록시 위치 | 파드 내부 | 노드 수준 (ztunnel) |
| 터널링 | 없음 (직접 연결) | HTTP/2 CONNECT |
| mTLS 종단점 | 사이드카 프록시 | ztunnel |
| 포트 | 원래 서비스 포트 | 15008 (HBONE) |
HBONE 연결 흐름
Source Pod (Node 1) Destination Pod (Node 2)
│ ▲
▼ │
ztunnel (Node 1) ztunnel (Node 2)
│ ▲
│ TCP: Node1 → Node2:15008 │
│ TLS: mTLS handshake │
│ HTTP/2: CONNECT method │
└──────────────────────────────┘
트래픽 인터셉션
eBPF 기반 인터셉션 (권장)
eBPF 프로그램이 커널 수준에서 트래픽을 리다이렉트:
App (소켓 연결) → eBPF hook → ztunnel
│
TC (Traffic Control) 또는
Socket-level redirection
장점:
- iptables보다 높은 성능
- 커널 수준에서 동작하여 오버헤드 최소화
- 파드별 iptables 규칙 불필요
iptables 기반 인터셉션 (폴백)
eBPF를 지원하지 않는 환경에서는 iptables를 사용합니다:
istio-cni가 노드 수준에서 iptables 규칙 설정:
iptables -t nat -A PREROUTING \
-p tcp \
-m mark ! --mark 0x539/0xfff \
-j REDIRECT --to-ports 15008
iptables -t nat -A OUTPUT \
-p tcp \
-m mark ! --mark 0x539/0xfff \
-j REDIRECT --to-ports 15001
워크로드 등록
Ambient Mesh 활성화
네임스페이스에 라벨을 추가하여 Ambient Mesh에 등록합니다:
kubectl label namespace production istio.io/dataplane-mode=ambient
이 라벨이 추가되면:
- 해당 네임스페이스의 파드 트래픽이 ztunnel로 리다이렉트
- ztunnel이 해당 파드의 인증서를 관리
- 모든 파드 간 통신에 mTLS 적용
L7 기능 활성화
L7 기능이 필요한 경우 waypoint proxy를 추가로 배포합니다:
# 네임스페이스에 waypoint proxy 배포
istioctl waypoint apply --namespace production
# 또는 특정 서비스 계정에만 적용
istioctl waypoint apply --namespace production \
--service-account reviews
성능 비교: 사이드카 vs Ambient
메모리 사용량
사이드카 모드 (100 파드):
- Envoy 프록시: 100개 x ~100MB = ~10GB
- istio-init: 시작 시에만 사용
Ambient 모드 (100 파드, 3 노드):
- ztunnel: 3개 x ~50MB = ~150MB
- waypoint (필요 시): 1-2개 x ~100MB = ~200MB
- 총: ~350MB (사이드카 대비 약 97% 절감)
레이턴시
사이드카 모드:
Client App → Client Envoy → Network → Server Envoy → Server App
(L4+L7) (L4+L7)
Ambient 모드 (L4만):
Client App → ztunnel → Network → ztunnel → Server App
(L4) (L4)
Ambient 모드 (L7 포함):
Client App → ztunnel → waypoint → ztunnel → Server App
(L4) (L7) (L4)
L4만 사용하는 경우 Ambient가 더 낮은 레이턴시를 보여줍니다. L7이 필요한 경우 추가 홉(waypoint)이 생기지만, 리소스 효율성이 크게 향상됩니다.
시작 시간
사이드카 모드:
- istio-init iptables 설정: 1-2초
- Envoy 시작 및 구성 수신: 2-5초
- 총 추가 시간: 3-7초
Ambient 모드:
- ztunnel이 이미 실행 중 (DaemonSet)
- 파드 시작 시 추가 오버헤드: 거의 없음
- eBPF 규칙 적용: 밀리초 단위
제한사항과 현재 상태
현재 제한사항
- 프로토콜 감지: ztunnel은 L4만 처리하므로 프로토콜 자동 감지가 제한적
- 일부 Envoy 기능 미지원: EnvoyFilter, 일부 고급 트래픽 관리 기능
- 멀티 클러스터: 아직 완전히 지원되지 않는 시나리오 존재
- Windows 노드: 현재 미지원
사이드카에서 Ambient로 마이그레이션
권장 마이그레이션 순서:
1. Ambient 모드 설치 (사이드카와 공존 가능)
2. 테스트 네임스페이스에서 Ambient 활성화
kubectl label namespace test istio.io/dataplane-mode=ambient
kubectl label namespace test istio-injection- # 사이드카 비활성화
3. 검증 후 프로덕션 네임스페이스에 적용
4. 필요한 네임스페이스에 waypoint proxy 배포
5. 기존 사이드카 라벨 제거
언제 어떤 모드를 선택할까
사이드카 모드가 적합한 경우:
├── 파드별 세밀한 L7 제어가 필요
├── EnvoyFilter를 사용하는 고급 구성
├── 기존 안정적인 환경 유지
└── Windows 노드 사용
Ambient 모드가 적합한 경우:
├── 리소스 효율성이 중요
├── 빠른 파드 시작이 필요
├── 사이드카 업그레이드 부담 최소화
├── 대부분 L4 보안(mTLS)만 필요
└── 점진적으로 L7 기능 추가 가능
마무리
Istio Ambient Mesh는 서비스 메시의 가장 큰 불만이었던 사이드카 오버헤드 문제를 해결하는 혁신적인 접근입니다. ztunnel(L4)과 waypoint proxy(L7)로 기능을 분리함으로써:
- 리소스 절감: 노드당 하나의 ztunnel로 수백 개 파드의 mTLS를 처리
- 운영 단순화: 사이드카 주입/업그레이드 불필요
- 점진적 채택: L4부터 시작하여 필요 시 L7 기능을 추가
다음 글에서는 Istio 관찰성의 내부 구현을 살펴보겠습니다.