본문 바로가기
WIKI 기술 지식 베이스

트래픽 이동

원문 보기 위키 갱신

트래픽 이동 (Traffic Shifting)

트래픽 분할과 이동은 운영자가 트래픽을 서로 다른 백엔드 Service로 동적으로 옮길 수 있게 해주는 강력한 기능이에요. A/B 실험, red/green 배포, 카나리 롤아웃, 결함 주입(fault injection) 등을 구현하는 데 쓸 수 있어요.

출처: Linkerd Traffic Shifting

본문

트래픽 분할은 HTTPRoute와 GRPCRoute 유형으로 이뤄져요.

참고

이전 버전의 Linkerd는 트래픽 분할을 위해 Linkerd SMI 확장의 일부로 TrafficSplit 리소스를 제공했어요. 이 방식은 여전히 지원되지만 더 이상 기능 개발은 되지 않아요.

Linkerd 프로덕션 팁

이 페이지에는 오픈 소스 커뮤니티가 제공하는 best-effort 지침이 담겨 있어요. 미션 크리티컬 애플리케이션을 운영하는 프로덕션 사용자는 Linkerd 프로덕션 리소스에 익숙해지고/거나 상용 Linkerd 제공업체와 연락을 취하는 게 좋아요.

사전 요구 사항

이 가이드를 사용하려면 Linkerd와 Linkerd-Viz가 실행 중인 Kubernetes 클러스터가 필요해요.

데모 설정

각각 v1과 v2라고 불리는 로드 생성기와 두 개의 백엔드가 포함된 최소 데모를 설정해 볼게요. 여기서 이들이 어떤 서비스의 두 버전을 나타내고, 완전히 롤아웃하기 전에 트래픽의 일부로 v2를 테스트하고 싶은 상황을 상상해 볼 수 있어요.

로드 생성에는 Slow-Cooker를, 백엔드에는 BB를 사용할 거예요.

이 컴포넌트들을 클러스터에 추가하고 Linkerd 데이터 플레인에 포함시키려면 다음을 실행하세요:

cat <<EOF | linkerd inject - | kubectl apply -f -
---
apiVersion: v1
kind: Namespace
metadata:
  name: traffic-shift-demo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: v1
  namespace: traffic-shift-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bb
      version: v1
  template:
    metadata:
      labels:
        app: bb
        version: v1
    spec:
      containers:
      - name: terminus
        image: buoyantio/bb:v0.0.6
        args:
        - terminus
        - "--h1-server-port=8080"
        - "--response-text=v1"
        ports:
        - containerPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: v2
  namespace: traffic-shift-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bb
      version: v2
  template:
    metadata:
      labels:
        app: bb
        version: v2
    spec:
      containers:
      - name: terminus
        image: buoyantio/bb:v0.0.6
        args:
        - terminus
        - "--h1-server-port=8080"
        - "--response-text=v2"
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: bb
  namespace: traffic-shift-demo
spec:
  ports:
  - name: http
    port: 8080
    targetPort: 8080
  selector:
    app: bb
    version: v1
---
apiVersion: v1
kind: Service
metadata:
  name: bb-v2
  namespace: traffic-shift-demo
spec:
  ports:
  - name: http
    port: 8080
    targetPort: 8080
  selector:
    app: bb
    version: v2
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: slow-cooker
  namespace: traffic-shift-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: slow-cooker
  template:
    metadata:
      labels:
        app: slow-cooker
    spec:
      containers:
      - args:
        - -c
        - |
          sleep 5 # wait for pods to start
          /slow_cooker/slow_cooker --qps 10 http://bb:8080
        command:
        - /bin/sh
        image: buoyantio/slow_cooker:1.3.0
        name: slow-cooker
EOF

slow-cooker가 v1 백엔드로 트래픽을 보내는 걸 확인할 수 있어요:

> linkerd viz -n traffic-shift-demo stat --from deploy/slow-cooker deploy
NAME   MESHED   SUCCESS       RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
v1        1/1   100.00%   10.1rps           1ms           1ms           8ms          1

트래픽 이동하기

이제 HTTPRoute를 만들고 트래픽의 10%를 v2 백엔드로 분할해 볼게요:

cat <<EOF | kubectl apply -f -
---
apiVersion: policy.linkerd.io/v1beta2
kind: HTTPRoute
metadata:
  name: bb-route
  namespace: traffic-shift-demo
spec:
  parentRefs:
    - name: bb
      kind: Service
      group: core
      port: 8080
  rules:
    - backendRefs:
      - name: bb
        port: 8080
        weight: 90
      - name: bb-v2
        port: 8080
        weight: 10
EOF

이 HTTPRoute에서 parentRef가 slow-cooker가 통신하는 bb Service 리소스라는 점을 눈여겨보세요. 즉 메시로 감싼 클라이언트가 bb Service와 통신할 때마다 이 HTTPRoute를 사용하게 돼요. 또한 bb Service가 backendRefs 목록에 weight 90으로 다시 나타나는 것도 볼 수 있어요. 이는 bb Service로 보내진 트래픽의 90%는 그 Service의 엔드포인트로 계속 흘러가고, 나머지 10% 요청은 bb-v2 Service로 라우팅된다는 뜻이에요.

트래픽 통계를 보면 이를 확인할 수 있어요 (stat 명령어는 1분 창의 메트릭을 보므로, 통계가 이렇게 보이려면 최대 1분이 걸릴 수 있다는 점을 기억하세요):

> linkerd viz -n traffic-shift-demo stat --from deploy/slow-cooker deploy
NAME   MESHED   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
v1        1/1   100.00%   9.0rps           1ms           1ms           1ms          1
v2        1/1   100.00%   1.0rps           1ms           1ms           1ms          1

여기서부터 HTTPRoute의 weight를 계속 조정해서 트래픽을 bb-v2 Service로 점진적으로 옮기거나, 위험해 보이면 다시 되돌릴 수 있어요. 이 데모를 마무리하면서 트래픽의 100%를 bb-v2로 옮겨 볼게요:

cat <<EOF | kubectl apply -f -
---
apiVersion: policy.linkerd.io/v1beta2
kind: HTTPRoute
metadata:
  name: bb-route
  namespace: traffic-shift-demo
spec:
  parentRefs:
    - name: bb
      kind: Service
      group: core
      port: 8080
  rules:
    - backendRefs:
      - name: bb-v2
        port: 8080
        weight: 100
EOF
> linkerd viz -n traffic-shift-demo stat --from deploy/slow-cooker deploy
NAME   MESHED   SUCCESS       RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
v1        1/1         -         -             -             -             -          -
v2        1/1   100.00%   10.0rps           1ms           1ms           2ms          1

더 알아보기 (Learn more)