Linkerd TrafficSplit 기반 카나리 배포 원리 간단 정리.

핵심 

• 기존 k8s Service 1개 구조로는 트래픽 비율 제어 불가능 (기본 무작위 라우팅이라 V1/V2 알아서 50:50 분산됨).
• Linkerd TrafficSplit CRD를 쓰면 클라이언트 API 주소 변경 없이 트래픽 비율 정밀 제어 가능.

구조 및 동작 방식

 

[Ingress] 
   │
   ▼
[대표 Service (Apex)]
   │
[Linkerd TrafficSplit] ─── (가중치 분산) ───┐
   │                                      │
   ▼ (90%)                                ▼ (10%)
[Service-V1]                           [Service-V2]
   │                                      │
   ▼                                      ▼
[V1 Pods (Primary)]                    [V2 Pods (Canary)]

• Service 3개 세팅 필요:
  • Primary Service (V1 Pod 전용 selector)
  • Canary Service (V2 Pod 전용 selector)
  • Apex Service (Ingress가 바라보는 대표 진입점 껍데기)
• TrafficSplit 역할: Apex Service로 들어오는 트래픽을 V1/V2 Service로 가중치(weight) 맞춰서 인프라 단에서 낚아채 분산함.
• 클라이언트 관점: 엔드포인트 변경 0개. 그냥 평소대로 원래 API 호출하면 끝.

 

한 줄 요약

Service를 V1/V2/대표 3개로 쪼개고, 그 위에 Linkerd TrafficSplit을 얹어서 API 변경 없이 안전하게 신버전 검증하는 구조임.

 

 

(다음 포스팅에서는 Flagger 연동해서 Service 생성 및 트래픽 비율 조절 자동화하는 법 정리할 예정)