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