Split View: Istio Ambient Mesh 내부 구조: 사이드카 없는 서비스 메시

Traditional Sidecar Mode:
┌─────────────────────────────────┐
│ Pod                             │
│  ┌───────────┐ ┌─────────────┐ │
│  │    App    │ │ istio-proxy │ │  ← ~100MB RAM, 0.1 CPU per pod
│  │           │ │  (Envoy)    │ │
│  └───────────┘ └─────────────┘ │
└─────────────────────────────────┘

100 pods = ~10GB additional memory

┌─────────────────────────────────────────────────────────┐
│                    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 functions:
├── 1. mTLS encryption/decryption
│   ├── Workload certificate management (SDS)
│   └── Encrypt all pod-to-pod communication
│
├── 2. L4 authorization
│   ├── AuthorizationPolicy (L4 rules only)
│   └── Source/destination identity-based access control
│
├── 3. HBONE tunneling
│   ├── HTTP/2 CONNECT-based tunnel
│   └── Listens on port 15008
│
└── 4. L4 telemetry
    ├── TCP connection metrics
    └── Byte transfer tracking

[Outbound Traffic Processing]

App (Pod A, Node 1) → reviews:9080
        │
[1] Traffic interception (eBPF or iptables)
    → Redirect traffic to local ztunnel
        │
[2] ztunnel determines destination
    ├── Kubernetes Service resolution
    └── Locate destination Pod node
        │
[3] Establish HBONE tunnel
    ├── mTLS connection to destination node ztunnel
    ├── Create tunnel via HTTP/2 CONNECT
    └── Use port 15008
        │
[4] Send encrypted traffic
        │

[Inbound Traffic Processing]

        │
[5] Destination node ztunnel receives HBONE tunnel
        │
[6] mTLS decryption and authorization check
    ├── Verify source SPIFFE ID
    └── Evaluate AuthorizationPolicy
        │
[7] Forward as plaintext to destination Pod

ztunnel (Node 1)
├── Pod A cert: spiffe://cluster.local/ns/prod/sa/frontend
├── Pod B cert: spiffe://cluster.local/ns/prod/sa/reviews
└── Pod C cert: spiffe://cluster.local/ns/prod/sa/ratings

Certificate acquisition:
1. ztunnel requests certificates for each workload from istiod
2. Authenticates via Kubernetes ServiceAccount token
3. Receives and renews certificates via SDS

When only L4 is needed:
Pod → ztunnel → ztunnel → Pod
(mTLS + L4 authz only)

When L7 is needed:
Pod → ztunnel → waypoint proxy → ztunnel → Pod
(HTTP routing, L7 authz, fault injection, etc.)

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 waypoint apply --namespace production

Waypoint Proxy (Envoy):
├── L7 Traffic Management
│   ├── VirtualService (HTTP routing)
│   ├── Weight-based traffic splitting
│   ├── Retries, timeouts
│   ├── Fault injection
│   └── Traffic mirroring
│
├── L7 Security
│   ├── AuthorizationPolicy (L7 rules)
│   ├── RequestAuthentication (JWT)
│   └── HTTP header/path-based authorization
│
└── L7 Observability
    ├── HTTP metrics (istio_requests_total, etc.)
    ├── Distributed tracing spans
    └── Access logging

HBONE Tunnel Structure:
┌──────────────────────────────────────┐
│ TCP Connection (port 15008)          │
│  ┌────────────────────────────────┐  │
│  │ TLS (mTLS)                     │  │
│  │  ┌──────────────────────────┐  │  │
│  │  │ HTTP/2 CONNECT           │  │  │
│  │  │  ┌────────────────────┐  │  │  │
│  │  │  │ Tunneled TCP Data  │  │  │  │
│  │  │  └────────────────────┘  │  │  │
│  │  └──────────────────────────┘  │  │
│  └────────────────────────────────┘  │
└──────────────────────────────────────┘

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 programs redirect traffic at the kernel level:

App (socket connect) → eBPF hook → ztunnel
                        │
                TC (Traffic Control) or
                Socket-level redirection

Benefits:
- Higher performance than iptables
- Operates at kernel level with minimal overhead
- No per-pod iptables rules needed

istio-cni sets up node-level iptables rules:

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

kubectl label namespace production istio.io/dataplane-mode=ambient

# Deploy waypoint proxy in namespace
istioctl waypoint apply --namespace production

# Or apply only for a specific service account
istioctl waypoint apply --namespace production \
  --service-account reviews

Sidecar mode (100 pods):
- Envoy proxies: 100 x ~100MB = ~10GB
- istio-init: used only at startup

Ambient mode (100 pods, 3 nodes):
- ztunnel: 3 x ~50MB = ~150MB
- waypoint (if needed): 1-2 x ~100MB = ~200MB
- Total: ~350MB (~97% reduction vs sidecar)

Sidecar mode:
Client App → Client Envoy → Network → Server Envoy → Server App
             (L4+L7)                    (L4+L7)

Ambient mode (L4 only):
Client App → ztunnel → Network → ztunnel → Server App
             (L4)                 (L4)

Ambient mode (with L7):
Client App → ztunnel → waypoint → ztunnel → Server App
             (L4)      (L7)       (L4)

Sidecar mode:
- istio-init iptables setup: 1-2 seconds
- Envoy startup and config reception: 2-5 seconds
- Total additional time: 3-7 seconds

Ambient mode:
- ztunnel already running (DaemonSet)
- Additional overhead at pod start: nearly zero
- eBPF rule application: milliseconds

Recommended migration order:

1. Install Ambient mode (can coexist with sidecars)

2. Enable Ambient on test namespace
   kubectl label namespace test istio.io/dataplane-mode=ambient
   kubectl label namespace test istio-injection-  # disable sidecar

3. After validation, apply to production namespaces

4. Deploy waypoint proxy for namespaces that need it

5. Remove existing sidecar labels

Sidecar mode is suitable when:
├── Fine-grained per-pod L7 control is needed
├── Advanced configuration using EnvoyFilter
├── Maintaining an existing stable environment
└── Using Windows nodes

Ambient mode is suitable when:
├── Resource efficiency is important
├── Fast pod startup is needed
├── Minimizing sidecar upgrade burden
├── Mostly needing L4 security (mTLS) only
└── Gradually adding L7 features as needed