Files

T

Antigravity Agent 93ec7e9056 [G1-Sync] Manual knowledge update

2026-05-09 21:08:02 +09:00

4.7 KiB

Raw Blame History

id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases

title

Service Mesh

Pod 옆 sidecar proxy (Envoy / linkerd2-proxy) 가 통신 가로챔. mTLS 자동 / traffic split / retry / circuit breaker 코드 외부화. Linkerd = 가벼움, Istio = 풀 기능.

📖 핵심 개념

Sidecar: 매 pod 옆 proxy.
Data plane: 실제 트래픽 처리.
Control plane: 정책 배포 (Istiod, linkerd-controller).
mTLS: 자동 - 모든 service 간 암호화 + 인증.

💻 코드 패턴

Linkerd 설치

linkerd check --pre
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
linkerd check

Inject sidecar

kubectl get deploy api -o yaml | linkerd inject - | kubectl apply -f -

# 또는 namespace 자동
kubectl annotate ns prod linkerd.io/inject=enabled

mTLS (자동)

linkerd viz edges deployment
# 모든 service 간 → mTLS

Istio VirtualService (traffic split)

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata: { name: api }
spec:
  hosts: [api]
  http:
  - match: [{ headers: { x-canary: { exact: "true" } } }]
    route: [{ destination: { host: api, subset: v2 } }]
  - route:
    - { destination: { host: api, subset: v1 }, weight: 90 }
    - { destination: { host: api, subset: v2 }, weight: 10 }

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata: { name: api }
spec:
  host: api
  subsets:
  - name: v1
    labels: { version: v1 }
  - name: v2
    labels: { version: v2 }

→ 90/10 canary, header 가 있으면 100% v2.

Retry / timeout

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata: { name: api }
spec:
  http:
  - route: [{ destination: { host: api } }]
    timeout: 5s
    retries:
      attempts: 3
      perTryTimeout: 2s
      retryOn: 5xx,reset,connect-failure

Circuit breaker

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata: { name: api }
spec:
  host: api
  trafficPolicy:
    connectionPool:
      tcp: { maxConnections: 100 }
      http: { http2MaxRequests: 1000, maxRequestsPerConnection: 10 }
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s

AuthorizationPolicy

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata: { name: api-allow }
spec:
  selector: { matchLabels: { app: api } }
  rules:
  - from:
    - source: { principals: ["cluster.local/ns/prod/sa/web"] }
    to:
    - operation: { methods: [GET, POST] }

Linkerd traffic split (SMI)

apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata: { name: api-split }
spec:
  service: api
  backends:
    - { service: api-v1, weight: 90 }
    - { service: api-v2, weight: 10 }

관찰 (Linkerd viz)

linkerd viz dashboard
# 자동: success rate, RPS, p95/p99, mTLS 표시

Istio observability

Kiali: service graph.
Jaeger: tracing.
Grafana: metrics.

Ambient mode (Istio sidecar 없는)

ztunnel (per-node) + waypoint proxy.
자원 효율 더 좋음.
새 (2024+).

Trade-offs

장점:
- 코드 변경 X
- 통일 정책 (mTLS, retry, CB)
- Observability 자동

단점:
- 자원 (각 pod + sidecar)
- 복잡도 (특히 Istio)
- Latency (~1-3ms per hop)
- Debug 어려움

🤔 의사결정 기준

규모	추천
<10 service	mesh 불필요 — 직접
10-100 service	Linkerd (가볍고 단순)
큰 / 복잡 정책	Istio
자원 절약	Linkerd 또는 Istio Ambient
GKE	Istio (기본 통합)
자체 호스트 작은 팀	Linkerd

❌ 안티패턴

Mesh 도입 + 단순 정책: overkill. ingress + library 충분.
모든 retry 같은 정책: 어떤 endpoint 는 idempotent X.
CB 없이 cascading failure: 한 service 죽으면 모두.
mTLS 가정 + 외부 통신: gateway 만 mTLS — 외부 API 는 공개.
Sidecar resource 안 잡음: pod scheduling 깨짐.
Istio 1.0 부터 풀 기능 도입: 점진. STRICT mTLS 부터.
Egress 무제어: 외부 호출 무제한.

🤖 LLM 활용 힌트

Linkerd 시작 → 단순.
Istio = 풀 기능, 학습 곡선.
mTLS / retry / CB / observability 가 ROI 높음.

4.7 KiB Raw Blame History