Istio Ambient vs Sidecar — 2026년 서비스메시 아키텍처 선택 가이드

가정:
- 클러스터 내 파드 수: 500개
- 사이드카 1개당 메모리: 평균 120MiB (서비스 1,000개 규모 메시 기준)
- 사이드카 1개당 CPU request: 100m

사이드카 모델 총 오버헤드:
  메모리 = 500 x 120MiB = 60,000MiB = 약 58.6GiB
  CPU request = 500 x 100m = 50 vCPU (request 기준 노드 점유)

노드가 16GiB 메모리라면:
  사이드카 메모리만으로 노드 약 4대 분량을 소비
  CPU request 50 vCPU는 스케줄링 가능 용량을 그만큼 잠식

사이드카 업그레이드 절차 (canary revision 방식):
1. istiod 1.26을 revision 태그로 신규 설치 (기존 1.25와 병행)
2. 네임스페이스 라벨을 새 revision으로 변경
3. 해당 네임스페이스의 모든 Deployment를 rollout restart
4. 전 네임스페이스 반복 — 파드 5,000개 클러스터라면 수 시간~수 일
5. 구버전 istiod 제거

문제점:
- 재시작이 불가능하거나 비싼 워크로드(StatefulSet, 배치, 세션 유지)가 발목을 잡음
- 재시작 누락 파드는 구버전 프록시로 잔류 → 버전 스큐(skew) 발생
- 업그레이드 주기가 분기 1회 이상이면 이 비용이 상시 운영 부담이 됨

+----------------------------------------------------------------------+
|                          Kubernetes 클러스터                          |
|                                                                      |
|  Node A                              Node B                          |
|  +------------------------------+    +-----------------------------+ |
|  |  Pod: app-a    Pod: app-b    |    |  Pod: app-c                 | |
|  |  (사이드카 없음) (사이드카 없음)|    |  (사이드카 없음)             | |
|  |       |             |        |    |       |                     | |
|  |       v             v        |    |       v                     | |
|  |  +------------------------+  |    |  +-----------------------+  | |
|  |  | ztunnel (DaemonSet)    |==|====|==| ztunnel (DaemonSet)   |  | |
|  |  | L4: mTLS, TCP 텔레메트리|  | HBONE | L4: mTLS, L4 인가     |  | |
|  |  +------------------------+  |    |  +-----------------------+  | |
|  +------------------------------+    +-----------------------------+ |
|                                                                      |
|            L7 기능이 필요한 네임스페이스에만 선택적으로:                 |
|            +------------------------------------+                    |
|            | waypoint proxy (Envoy, Deployment) |                    |
|            | L7: HTTP 라우팅, 재시도, L7 인가,    |                    |
|            |     HTTP 텔레메트리                  |                    |
|            +------------------------------------+                    |
|                                                                      |
|  +----------------+                                                  |
|  | istiod (제어부) | --- xDS/인증서 ---> ztunnel, waypoint            |
|  +----------------+                                                  |
+----------------------------------------------------------------------+

HBONE 터널 구조 (포트 15008):

  +-------------------------------------------------------+
  |  TCP (노드 A ztunnel -> 노드 B ztunnel, 목적지 :15008)  |
  |  +---------------------------------------------------+|
  |  |  mTLS (SPIFFE 신원 상호 검증, 클라이언트/서버 인증서) ||
  |  |  +-----------------------------------------------+ ||
  |  |  |  HTTP/2                                       | ||
  |  |  |  CONNECT 요청: 목적지 파드 IP:포트 지정          | ||
  |  |  |  +-------------------------------------------+| ||
  |  |  |  |  원본 애플리케이션 TCP 바이트스트림           || ||
  |  |  |  +-------------------------------------------+| ||
  |  |  +-----------------------------------------------+ ||
  |  +---------------------------------------------------+|
  +-------------------------------------------------------+

# 네임스페이스를 ambient 메시에 편입 — 파드 재시작 불필요
kubectl label namespace payments istio.io/dataplane-mode=ambient

# 메시에서 제외
kubectl label namespace payments istio.io/dataplane-mode-

[사이드카 모드] app-a (Node A) -> app-b (Node B) HTTP 호출

app-a 컨테이너
  | (1) localhost 아웃바운드, iptables가 가로챔
  v
app-a 파드의 istio-proxy (Envoy)           <- L4+L7 처리 (홉 1)
  | (2) mTLS 암호화, 라우팅/재시도/텔레메트리
  v
(노드 간 네트워크, mTLS)
  |
  v
app-b 파드의 istio-proxy (Envoy)           <- L4+L7 처리 (홉 2)
  | (3) mTLS 복호화, 인가 검사, L7 텔레메트리
  v
app-b 컨테이너

프록시 홉: 2 (양쪽 모두 항상 L7 파싱)

[Ambient, waypoint 없음] app-a (Node A) -> app-b (Node B) TCP/HTTP 호출

app-a 컨테이너
  | (1) 아웃바운드, istio-cni 규칙이 노드 ztunnel로 리다이렉트
  v
Node A ztunnel                              <- L4 처리 (홉 1)
  | (2) HBONE 터널 수립 (mTLS, HTTP/2 CONNECT, :15008)
  v
Node B ztunnel                              <- L4 처리 (홉 2)
  | (3) 복호화, L4 인가 검사 후 파드로 전달
  v
app-b 컨테이너

프록시 홉: 2 (단, 둘 다 경량 L4 — HTTP 파싱 없음)

[Ambient + waypoint] app-a -> app-b (app-b 네임스페이스에 waypoint 있음)

app-a 컨테이너
  v
Node A ztunnel ── HBONE ──> waypoint 파드 (Envoy)   <- L7 처리
                               | HTTP 라우팅, 재시도,
                               | L7 인가, 텔레메트리
                               v
                  ── HBONE ──> 목적지 노드 ztunnel
                               v
                            app-b 컨테이너

프록시 홉: 3 (ztunnel -> waypoint -> ztunnel)
핵심: waypoint는 "목적지 측" 리소스 — 목적지 서비스의 정책을 집행

가정:
- 파드 500개, 노드 20대
- ztunnel 1개당 메모리: 평균 50MiB (연결 수에 따라 변동, L4만 처리)
- L7 정책이 필요한 네임스페이스: 5개
- waypoint 1개당: replica 2, 각 200MiB (Envoy, HPA로 확장)

Ambient 총 오버헤드:
  ztunnel  = 20노드 x 50MiB           = 1,000MiB ≈ 1GiB
  waypoint = 5ns x 2replica x 200MiB  = 2,000MiB ≈ 2GiB
  합계 ≈ 3GiB

사이드카 모델: ≈ 58.6GiB (앞서 계산)
절감: 약 95% (이 시나리오 기준)

권장 전환 순서:

단계 0: 사전 점검
  - Istio를 Ambient 지원 안정 버전으로 업그레이드
  - istio-cni, ztunnel 컴포넌트 설치 (기존 사이드카 트래픽에 영향 없음)
  - EnvoyFilter 사용처 전수 조사 — Ambient 비호환 항목 식별

단계 1: 저위험 네임스페이스 1개 선정 (내부 도구, 스테이징)
  - 해당 ns 워크로드의 사이드카 주입 라벨 제거 + rollout restart
  - istio.io/dataplane-mode=ambient 라벨 부여
  - L7 정책이 있었다면 waypoint 배포 후 정책 재바인딩
  - 1~2주 관찰: mTLS 메트릭, 오류율, p99 지연

단계 2: 트래픽 패턴이 단순한(L4 위주) 네임스페이스 확대
  - waypoint 없이 ztunnel만으로 운영되는 영역부터

단계 3: L7 정책이 복잡한 핵심 서비스
  - waypoint 용량 산정(HPA), 정책 동작 검증 후 전환

단계 4: 사이드카 잔존 영역 확정
  - VM 연동, EnvoyFilter 의존 워크로드는 사이드카 유지 결정 가능
  - 혼합 운영을 공식 상태로 문서화

# 전환 전 상태 확인 — 두 라벨이 공존하면 안 됨
kubectl get namespace payments -o jsonpath='{.metadata.labels}'

# 사이드카 주입 해제 (revision 라벨 사용 시 해당 라벨 제거)
kubectl label namespace payments istio-injection-
# 파드에서 사이드카 제거
kubectl rollout restart deployment -n payments
# 재시작 완료 후 ambient 편입
kubectl label namespace payments istio.io/dataplane-mode=ambient

helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update

# 1) CRD 및 베이스
helm install istio-base istio/base -n istio-system --create-namespace --wait

# 2) istiod — ambient 프로파일
helm install istiod istio/istiod -n istio-system \
  --set profile=ambient --wait

# 3) CNI 노드 에이전트 — 트래픽 리다이렉션 담당
helm install istio-cni istio/cni -n istio-system \
  --set profile=ambient --wait

# 4) ztunnel DaemonSet
helm install ztunnel istio/ztunnel -n istio-system --wait

istioctl install --set profile=ambient --skip-confirmation

# 네임스페이스용 waypoint 생성 + 해당 ns 트래픽이 waypoint를 쓰도록 편입
istioctl waypoint apply -n payments --enroll-namespace

# 위 명령과 동등한 선언적 YAML
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: waypoint
  namespace: payments
  labels:
    istio.io/waypoint-for: service   # service | workload | all
spec:
  gatewayClassName: istio-waypoint
  listeners:
    - name: mesh
      port: 15008
      protocol: HBONE
---
# 네임스페이스가 이 waypoint를 사용하도록 라벨링 (enroll-namespace와 동일 효과)
# kubectl label ns payments istio.io/use-waypoint=waypoint

신규 메시 구축인가?
 ├─ 예 → EnvoyFilter/VM/고급 멀티클러스터 요구가 있는가?
 │        ├─ 없음 → Ambient로 시작 (권장 기본값)
 │        └─ 있음 → 해당 워크로드만 사이드카, 나머지 Ambient 혼합
 └─ 아니오 (기존 사이드카 메시 운영 중)
          → 사이드카 운영 고통(리소스/업그레이드)이 큰가?
            ├─ 크다 → 네임스페이스 단위 점진 전환 시작
            │         L4 위주 ns부터 → L7 ns는 waypoint 검증 후
            └─ 작다 → 현상 유지 + 신규 ns만 Ambient로 (점진 수렴)

# ztunnel 파드 확인
kubectl get pods -n istio-system -l app=ztunnel -o wide

# 특정 노드 ztunnel 로그 — 워크로드 편입/HBONE 연결 이벤트 확인
kubectl logs -n istio-system ztunnel-abcde --tail=100

# ztunnel이 인지한 워크로드 목록 (istioctl)
istioctl ztunnel-config workloads
istioctl ztunnel-config services
istioctl ztunnel-config certificates   # 워크로드 인증서 발급 상태

# 설정 정합성 진단 — 모드 혼용, waypoint 미바인딩 등 검출
istioctl analyze -n payments

# waypoint가 정책/라우트를 받았는지 확인 (waypoint는 Envoy이므로 proxy-config 사용 가능)
istioctl proxy-config routes deploy/waypoint -n payments