[3주차] 트래픽 제어(세밀한 트래픽 라우팅) : 트래픽 미러링

CloudNet@ 가시다님이 진행하는 Istio Hands-on Study [1기]

---

🚀Istio로 트래픽 미러링하여
배포 위험 줄이기 

• Istio의 traffic mirroring 기능을 활용해 새 버전 배포의 위험을 더욱 줄이는 방법
• 트래픽 미러링은 실제 사용자 트래픽에 영향을 주지 않으면서 새 버전(v2)을 테스트할 수 있는 강력한 기술

---

🧹 트래픽을 v1으로 리셋하기

• 트래픽 미러링 실습을 시작하기 전에 모든 트래픽을 catalog service의 v1으로 리셋합니다. 
• 다음 명령어를 실행해 트래픽을 v1으로 라우팅하도록 VirtualService를 적용합니다: virtualservice.networking.istio.io/catalog를 설정해 모든 트래픽을 catalog v1으로 보냅니다.

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl apply -f ch5/catalog-vs-v1-mesh.yaml -n istioinaction
virtualservice.networking.istio.io/catalog created

• 적용 후, webapp의 /api/catalog 엔드포인트를 호출해 v1 응답만 나오는지 확인합니다:
  • 응답은 imageUrl 필드가 없는 v1 응답일 거예요. 이는 트래픽이 v1으로 올바르게 라우팅되고 있음을 보여줍니다!

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ curl -s http://webapp.istioinaction.io:30000/api/catalog \
-H "Host: webapp.istioinaction.io" | jq
[
  {
    "id": 1,
    "color": "amber",
    "department": "Eyewear",
    "name": "Elinor Glasses",
    "price": "282.00"
  },
...

VirtualService를 적용해 모든 트래픽을 catalog v1으로 리셋합니다.
curl로 테스트해 v1 응답만 나오는지 확인합니다!

---

🪞 트래픽 미러링 설정하기

• 이제 트래픽 미러링을 설정해 실제 트래픽은 v1으로 가면서, 동일한 요청을 v2로 복사합니다.
  미러링된 요청은 사용자 응답에 영향을 주지 않는 fire-and-forget 방식으로 처리됩니다.
• 아래는 트래픽 미러링을 위한 VirtualService 설정입니다:

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ cat ch5/catalog-vs-v2-mirror.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: catalog
spec:
  hosts:
  - catalog
  gateways:
  - mesh
  http:
  - route:
    - destination: #트래픽의 목적지를 지정
        host: catalog
        subset: version-v1
      weight: 100
    mirror: #실제 트래픽의 복사본을 만들어 다른 서비스로도 보내는 기능
      host: catalog #미러링된 트래픽을 보낼 서비스 이름
      subset: version-v2 #미러링된 트래픽을 'catalog' 서비스의 'version-v2' 버전으로 보낸다

• 이 설정을 살펴보면:
  • route: 모든 실제 트래픽(100%)을 version-v1 subset(v1)으로 라우팅합니다.
  • mirror: 모든 요청을 version-v2 subset(v2)으로 복사해 보냅니다. 미러링된 요청은 응답이 무시되며, 사용자에게 영향을 주지 않습니다.
• 이 VirtualService를 적용합니다:

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl apply -f ch5/catalog-vs-v2-mirror.yaml -n istioinaction
virtualservice.networking.istio.io/catalog configured

VirtualService에 mirror 설정을 추가해 실제 트래픽은 v1으로, 복사된 트래픽은 v2로 보냅니다.
미러링은 사용자 응답에 영향을 주지 않습니다!

---

✅ 미러링 동작 확인하기

• 트래픽 미러링이 제대로 작동하는지 확인합니다.
• 먼저 webapp 엔드포인트를 호출해 사용자 응답이 v1에서 오는지 확인합니다:
  응답은 imageUrl 필드가 없는 v1 응답일 거예요. 이는 실제 트래픽이 v1으로 가고 있음을 보여줍니다

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ curl -s http://webapp.istioinaction.io:30000/api/catalog \
-H "Host: webapp.istioinaction.io" | jq
[
  {
    "id": 1,
    "color": "amber",
    "department": "Eyewear",
    "name": "Elinor Glasses",
    "price": "282.00"
  },
...

• 이제 v1과 v2 pod의 로그를 확인해 요청이 실제로 미러링되고 있는지 확인합니다.
  먼저 v1 pod의 이름을 가져오고 로그를 확인합니다: v1 로그에는 실제 요청이 기록돼 있습니다.

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~$ CATALOG_V1=$(kubectl get pod -n istioinaction -l app=catalog -l version=v1 \
-o jsonpath={.items..metadata.name})

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~$ kubectl logs $CATALOG_V1 -n istioinaction -c catalog
GET catalog.istioinaction:80 /items 200 502 - 1.167 ms
GET /items 200 1.167 ms - 502
request path: /items
blowups: {}
number of blowups: 0

• 이제 v2 pod의 로그를 확인합니다.
  • v2 로그에도 요청이 기록돼 있으며, Host 헤더가 -shadow:80으로 표시돼 있습니다. 이는 요청이 미러링된 것임을 나타냅니다.
    미러링된 요청은 -shadow 접미사를 가지며, 서비스는 이를 인식해 응답이 폐기됨을 알 수 있습니다(예: 트랜잭션 롤백, 리소스 집약적 작업 회피).

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl get pod -n istioinaction -l app=catalog -l version=v2 \
-o jsonpath={.items..metadata.name}

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl logs $CATALOG_V2 -c catalog -n istioinaction
GET catalog.istioinaction-shadow:80 /items 200 698 - 0.888 ms
GET /items 200 0.888 ms - 698
request path: /items
blowups: {}
number of blowups: 0

curl로 v1 응답만 오는지 확인하고, v1/v2 로그를 통해 요청이 v2로 미러링되는지 확인합니다.
v2 로그의 -shadow 접미사는 미러링 요청을 나타냅니다!

---

⚠️ 트래픽 미러링 시 주의사항

• 미러링 인식: 서비스는 -shadow 접미사를 확인해 미러링 요청임을 인식하고, 리소스 집약적 작업이나 상태 변경을 피해야 합니다.
• 다중 버전 지원: v1과 v2가 동시에 실행되며, 미러링된 트래픽을 처리할 수 있도록 애플리케이션이 설계돼야 합니다.
• 상태 관리: 상태를 가진 서비스는 미러링 요청이 실제 데이터에 영향을 주지 않도록 주의해야 합니다.

애플리케이션은 미러링 요청을 인식하고, 다중 버전 실행 및 상태 관리를 지원해야 합니다.
-shadow 접미사를 활용해 미러링 트래픽을 구분하세요!

---

📌핵심 요약

1. v1으로 트래픽 리셋: VirtualService를 적용해 모든 트래픽을 catalog v1으로 라우팅하고, curl로 v1 응답만 나오는지 확인
2. 미러링 설정: VirtualService에 mirror 설정을 추가해 실제 트래픽은 v1으로, 복사된 트래픽은 v2로 보냈어요. 미러링은 사용자 응답에 영향을 주지 않습니다.
3. 미러링 확인: curl로 v1 응답을 확인하고, v1/v2 로그를 통해 v2로 요청이 미러링됨을 확인했어요. v2 로그의 -shadow 접미사는 미러링 요청임을 나타냅니다.
4. 주의사항: 애플리케이션이 미러링 요청을 인식하고, 다중 버전 및 상태 관리를 지원해야 함

---