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%가 전달됩니다. 애플리케이션이 예상대로 실행되고 있으며 새 버전을 배포하려는 추가 시도가 이루어지지 않습니다.

안정적인 버전의 애플리케이션의 트래픽 100%

그러나 새 버전의 애플리케이션을 배포한 후 Argo Rollouts는 새 버전의 애플리케이션을 기반으로 새 카나리아 배포를 생성하고 일부 트래픽 백분율을 해당 새 버전으로 라우팅합니다.

서비스 메시를 사용하는 경우 Argo Rollouts는 VirtualService 리소스를 자동으로 수정하여 안정적인 및 카나리아 애플리케이션 버전 간의 트래픽 분할 백분율을 제어합니다. 다음 다이어그램에서는 첫 번째 승격 후 트래픽의 20%가 카나리아 애플리케이션 버전으로 전송되고 안정적인 서비스에 의해 80%가 안정적인 버전으로 전송됩니다.

안정적인 버전의 트래픽의 80% 및 카나리아 버전의 20%

5.1. OpenShift Service Mesh를 사용하여 트래픽을 라우팅하도록 Argo 롤아웃 구성

OpenShift Service Mesh를 사용하여 다음 항목을 생성하여 Argo 롤아웃을 구성할 수 있습니다.

  • 게이트웨이
  • 두 가지 Kubernetes 서비스: 각 서비스 버전 내에서 Pod를 가리키는 안정적인 및 카나리아
  • A VirtualService
  • 롤아웃 CR(사용자 정의 리소스)

다음 예제 절차에서 롤아웃은 트래픽의 20%를 카나리아 버전으로 라우팅합니다. 수동 승격 후 롤아웃은 트래픽의 40%를 라우팅합니다. 다른 수동 승격 후 롤아웃은 모든 트래픽이 새 애플리케이션 버전으로 라우팅될 때까지 여러 자동 승격을 수행합니다.

사전 요구 사항

프로세스

  1. 메시에 대한 인바운드 트래픽을 수락할 게이트웨이 오브젝트를 만듭니다.

    1. 다음 스니펫 콘텐츠를 사용하여 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:
          - "*"

      1
      게이트웨이의 이름입니다.
      2
      수신 게이트웨이의 이름을 지정합니다. 게이트웨이는 노출된 포트 및 프로토콜을 구성하지만 트래픽 라우팅 구성은 포함되지 않습니다.
    2. 다음 명령을 실행하여 YAML 파일을 적용합니다.

      $ oc apply -f gateway.yaml
  2. 카나리아 및 안정적인 버전의 애플리케이션에 대한 서비스를 생성합니다.

    1. 웹 콘솔의 관리자 화면에서 네트워킹 서비스로 이동합니다.
    2. 서비스 생성을 클릭합니다.
    3. 서비스 생성 페이지에서 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
      1
      컨테이너 내부에서 실행하기 위해 애플리케이션에서 사용하는 포트의 이름을 지정합니다.
      2
      selector 필드의 콘텐츠가 안정적인 service 및 Rollout CR에서 동일한지 확인합니다.
    4. 생성 을 클릭하여 안정적인 서비스를 생성합니다.
    5. 서비스 생성 페이지에서 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
      1
      컨테이너 내부에서 실행하기 위해 애플리케이션에서 사용하는 포트의 이름을 지정합니다.
      2
      selector 필드의 콘텐츠가 카나리아 서비스 및 롤아웃 CR에서 동일한지 확인합니다.
    6. 생성 을 클릭하여 카나리아 서비스를 생성합니다.
  3. 들어오는 트래픽을 안정적인 카나리아 서비스로 라우팅하는 VirtualService를 생성합니다.

    1. 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
      1
      게이트웨이의 이름입니다.
      2
      대상 안정적인 서비스의 이름입니다.
      3
      트래픽을 수신하는 데 사용되는 포트 번호를 지정합니다.
      4
      대상 카나리아 서비스의 이름입니다.
      5
      VirtualService를 보호하는 데 사용되는 TLS 구성을 지정합니다.
    2. 다음 명령을 실행하여 YAML 파일을 적용합니다.

      $ oc apply -f virtual-service.yaml
  4. Rollout CR을 생성합니다. 이 예에서는 Istio 가 트래픽 관리자로 사용됩니다.

    1. 웹 콘솔의 관리자 화면에서 Operator 설치된 Operator Red Hat OpenShift GitOps 롤아웃 으로 이동합니다.
    2. 롤아웃 생성 페이지에서 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
      1
      이 값은 생성된 카나리아 서비스 의 이름과 일치해야 합니다.
      2
      이 값은 생성된 안정적인 서비스 의 이름과 일치해야 합니다.
      3
      롤아웃 단계를 지정합니다. 이 예에서는 카나리아 버전으로 트래픽의 20%, 40%, 60% 및 100%를 모두 라우팅합니다.
      4
      selector 필드의 콘텐츠가 카나리아 및 안정적인 서비스의 내용과 동일한지 확인합니다.
    3. 생성을 클릭합니다.
    4. 롤아웃 탭의 롤아웃 섹션에서 롤아웃상태 필드에 단계: Healthy 가 표시되는지 확인합니다.
  5. 경로가 100%의 트래픽을 안정적인 버전의 애플리케이션으로 유도하는지 확인합니다.

    1. 다음 명령을 실행하여 롤아웃 진행을 확인합니다.

      $ 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 리소스 생성은 모든 트래픽을 애플리케이션의 안정적인 버전으로 라우팅하고 트래픽이 카나리아 버전으로 전송되는 부분을 건너뜁니다.

    2. 서비스 메시가 안정적인 서비스에 대한 트래픽의 100%와 카나리아 서비스에 대해 0%를 전송하는지 확인하려면 다음 명령을 실행합니다.

      $ oc describe virtualservice/rollouts-demo-vsvc -n <namespace>
    3. 터미널에 표시된 다음 출력을 확인합니다.

      route
      - destination:
          host: rollouts-demo-stable
        weight: 100 1
      - destination:
          host: rollouts-demo-canary
        weight: 0 2
      1
      100 은 트래픽의 100%가 안정적인 버전으로 전달됨을 의미합니다.
      2
      0 은 트래픽의 0%가 카나리아 버전으로 전달됨을 의미합니다.
  6. 롤아웃에 배포된 컨테이너 이미지를 수정하여 애플리케이션의 새 카나리아 버전을 시뮬레이션합니다.

    1. 다음 명령을 실행하여 argoproj/rollouts-demo:blue to argoproj/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%가 카나리아 버전으로 전달된 후 롤아웃이 일시 중지됩니다.

    2. 다음 명령을 실행하여 롤아웃 진행을 확인합니다.

      $ 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

      1
      80 은 트래픽의 80%가 안정적인 버전으로 전달됨을 의미합니다.
      2
      20 은 트래픽의 20%가 카나리아 버전으로 전달됨을 의미합니다.
  7. 배포를 다음 승격 단계로 수동으로 승격합니다.

    $ oc argo rollouts promote rollouts-demo -n <namespace> 1
    1
    Rollout 리소스가 정의된 네임스페이스를 지정합니다.
    1. 다음 명령을 실행하여 롤아웃 진행을 확인합니다.

      $ 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

      1
      60 은 트래픽의 60 %가 안정적인 버전으로 전달됨을 의미합니다.
      2
      40 은 트래픽의 40%가 카나리아 버전으로 전달됨을 의미합니다.
  8. 카나리아 버전의 트래픽 가중치를 100%로 늘리고 다음 명령을 실행하여 애플리케이션의 이전 안정적인 버전의 트래픽을 삭제합니다.

    $ oc argo rollouts promote rollouts-demo -n <namespace> 1
    1
    Rollout 리소스가 정의된 네임스페이스를 지정합니다.
    1. 다음 명령을 실행하여 롤아웃 진행을 확인합니다.

      $ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1
      1
      Rollout 리소스가 정의된 네임스페이스를 지정합니다.

성공적으로 완료되면 안정적인 서비스의 가중치는 카나리아 서비스의 100% 및 0%입니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.