Ssoon

[3주차] 트래픽 제어(세밀한 트래픽 라우팅) : 트래픽 전환 본문

Istio Hands-on Study [1기]

[3주차] 트래픽 제어(세밀한 트래픽 라우팅) : 트래픽 전환

구구달스 2025. 4. 20. 21:08 
CloudNet@ 가시다님이 진행하는 Istio Hands-on Study [1기]

🚀 Istio로 트래픽 점진적 분배하기:
Canary Release

  • Istio를 활용해 서비스의 새 버전을 안전하게 배포하는 canary release 방법
  • 트래픽을 특정 비율로 나누어 catalog service의 v1과 v2로 분배하는 traffic shifting
  • 이를 통해 새 버전(v2)을 점진적으로 사용자에게 공개하며 위험을 최소화할 수 있습니다.

🧹 초기 상태 확인 및 v1으로 트래픽 리셋하기

  • 모든 트래픽을 catalog service의 v1으로 리셋합니다.
  • 현재 실행 중인 pod을 확인해봅시다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl get deploy,rs,pod -n istioinaction --show-labels
NAME                         READY   UP-TO-DATE   AVAILABLE   AGE     LABELS
deployment.apps/catalog      1/1     1            1           3h45m   app=catalog,version=v1
deployment.apps/catalog-v2   1/1     1            1           3h25m   app=catalog,version=v2
deployment.apps/webapp       1/1     1            1           57m     app=webapp

NAME                                    DESIRED   CURRENT   READY   AGE     LABELS
replicaset.apps/catalog-6cf4b97d        1         1         1       3h45m   app=catalog,pod-template-hash=6cf4b97d,version=v1
replicaset.apps/catalog-v2-6df885b555   1         1         1       3h25m   app=catalog,pod-template-hash=6df885b555,version=v2
replicaset.apps/webapp-7685bcb84        1         1         1       57m     app=webapp,pod-template-hash=7685bcb84

NAME                              READY   STATUS    RESTARTS   AGE     LABELS
pod/catalog-6cf4b97d-dpflk        2/2     Running   0          3h45m   app=catalog,pod-template-hash=6cf4b97d,security.istio.io/tlsMode=istio,service.istio.io/canonical-name=catalog,service.istio.io/canonical-revision=v1,version=v1
pod/catalog-v2-6df885b555-nw8w7   2/2     Running   0          3h25m   app=catalog,pod-template-hash=6df885b555,security.istio.io/tlsMode=istio,service.istio.io/canonical-name=catalog,service.istio.io/canonical-revision=v2,version=v2
pod/webapp-7685bcb84-99q5q        2/2     Running   0          57m     app=webapp,pod-template-hash=7685bcb84,security.istio.io/tlsMode=istio,service.istio.io/canonical-name=webapp,service.istio.io/canonical-revision=latest

 

  • 모든 트래픽을 catalog v1으로 라우팅하도록 VirtualService를 적용합니다:  
    virtualservice.networking.istio.io/catalog를 설정해     모든 트래픽을 v1으로 보냅니다. 
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ cat ch5/catalog-vs-v1-mesh.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: catalog
spec:
  hosts:
  - catalog
  gateways:
    - mesh
  http:
  - route:
    - destination:
        host: catalog
        subset: version-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 configured
  • 적용 후, 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 | jq
[
  {
    "id": 1,
    "color": "amber",
    "department": "Eyewear",
    "name": "Elinor Glasses",
    "price": "282.00"
  },
 ...

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

⚖️ 10% 트래픽을 v2로 분배하기

  • 이제 canary release를 시작해볼게요! catalog service v2로 10%의 트래픽을 보내고, 나머지 90%는 v1으로 유지합니다.
    이렇게 하면 v2의 안정성을 소규모로 테스트하며 문제를 빠르게 파악할 수 있어요.
  • 아래는 트래픽을 90:10 비율로 나누는 VirtualService 설정입니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ cat ch5/catalog-vs-v2-10-90-mesh.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: catalog
spec:
  hosts:
  - catalog
  gateways:
  - mesh #클러스터 내부에서 서비스끼리 통신할 때 적용되는 설정
  http:
  - route:
    - destination: #트래픽의 목적지를 지정
        host: catalog #목적지 서비스의 이름
        subset: version-v1 #'catalog' 서비스 중에서도 'version-v1'이라는 특정 버전으로 트래픽을 보낸다
      weight: 90 #전체 트래픽의 90%가 이 목적지로 전송됨
    - destination:
        host: catalog
        subset: version-v2
      weight: 10
  • 이 설정은:
    • catalog 서비스로 가는 트래픽을 version-v1에 90%, version-v2에 10% 분배합니다.
    • gateways: mesh 를 사용해 클러스터 내부의 서비스 간 호출에 적용됩니다.
  • 이 VirtualService를 적용합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl apply -f ch5/catalog-vs-v2-10-90-mesh.yaml -n istioinaction
virtualservice.networking.istio.io/catalog configured
  • 적용 후, /api/catalog 엔드포인트를 100번 호출해 v2 응답(imageUrl 필드 포함)의 비율을 확인합니다:
    • 결과는 약 10(100번 중 10%) 정도입니다. 이는 트래픽의 10%가 v2로 라우팅되고 있음을 보여줍니다!
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ for i in {1..100}; do curl -s http://webapp.istioinaction.io:30000/api/catalog | grep -i imageUrl ; done | wc -l
12

VirtualService를 설정해 트래픽의 10%를 catalog v2로, 90%를 v1으로 분배합니다.
100번 호출로 v2 응답이 약 10번 나오는지 확인합니다!

🔄 50:50 트래픽 분배로 전환하기

  • 이번에는 트래픽을 v1과 v2에 50:50으로 나누겠습니다.
  • 아래는 50:50 비율로 트래픽을 분배하는 VirtualService 설정입니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ cat ch5/catalog-vs-v2-50-50-mesh.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: 50
    - destination:
        host: catalog
        subset: version-v2
      weight: 50
  • 이 설정을 적용합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl apply -f ch5/catalog-vs-v2-50-50-mesh.yaml -n istioinaction
virtualservice.networking.istio.io/catalog configured
  • 적용 후, 다시 100번 호출해 v2 응답의 비율을 확인해봅시다:
    • 결과는 약 50(100번 중 50%) 정도입니다. 이는 트래픽이 v1과 v2에 균등하게 분배되고 있음을 보여줍니다!
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ for i in {1..100}; do curl -s http://webapp.istioinaction.io:30000/api/catalog | grep -i imageUrl ; done | wc -l
52

VirtualService를 업데이트해 트래픽을 v1과 v2에 50:50으로 분배합니다.
100번 호출로 v2 응답이 약 50번 나오는지 확인합니다!

⚠️ 트래픽 분배 시 주의사항

  • Weight 합계: 모든 weight의 합은 반드시 100이어야 합니다. 그렇지 않으면 예측 불가능한 라우팅이 발생할 수 있습니다.
  • Subset 정의: v1, v2 외의 다른 버전이 있다면, 반드시 DestinationRule에 해당 버전을 subset으로 정의해야 합니다(예: ch5/catalog-dest-rule.yaml 참조).
  • 모니터링: 새 버전(v2)을 배포할 때는 안정성, 성능, 정확성을 모니터링합니다. 문제가 생기면 weight를 조정해 v2로 가는 트래픽을 줄이거나 0%로 롤백할 수 있습니다.
  • 상태 관리: 서비스가 상태(state)를 가지거나 외부 상태에 의존하면, 여러 버전이 동시에 실행될 때 복잡성이 증가할 수 있습니다.

트래픽 분배 시 weight 합계가 100이어야 하며, 모든 버전은 DestinationRule에 정의해야 합니다.
모니터링과 롤백 계획을 세우고, 자동화를 고려하세요!

📌핵심 요약

  • v1으로 트래픽 리셋: pod 상태를 확인하고 VirtualService를 적용해 모든 트래픽을 catalog v1으로 라우팅. curl로 v1 응답만 나오는 걸 확인
  • 10% v2 분배: VirtualService를 설정해 트래픽의 10%를 v2로, 90%를 v1으로 보냈습니다. 100번 호출로 v2 응답이 약 10번 나왔습니다.
  • 50:50 분배: 트래픽을 v1과 v2에 50:50으로 나누었고, 100번 호출로 v2 응답이 약 50번 나오는 걸 확인

🚀Flagger로
Istio Canary Release 자동화하기 

  • Istio의 트래픽 관리 기능을 수동으로 설정하는 대신, Flagger를 활용해 canary release를 자동화하는 방법
  • Flagger는 새 버전 배포를 점진적으로 진행하고, 메트릭을 기반으로 성공 여부를 판단해 롤백까지 자동으로 처리해주는 강력한 도구입니다. 

🧹 기존 리소스 정리하기

  • Flagger 실습을 시작하기 전에 기존 Istio 설정을 정리해 깨끗한 환경을 만듭니다.
    다음 명령어로 catalog 관련 리소스를 삭제합니다: VirtualService, catalog-v2 deployment, catalog service, DestinationRule을 제거
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl delete virtualservice catalog -n istioinaction
kubectl delete deploy catalog-v2 -n istioinaction
kubectl delete service catalog -n istioinaction
kubectl delete destinationrule catalog -n istioinaction
virtualservice.networking.istio.io "catalog" deleted
deployment.apps "catalog-v2" deleted
service "catalog" deleted
destinationrule.networking.istio.io "catalog" deleted

Flagger 실습 전 catalog 관련 Istio 리소스를 삭제합니다.

📊 Prometheus와 Flagger 설치하기

  • Flagger는 서비스의 상태를 판단하기 위해 메트릭을 사용하므로, Prometheus가 필수입니다.
    Prometheus는 Istio 데이터 플레인을 스크래핑해 메트릭을 수집합니다.
  • 이제 Flagger를 설치합니다. Flagger는 Helm을 사용해 설치하며, Istio와 Prometheus와 연동되도록 설정합니다.
  • Flagger가 사용할 세 가지 커스텀 리소스 타입의 정의를 클러스터에 추가
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~$ kubectl apply -f https://raw.githubusercontent.com/fluxcd/flagger/main/artifacts/flagger/crd.yaml
customresourcedefinition.apiextensions.k8s.io/canaries.flagger.app created
customresourcedefinition.apiextensions.k8s.io/metrictemplates.flagger.app created
customresourcedefinition.apiextensions.k8s.io/alertproviders.flagger.app created
  • 먼저 Helm 저장소를 추가하고 Flagger를 설치합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~$ helm repo add flagger https://flagger.app
"flagger" has been added to your repositories

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~$ helm install flagger flagger/flagger \
  --namespace=istio-system \
  --set crd.create=false \
  --set meshProvider=istio \
  --set metricServer=http://prometheus:9090
NAME: flagger
LAST DEPLOYED: Thu Apr 24 14:57:07 2025
NAMESPACE: istio-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Flagger installed
  • 설치 후, Flagger pod이 실행 중인지 확인합니다.
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~$ kubectl get pod -n istio-system -l app.kubernetes.io/name=flagger
NAME                       READY   STATUS    RESTARTS   AGE
flagger-6d4ffc5576-6qhch   1/1     Running   0          79s

Prometheus와 Flagger를 설치해 메트릭 수집과 canary release 자동화를 준비합니다.

⚙️ Flagger Canary 리소스 설정하기

  • Flagger는 Canary 리소스를 통해 canary release의 동작 방식을 정의합니다.
    이 리소스는 배포 대상, 트래픽 라우팅, 메트릭 기준 등을 지정해 Flagger가 자동으로 리소스를 생성하고 배포를 관리하도록 도와줍니다.
  • 아래는 catalog 서비스의 canary release를 위한 Canary 리소스 설정입니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ cat ch5/flagger/catalog-release.yaml
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: catalog-release
  namespace: istioinaction
spec:
  targetRef: #카나리아 배포가 관리할 대상을 지정
    apiVersion: apps/v1
    kind: Deployment
    name: catalog
  progressDeadlineSeconds: 60 #60초 동안 진행 상황이 없으면 배포가 실패한 것으로 간주
  service:
    name: catalog
    port: 80
    targetPort: 3000
    gateways:
    - mesh #서비스 메시 내부의 모든 통신에 이 설정을 적용
    hosts:
    - catalog
  analysis: #카나리아 배포 중 분석 방법을 정의
    interval: 45s #분석을 45초마다 수행
    threshold: 5 #배포 진행 여부를 결정하기 전에 수행할 분석 횟수
    maxWeight: 50 #카나리아 버전이 받을 수 있는 최대 트래픽 비율(50%)
    stepWeight: 10 #각 단계마다 카나리아 버전으로 보내는 트래픽을 10%씩 증가시킴
    metrics: #첫 번째 메트릭(측정 항목)을 정의
    - name: request-success-rate #요청 성공률을 측정
      thresholdRange:
        min: 99 #성공률이 최소 99% 이상이어야 함
      interval: 1m #메트릭을 1분마다 측정
    - name: request-duration #요청 처리 시간을 측정
      thresholdRange:
        max: 500 #요청 처리 시간이 최대 500밀리초(0.5초) 이하여야 함
      interval: 30s #이 메트릭을 30초마다 측정
  • 이 설정의 주요 내용을 정리하면:
    • targetRef: canary 대상인 catalog Deployment를 지정합니다.
    • service: catalog 서비스와 Istio VirtualService 설정을 정의합니다(포트 80, 대상 포트 3000, mesh gateway 사용).
    • analysis: canary 진행 방식을 정의합니다.
      • 45초마다 상태를 평가하고, 트래픽을 10%씩 증가시킵니다.
      • 최대 50%까지 트래픽을 v2로 보낸 뒤, 성공 시 100%로 전환합니다.
      • 메트릭: 요청 성공률 99% 이상, P99 요청 지연 시간 500ms 이하.
      • 5번 연속 메트릭 기준 미달 시 롤백됩니다.
  • Canary 리소스를 적용합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl apply -f ch5/flagger/catalog-release.yaml -n istioinaction
canary.flagger.app/catalog-release created
  • 적용 후, canary 상태를 실시간으로 확인할 수 있어요:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl get canary -n istioinaction -w
NAME              STATUS         WEIGHT   LASTTRANSITIONTIME
catalog-release   Initializing   0        2025-04-24T06:01:00Z
catalog-release   Initialized    0        2025-04-24T06:01:50Z

 

  • Flagger는 자동으로 catalog-primary, catalog-canary Deployment와 Service, 그리고 VirtualService를 생성합니다. 생성된 VirtualService를 확인해보면:
    • 초기에는 모든 트래픽이 catalog-primary로 가고, catalog-canary는 0%를 받습니다.
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~$ kubectl get vs -n istioinaction catalog -o yaml | kubectl neat
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  annotations:
    helm.toolkit.fluxcd.io/driftDetection: disabled
    kustomize.toolkit.fluxcd.io/reconcile: disabled
  name: catalog
  namespace: istioinaction
spec:
  gateways:
  - mesh
  hosts:
  - catalog
  http:
  - match:
    - sourceLabels:
        app: webapp
    route:
    - destination:
        host: catalog-primary
      weight: 100
    - destination:
        host: catalog-canary
      weight: 0
  - route:
    - destination:
        host: catalog-primary
      weight: 100

Canary 리소스를 설정해 canary release의 대상, 서비스, 메트릭 기준을 정의합니다.
Flagger가 자동으로 필요한 리소스를 생성하며, kubectl get canary로 진행 상황을 확인합니다!

🚀 Catalog v2 배포 및 Canary 진행 관찰하기

  • 이제 catalog v2를 배포하고 Flagger가 canary release를 자동으로 진행하도록 해볼게요.
    Flagger는 Deployment 변경을 감지해 catalog-canary를 생성하고 트래픽을 점진적으로 분배합니다.
  • 먼저, 서비스에 부하를 생성해 메트릭의 기준선을 만듭니다.
  • 새 터미널에서 다음 명령어를 실행해 /api/catalog 엔드포인트를 지속적으로 호출합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~$ while true; do curl -s http://webapp.istioinaction.io:30000/api/catalog -I | head -n 1 ; date "+%Y-%m-%d %H:%M:%S" ; sleep 1; echo; done
HTTP/1.1 200 OK
2025-04-24 15:08:21
...
  • 다음으로, catalog v2를 배포합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ cat ch5/flagger/catalog-deployment-v2.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: catalog
    version: v1
  name: catalog
spec:
  replicas: 1
  selector:
    matchLabels:
      app: catalog
      version: v1
  template:
    metadata:
      labels:
        app: catalog
        version: v1
    spec:
      containers:
      - env:
        - name: KUBERNETES_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: SHOW_IMAGE
          value: "true"
        image: istioinaction/catalog:latest
        imagePullPolicy: IfNotPresent
        name: catalog
        ports:
        - containerPort: 3000
          name: http
          protocol: TCP
        securityContext:
          privileged: false
         
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl apply -f ch5/flagger/catalog-deployment-v2.yaml -n istioinaction
deployment.apps/catalog configured
  • Flagger는 이 변경을 감지해 canary release를 시작합니다. 진행 상황을 실시간으로 확인해봅시다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~$ kubectl get canary -n istioinaction -w
NAME              STATUS        WEIGHT   LASTTRANSITIONTIME
catalog-release   Initialized   0        2025-04-24T06:01:50Z
catalog-release   Progressing   0        2025-04-24T06:10:34Z
catalog-release   Progressing   10       2025-04-24T06:11:18Z
catalog-release   Progressing   10       2025-04-24T06:12:01Z
catalog-release   Progressing   20       2025-04-24T06:12:46Z
catalog-release   Progressing   30       2025-04-24T06:13:29Z
catalog-release   Progressing   40       2025-04-24T06:14:13Z
catalog-release   Progressing   50       2025-04-24T06:14:57Z
catalog-release   Promoting     0        2025-04-24T06:15:40Z
catalog-release   Finalising    0        2025-04-24T06:16:24Z
catalog-release   Succeeded     0        2025-04-24T06:17:07Z

 

  • Flagger는 45초마다 트래픽을 10%씩 v2로 이동시키며, 메트릭(성공률 99% 이상, 지연 시간 500ms 이하)을 확인합니다. 50%에 도달하면 성공 시 v2를 catalog-primary로 승격하고, 실패 시 롤백합니다.
  • 진행 중에 VirtualService를 확인하면 트래픽 분배 상태를 볼 수 있어요:
    • 성공적으로 완료되면 v2가 100% 트래픽을 받으며 catalog-primary로 승격됩니다!
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~$ kubectl get vs -n istioinaction catalog -o yaml -w
...
    route:
    - destination:
        host: catalog-primary
      weight: 80
    - destination:
        host: catalog-canary
      weight: 20
  - route:
    - destination:
        host: catalog-primary
      weight: 80
---
...
    route:
    - destination:
        host: catalog-primary
      weight: 70
    - destination:
        host: catalog-canary
      weight: 30
  - route:
    - destination:
        host: catalog-primary
      weight: 70
---
...
    route:
    - destination:
        host: catalog-primary
      weight: 60
    - destination:
        host: catalog-canary
      weight: 40
  - route:
    - destination:
        host: catalog-primary
      weight: 60
---
...
    route:
    - destination:
        host: catalog-primary
      weight: 50
    - destination:
        host: catalog-canary
      weight: 50
  - route:
    - destination:
        host: catalog-primary
      weight: 50
---
...
    route:
    - destination:
        host: catalog-primary
      weight: 100
    - destination:
        host: catalog-canary
      weight: 0
  - route:
    - destination:
        host: catalog-primary
      weight: 100
  • 카나리 과정 중 kiali 확인

catalog v2를 배포하고 부하를 생성해 Flagger가 canary release를 진행합니다.

🧼 실습 환경 정리하기

  • Flagger 실습을 마무리하고, 환경을 정리합니다.
    Flagger와 관련 리소스를 제거하고, 원래 catalog 서비스와 v2를 별도 Deployment로 복원합니다.
  • 다음 명령어로 Flagger와 관련 리소스를 삭제합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl delete canary catalog-release -n istioinaction
canary.flagger.app "catalog-release" deleted
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl delete deploy catalog -n istioinaction
deployment.apps "catalog" deleted
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ helm uninstall flagger -n istio-system
release "flagger" uninstalled
  • 그 다음, catalog 서비스와 v1, v2 Deployment, DestinationRule을 복원합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl apply -f services/catalog/kubernetes/catalog-svc.yaml -n istioinaction
kubectl apply -f services/catalog/kubernetes/catalog-deployment.yaml -n istioinaction
kubectl apply -f services/catalog/kubernetes/catalog-deployment-v2.yaml -n istioinaction
kubectl apply -f ch5/catalog-dest-rule.yaml -n istioinaction
service/catalog created
deployment.apps/catalog created
deployment.apps/catalog-v2 created
destinationrule.networking.istio.io/catalog created

Flagger와 관련 리소스를 삭제하고,
catalog 서비스, v1, v2 Deployment, DestinationRule을 복원합니다.

 

📌 전체 과정 요약

  1. 리소스 정리: catalog 관련 Istio 리소스를 삭제해 Flagger 실습을 위한 깨끗한 환경을 준비
  2. Prometheus와 Flagger 설치: Prometheus로 메트릭 수집 환경을 구축하고, Helm으로 Flagger를 설치해 Istio와 연동
  3. Canary 리소스 설정: Canary 리소스를 정의해 catalog Deployment를 대상으로 트래픽 분배(10%씩, 최대 50%)와 메트릭 기준(성공률 99%, 지연 500ms)을 설정
  4. v2 배포 및 진행 관찰: 부하를 생성하고 catalog v2를 배포해 Flagger가 트래픽을 점진적으로 이동시키는 과정을 관찰했어요. 성공 시 v2가 100%로 승격
  5. 환경 정리: Flagger와 관련 리소스를 제거하고, 원래 catalog 환경을 복원

 

저작자표시

'Istio Hands-on Study [1기]' 카테고리의 다른 글

[3주차] 트래픽 제어(세밀한 트래픽 라우팅) : Istio의 서비스 검색을 사용하여 클러스터 외부의 서비스로 라우팅하기  (0) 2025.04.20
[3주차] 트래픽 제어(세밀한 트래픽 라우팅) : 트래픽 미러링  (0) 2025.04.20
[3주차] 트래픽 제어(세밀한 트래픽 라우팅) : Istio로 라우팅 요청  (0) 2025.04.20
[3주차] 트래픽 제어(세밀한 트래픽 라우팅) : 새로운 코드 배포의 위험 줄이기  (0) 2025.04.20
2주차 : Istio gateways > 클러스터로 트래픽 유입 : 운영 팁  (0) 2025.04.15
'Istio Hands-on Study [1기]' Related Articles more
Comments