5장. OpenShift Service Mesh에 Argo 롤아웃을 사용하여 트래픽 라우팅
Red Hat OpenShift GitOps의 Argo 롤아웃은 OpenShift 경로 및 Istio 기반 OpenShift Service Mesh와 같은 다양한 트래픽 관리 메커니즘을 지원합니다.
Argo Rollouts에서 사용할 트래픽 관리자를 선택하는 옵션은 클러스터 워크로드를 배포하는 기존 트래픽 관리 솔루션에 따라 다릅니다. 예를 들어 Red Hat OpenShift 경로는 기본 트래픽 관리 기능을 제공하며 사이드카 컨테이너를 사용할 필요가 없습니다. 그러나 Red Hat OpenShift Service Mesh는 Istio를 사용하여 고급 라우팅 기능을 제공하지만 사이드카 컨테이너를 구성해야 합니다.
OpenShift Service Mesh를 사용하여 두 애플리케이션 버전 간에 트래픽을 분할할 수 있습니다.
- Canary version: 트래픽을 점진적으로 라우팅하는 새로운 버전의 애플리케이션입니다.
- stable 버전: 애플리케이션의 현재 버전입니다. 카나리아 버전이 안정적이고 모든 사용자 트래픽이 전달되면 새 안정적인 버전이 됩니다. 이전 안정 버전이 삭제되었습니다.
Argo Rollouts 내의 Istio-support는 게이트웨이 및 VirtualService 리소스를 사용하여 트래픽 라우팅을 처리합니다.
- 게이트웨이: 게이트웨이 를 사용하여 메시에 대한 인바운드 및 아웃바운드 트래픽을 관리할 수 있습니다. 게이트웨이는 OpenShift Service Mesh의 진입점이며 애플리케이션으로 전송된 트래픽 요청을 처리합니다.
- VirtualService: VirtualService는 트래픽 라우팅 규칙과 안정적인 및 카나리아 서비스와 같은 기본 서비스로 이동하는 트래픽의 백분율을 정의합니다.
샘플 배포 시나리오
예를 들어 샘플 배포 시나리오에서는 초기 인스턴스 중에 애플리케이션의 안정적인 버전으로 트래픽의 100%가 전달됩니다. 애플리케이션이 예상대로 실행되고 있으며 새 버전을 배포하려는 추가 시도가 이루어지지 않습니다.
그러나 새 버전의 애플리케이션을 배포한 후 Argo Rollouts는 새 버전의 애플리케이션을 기반으로 새 카나리아 배포를 생성하고 일부 트래픽 백분율을 해당 새 버전으로 라우팅합니다.
서비스 메시를 사용하는 경우 Argo Rollouts는 VirtualService 리소스를 자동으로 수정하여 안정적인 및 카나리아 애플리케이션 버전 간의 트래픽 분할 백분율을 제어합니다. 다음 다이어그램에서는 첫 번째 승격 후 트래픽의 20%가 카나리아 애플리케이션 버전으로 전송되고 안정적인 서비스에 의해 80%가 안정적인 버전으로 전송됩니다.
5.1. OpenShift Service Mesh를 사용하여 트래픽을 라우팅하도록 Argo 롤아웃 구성
OpenShift Service Mesh를 사용하여 다음 항목을 생성하여 Argo 롤아웃을 구성할 수 있습니다.
- 게이트웨이
- 두 가지 Kubernetes 서비스: 각 서비스 버전 내에서 Pod를 가리키는 안정적인 및 카나리아
- A VirtualService
- 롤아웃 CR(사용자 정의 리소스)
다음 예제 절차에서 롤아웃은 트래픽의 20%를 카나리아 버전으로 라우팅합니다. 수동 승격 후 롤아웃은 트래픽의 40%를 라우팅합니다. 다른 수동 승격 후 롤아웃은 모든 트래픽이 새 애플리케이션 버전으로 라우팅될 때까지 여러 자동 승격을 수행합니다.
사전 요구 사항
- OpenShift Container Platform 클러스터에 관리자로 로그인되어 있습니다.
- OpenShift Container Platform 클러스터에 Red Hat OpenShift GitOps 를 설치했습니다.
- OpenShift Container Platform 클러스터에 Argo 롤아웃 이 설치되어 있어야 합니다.
- 시스템에 Argo 롤아웃 CLI 를 설치했습니다.
- 클러스터에 OpenShift Service Mesh Operator를 설치하고 ServiceMeshControlPlane 을 구성했습니다.
프로세스
메시에 대한 인바운드 트래픽을 수락할
게이트웨이
오브젝트를 만듭니다.다음 스니펫 콘텐츠를 사용하여 YAML 파일을 생성합니다.
rollouts-demo-gateway
라는 게이트웨이의 예apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: rollouts-demo-gateway 1 spec: selector: istio: ingressgateway 2 servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"
다음 명령을 실행하여 YAML 파일을 적용합니다.
$ oc apply -f gateway.yaml
카나리아 및 안정적인 버전의 애플리케이션에 대한 서비스를 생성합니다.
-
웹 콘솔의 관리자 화면에서 네트워킹
서비스로 이동합니다. - 서비스 생성을 클릭합니다.
서비스 생성 페이지에서 YAML 보기를 클릭하고 다음 스니펫을 추가합니다. 다음 예제에서는
rollouts-demo-stable
이라는 안정적인 서비스를 생성합니다. 안정적인 트래픽이 이 서비스로 전달됩니다.apiVersion: v1 kind: Service metadata: name: rollouts-demo-stable spec: ports: 1 - port: 80 targetPort: http protocol: TCP name: http selector: 2 app: rollouts-demo
- 생성 을 클릭하여 안정적인 서비스를 생성합니다.
서비스 생성 페이지에서 YAML 보기를 클릭하고 다음 스니펫을 추가합니다. 다음 예제에서는
rollouts-demo-canary
라는 카나리아 서비스를 생성합니다. 카나리아 트래픽은 이 서비스로 이동합니다.apiVersion: v1 kind: Service metadata: name: rollouts-demo-canary spec: ports: 1 - port: 80 targetPort: http protocol: TCP name: http selector: 2 app: rollouts-demo
- 생성 을 클릭하여 카나리아 서비스를 생성합니다.
-
웹 콘솔의 관리자 화면에서 네트워킹
들어오는 트래픽을 안정적인 카나리아 서비스로 라우팅하는 VirtualService를 생성합니다.
YAML 파일을 생성한 후 다음 YAML을 이 파일에 복사합니다. 다음 예제에서는
rollouts-demo-vsvc
라는VirtualService
를 생성합니다.apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: rollouts-demo-vsvc spec: gateways: - rollouts-demo-gateway 1 hosts: - rollouts-demo-vsvc.local http: - name: primary route: - destination: host: rollouts-demo-stable 2 port: number: 15372 3 weight: 100 - destination: host: rollouts-demo-canary 4 port: number: 15372 weight: 0 tls: 5 - match: - port: 3000 sniHosts: - rollouts-demo-vsvc.local route: - destination: host: rollouts-demo-stable weight: 100 - destination: host: rollouts-demo-canary weight: 0
다음 명령을 실행하여 YAML 파일을 적용합니다.
$ oc apply -f virtual-service.yaml
Rollout
CR을 생성합니다. 이 예에서는Istio
가 트래픽 관리자로 사용됩니다.-
웹 콘솔의 관리자 화면에서 Operator
설치된 Operator Red Hat OpenShift GitOps 롤아웃 으로 이동합니다. 롤아웃 생성 페이지에서 YAML 보기를 클릭하고 다음 스니펫을 추가합니다. 다음 예제에서는
rollouts-demo
라는롤아웃
CR을 생성합니다.apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: rollouts-demo spec: replicas: 5 strategy: canary: canaryService: rollouts-demo-canary 1 stableService: rollouts-demo-stable 2 trafficRouting: istio: virtualServices: - name: rollouts-demo-vsvc routes: - primary steps: 3 - setWeight: 20 - pause: {} - setWeight: 40 - pause: {} - setWeight: 60 - pause: {duration: 30} - setWeight: 80 - pause: {duration: 60} revisionHistoryLimit: 2 selector: 4 matchLabels: app: rollouts-demo template: metadata: labels: app: rollouts-demo istio-injection: enabled spec: containers: - name: rollouts-demo image: argoproj/rollouts-demo:blue ports: - name: http containerPort: 8080 protocol: TCP resources: requests: memory: 32Mi cpu: 5m
- 생성을 클릭합니다.
- 롤아웃 탭의 롤아웃 섹션에서 롤아웃 의 상태 필드에 단계: Healthy 가 표시되는지 확인합니다.
-
웹 콘솔의 관리자 화면에서 Operator
경로가 100%의 트래픽을 안정적인 버전의 애플리케이션으로 유도하는지 확인합니다.
다음 명령을 실행하여 롤아웃 진행을 확인합니다.
$ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1
- 1
Rollout
리소스가 정의된 네임스페이스를 지정합니다.
출력 예
Name: rollouts-demo Namespace: argo-rollouts Status: ✔ Healthy Strategy: Canary Step: 8/8 SetWeight: 100 ActualWeight: 100 Images: argoproj/rollouts-demo:blue (stable) Replicas: Desired: 5 Current: 5 Updated: 5 Ready: 5 Available: 5 NAME KIND STATUS AGE INFO ⟳ rollouts-demo Rollout ✔ Healthy 4m50s └──# revision:1 └──⧉ rollouts-demo-687d76d795 ReplicaSet ✔ Healthy 4m50s stable ├──□ rollouts-demo-687d76d795-75k57 Pod ✔ Running 4m49s ready:1/1 ├──□ rollouts-demo-687d76d795-bv5zf Pod ✔ Running 4m49s ready:1/1 ├──□ rollouts-demo-687d76d795-jsxg8 Pod ✔ Running 4m49s ready:1/1 ├──□ rollouts-demo-687d76d795-rsgtv Pod ✔ Running 4m49s ready:1/1 └──□ rollouts-demo-687d76d795-xrmrj Pod ✔ Running 4m49s ready:1/1
참고Rollout
리소스의 첫 번째 인스턴스가 생성되면 롤아웃은 안정적이고 카나리아 애플리케이션 버전으로 전달될 트래픽 양을 조정합니다. 초기 인스턴스에서Rollout
리소스 생성은 모든 트래픽을 애플리케이션의 안정적인 버전으로 라우팅하고 트래픽이 카나리아 버전으로 전송되는 부분을 건너뜁니다.서비스 메시가 안정적인 서비스에 대한 트래픽의 100%와 카나리아 서비스에 대해 0%를 전송하는지 확인하려면 다음 명령을 실행합니다.
$ oc describe virtualservice/rollouts-demo-vsvc -n <namespace>
터미널에 표시된 다음 출력을 확인합니다.
route - destination: host: rollouts-demo-stable weight: 100 1 - destination: host: rollouts-demo-canary weight: 0 2
롤아웃에 배포된 컨테이너 이미지를 수정하여 애플리케이션의 새 카나리아 버전을 시뮬레이션합니다.
다음 명령을 실행하여
argoproj/rollouts-demo:blue
toargoproj/rollouts-demo:yellow
에서.spec.template.spec.containers.image
값을 수정합니다.$ oc argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow -n <namespace>
결과적으로 롤아웃에 배포된 컨테이너 이미지가 수정되고 롤아웃에서 새 카나리아 배포를 시작합니다.
참고Rollout
리소스의.spec.strategy.canary.steps
필드에 정의된setWeight
속성에 따라 처음에 경로에 대한 트래픽의 20%가 카나리아 버전에 도달하고 트래픽의 80%가 안정적인 버전으로 이동합니다. 트래픽의 20%가 카나리아 버전으로 전달된 후 롤아웃이 일시 중지됩니다.다음 명령을 실행하여 롤아웃 진행을 확인합니다.
$ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1
- 1
Rollout
리소스가 정의된 네임스페이스를 지정합니다.
다음 예에서 트래픽의 80%가 안정적인 서비스로 라우팅되고 트래픽의 20%는 카나리아 서비스로 라우팅됩니다. 그런 다음 수동으로 다음 수준으로 승격할 때까지 배포가 무기한 일시 중지됩니다.
출력 예
Name: rollouts-demo Namespace: argo-rollouts Status: ॥ Paused Message: CanaryPauseStep Strategy: Canary Step: 1/8 SetWeight: 20 ActualWeight: 20 Images: argoproj/rollouts-demo:blue (stable) argoproj/rollouts-demo:yellow (canary) Replicas: Desired: 5 Current: 6 Updated: 1 Ready: 6 Available: 6 NAME KIND STATUS AGE INFO ⟳ rollouts-demo Rollout ॥ Paused 6m51s ├──# revision:2 │ └──⧉ rollouts-demo-6cf78c66c5 ReplicaSet ✔ Healthy 99s canary │ └──□ rollouts-demo-6cf78c66c5-zrgd4 Pod ✔ Running 98s ready:1/1 └──# revision:1 └──⧉ rollouts-demo-687d76d795 ReplicaSet ✔ Healthy 9m51s stable ├──□ rollouts-demo-687d76d795-75k57 Pod ✔ Running 9m50s ready:1/1 ├──□ rollouts-demo-687d76d795-jsxg8 Pod ✔ Running 9m50s ready:1/1 ├──□ rollouts-demo-687d76d795-rsgtv Pod ✔ Running 9m50s ready:1/1 └──□ rollouts-demo-687d76d795-xrmrj Pod ✔ Running 9m50s ready:1/1
안정적인 버전으로 향하는 80%의 트래픽과 카나리아 버전으로 전송되는 트래픽의 20%를 예로 들 수 있습니다.
route - destination: host: rollouts-demo-stable weight: 80 1 - destination: host: rollouts-demo-canary weight: 20 2
배포를 다음 승격 단계로 수동으로 승격합니다.
$ oc argo rollouts promote rollouts-demo -n <namespace> 1
- 1
Rollout
리소스가 정의된 네임스페이스를 지정합니다.
다음 명령을 실행하여 롤아웃 진행을 확인합니다.
$ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1
- 1
Rollout
리소스가 정의된 네임스페이스를 지정합니다.
다음 예에서 트래픽의 60%는 안정적인 서비스로 라우팅되고 트래픽의 40%는 카나리아 서비스로 라우팅됩니다. 그런 다음 수동으로 다음 수준으로 승격할 때까지 배포가 무기한 일시 중지됩니다.
출력 예
Name: rollouts-demo Namespace: argo-rollouts Status: ॥ Paused Message: CanaryPauseStep Strategy: Canary Step: 3/8 SetWeight: 40 ActualWeight: 40 Images: argoproj/rollouts-demo:blue (stable) argoproj/rollouts-demo:yellow (canary) Replicas: Desired: 5 Current: 7 Updated: 2 Ready: 7 Available: 7 NAME KIND STATUS AGE INFO ⟳ rollouts-demo Rollout ॥ Paused 9m21s ├──# revision:2 │ └──⧉ rollouts-demo-6cf78c66c5 ReplicaSet ✔ Healthy 99s canary │ └──□ rollouts-demo-6cf78c66c5-zrgd4 Pod ✔ Running 98s ready:1/1 └──# revision:1 └──⧉ rollouts-demo-687d76d795 ReplicaSet ✔ Healthy 9m51s stable ├──□ rollouts-demo-687d76d795-75k57 Pod ✔ Running 9m50s ready:1/1 ├──□ rollouts-demo-687d76d795-jsxg8 Pod ✔ Running 9m50s ready:1/1 ├──□ rollouts-demo-687d76d795-rsgtv Pod ✔ Running 9m50s ready:1/1 └──□ rollouts-demo-687d76d795-xrmrj Pod ✔ Running 9m50s ready:1/1
안정적인 버전으로 전송되는 60 % 트래픽의 예와 카나리아 버전으로 향하는 40%의 트래픽입니다.
route - destination: host: rollouts-demo-stable weight: 60 1 - destination: host: rollouts-demo-canary weight: 40 2
카나리아 버전의 트래픽 가중치를 100%로 늘리고 다음 명령을 실행하여 애플리케이션의 이전 안정적인 버전의 트래픽을 삭제합니다.
$ oc argo rollouts promote rollouts-demo -n <namespace> 1
- 1
Rollout
리소스가 정의된 네임스페이스를 지정합니다.
다음 명령을 실행하여 롤아웃 진행을 확인합니다.
$ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1
- 1
Rollout
리소스가 정의된 네임스페이스를 지정합니다.
성공적으로 완료되면 안정적인 서비스의 가중치는 카나리아 서비스의 100% 및 0%입니다.