카나리아 배포 전략 사용

이 문서에서는 카나리아 배포 전략을 구성하고 사용하는 방법을 설명합니다.

카나리아 배포란 무엇인가요?

카나리아 배포는 이미 배포된 버전과 새 버전 간에 트래픽을 분할하여 완전히 배포되기 전에 일부 사용자에게 배포하는 애플리케이션의 점진적 출시입니다.

지원되는 대상 유형

Cloud Deploy에서 카나리아 배포는 다음을 포함하여 모든 대상 유형을 지원합니다.

Google Kubernetes Engine
Cloud Run(작업 아님, 서비스만)
GKE Enterprise

카나리아는 다중 대상에서도 작동합니다.

카나리아 배포 전략을 사용하는 이유는 무엇인가요?

카나리아 배포를 사용하면 애플리케이션을 부분적으로 출시할 수 있습니다. 이렇게 하면 모든 사용자에게 새 버전의 애플리케이션을 제공하기 전에 안정성을 확인할 수 있습니다.

예를 들어 GKE 또는 GKE Enterprise에 배포하는 경우 제한된 수의 포드에 애플리케이션의 새 버전을 배포할 수 있습니다. 이전 버전은 계속 실행되지만 더 많은 트래픽이 새 포드로 전송됩니다.

Cloud Run에 배포할 경우 Cloud Run 자체는 구성하는 비율에 따라 이전 버전과 새 버전 간에 트래픽을 분할합니다.

카나리아 유형

Cloud Deploy를 사용하면 다음 유형의 카나리아 배포를 구성할 수 있습니다.

자동

자동 카나리아 배포의 경우 점진적 배포를 표현하는 일련의 백분율로 Cloud Deploy를 구성합니다. Cloud Deploy는 추가 작업을 자동으로 수행해서 이전 및 신규 버전 사이에 트래픽 백분율을 할당합니다.
커스텀 자동

커스텀 자동 카나리아의 경우 다음을 제공할 수 있습니다.
- 단계 이름
- 백분율 목표
- 단계에 사용할 Skaffold 프로필
- 확인 작업 포함 여부
하지만 트래픽 균형 조정 정보를 제공할 필요가 없습니다. 여기에 설명된 대로 Cloud Deploy가 필요한 리소스를 만듭니다.
커스텀

커스텀 카나리아를 사용하면 다음을 포함하여 각 카나리아 단계를 개별적으로 구성합니다.
- 단계 이름
- 백분율 목표
- 단계에 사용할 Skaffold 프로필
- 확인 작업 포함 여부
또한 완전 커스텀 카나리아의 경우 여기에 설명된 대로 모든 트래픽 분산 구성을 제공합니다.

카나리아 배포 단계

카나리아 배포용 출시 버전을 만들면 각 카나리아 증분 단계와 100%를 위한 최종 stable 단계로 출시가 생성됩니다.

예를 들어 카나리아를 25%, 50%, 75% 단위로 구성하면 출시가 다음 단계로 진행됩니다.

canary-25
canary-50
canary-75
stable

출시 단계, 작업, 작업 실행에 대한 자세한 내용은 출시 관리를 참조하세요.

자동 카나리아 또는 커스텀 자동 카나리아에서 발생하는 일

카나리아 배포를 지원하기 위해 Cloud Deploy에는 Kubernetes 매니페스트 또는 Cloud Run 서비스 구성을 렌더링할 때 특수한 처리 단계가 포함됩니다.

GKE/GKE Enterprise(네트워크)

Cloud Deploy가 네트워크 기반 GKE 및 GKE Enterprise에서 카나리아 배포를 실행하는 방법은 다음과 같습니다.

배포 리소스 및 서비스 리소스 이름을 제공합니다.
Cloud Deploy가 현재 배포 이름과 -canary를 사용해서 추가적인 배포 리소스를 만듭니다.
Cloud Deploy가 서비스를 수정하여 현재 배포 및 카나리아 포드의 포드를 선택하도록 선택기를 조정합니다.

Cloud Deploy는 여기에 설명된 계산을 기반으로 카나리아에 사용할 포드 수를 계산합니다. 이 계산은 포드 오버프로비저닝 사용 설정 또는 중지 여부에 따라 달라집니다.

stable 단계로 건너뛰는 경우 Cloud Deploy가 후속 카나리아 실행에 사용할 수 있도록 포드 일치에 사용할 라벨을 추가합니다.

Cloud Deploy가 단계별 포드의 백분율이 포함된 배포를 만들어서 각 단계에 대해 업데이트합니다. 이렇게 하려면 포드 수를 원래 포드 수의 백분율로 계산합니다. 이로 인해 부정확한 트래픽 분할이 발생할 수 있습니다. 정확한 트래픽 분할이 필요한 경우 Gateway API를 사용하면 됩니다.

또한 -canary를 사용하여 보안 비밀 및 ConfigMap을 복사하고 이름을 변경합니다.
stable 단계 중에는 -canary 배포가 0으로 축소되고 원래 배포가 새 배포로 바뀝니다.

Cloud Deploy가 stable 단계까지 원래 배포를 수정하지 않습니다.

Cloud Deploy는 요청된 카나리아 백분율을 최대한 달성하기 위해 포드를 프로비저닝합니다. 이는 포드에 대한 트래픽이 아닌 포드 수를 기준으로 합니다. 카나리아가 트래픽을 기반으로 하려면 Gateway API를 사용해야 합니다.

GKE 네트워크 기반 카나리아의 경우 포드 오버프로비저닝을 사용 설정 또는 중지할 수 있습니다. 다음 섹션에서는 Cloud Deploy가 각 카나리아 단계에서 카나리아 배포에 프로비저닝할 포드 수를 계산하는 방법을 설명합니다.

오버프로비저닝이 사용 설정된 포드 프로비저닝

오버프로비저닝(disablePodOverprovisioning: false)을 사용 설정하면 Cloud Deploy에서 기존 배포를 실행하는 포드 수를 기준으로 사용자가 원하는 카나리아 백분율을 실행하기에 충분한 추가 포드를 만들 수 있습니다. 다음 수식은 포드 오버프로비저닝이 사용 설정된 경우 Cloud Deploy가 각 카나리아 단계에서 카나리아 배포에 프로비저닝할 포드 수를 계산하는 방법을 보여줍니다.

math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))

이 수식에서는 현재 복제본 수(카나리아 전에 이미 보유하고 있던 포드 수)에 해당 단계의 카나리아 백분율을 곱하고, 그 결과를 (100에서 해당 백분율을 뺀 값)으로 나눕니다.

예를 들어 4개의 포드가 이미 있고 카나리아 단계가 50%인 경우 카나리아 포드 수는 4개입니다. (100-percentage의 결과가 백분율: 100-50=50으로 사용되고 .50으로 처리됩니다.)

포드 오버프로비저닝은 기본 동작입니다.

오버프로비저닝이 중지된 포드 프로비저닝

Cloud Deploy가 복제본 수를 늘리지 않도록 오버프로비저닝(disablePodOverprovisioning: true)을 중지할 수 있습니다.

다음 수식은 포드 오버프로비저닝이 중지된 경우 Cloud Deploy가 각 카나리아 단계에서 카나리아 배포의 포드 프로비저닝을 계산하는 방법을 보여줍니다.

math.Ceil( (ReplicaCountOfDeploymentOnCluster + ReplicaCountOfCanaryDeploymentOnCluster) * percentage)

이 수식에서 ReplicaCountOfCanaryDeploymentOnCluster는 카나리아 단계가 이미 있는 경우에만 존재합니다. 첫 번째 카나리아 단계인 경우 ReplicaCountOfCanaryDeploymentOnCluster는 없습니다.

포드 4개로 시작하는 경우 이 숫자에 카나리아 백분율(예: 50% 또는 .5)을 곱하면 2를 얻을 수 있습니다. 따라서 원래 배포가 이제 2개로 축소되고 카나리아 배포에는 2개의 새 포드가 생성됩니다. 카나리아 단계가 75%이면 2(원본 배포) +2(첫 번째 카나리아 단계) *.75를 통해 카나리아 포드 3개와 원래 배포를 실행하는 포드 1개를 얻게 됩니다.

GKE/GKE Enterprise(게이트웨이)

Cloud Deploy가 Gateway API를 사용해서 GKE 및 GKE Enterprise에서 카나리아 배포를 실행하는 방법은 다음과 같습니다.

배포 및 서비스 참조 외에도 HTTPRoute 리소스에 서비스를 참조하는 backendRefs 규칙을 제공합니다.
Cloud Deploy는 원래 배포 이름에 -canary가 추가된 새 배포와 원래 서비스 이름에 -canary가 추가된 새 서비스를 만듭니다.

또한 보안 비밀, ConfigMap, 수평형 포드 자동 확장 처리는 -canary를 사용하여 복사되고 이름이 변경됩니다.
각 카나리아 단계에서 Cloud Deploy는 해당 단계의 백분율에 따라 원래 배포의 포드와 카나리아 배포의 포드 간의 가중치를 업데이트하도록 HTTPRoute를 수정합니다.

HTTPRoute 리소스 변경사항 전파가 지연될 수 있으므로 구성에 routeUpdateWaitTime 속성을 포함합니다. 그러면 시스템에서 전파를 위해 지정된 시간을 기다립니다.
stable 단계 중에는 -canary 배포가 0으로 축소되고 원래 배포가 새 릴리스 배포를 사용하도록 업데이트됩니다.

또한 HTTPRoute가 원래 사용자가 제공한 값으로 돌아갑니다.

Cloud Deploy는 stable 단계까지 원래 배포 또는 서비스를 수정하지 않습니다.

Cloud Run

Cloud Deploy가 Cloud Run에 대해 카나리아 배포를 실행하는 방법은 다음과 같습니다.

Cloud Run에 카나리아 배포를 수행하려면 서비스 YAML에서 traffic 스탠자를 제공하지 않습니다.
카나리아용 새 출시를 만들 때 Cloud Deploy는 Cloud Deploy에서 성공적으로 배포된 이전 버전과 새 버전 간에 트래픽을 분할합니다.

카나리아 배포의 단계 간 차이를 보려면 출시 버전 검사기에서 제공되는 단계별 렌더링 매니페스트의 변경사항을 확인하면 됩니다. 출시가 시작되기 전에도 이 작업을 수행할 수 있습니다. 또한 병렬 배포를 사용하는 경우 각 하위 항목의 렌더링된 매니페스트를 조사할 수 있습니다.

카나리아 배포 구성

이 섹션에서는 카나리아 배포를 위한 배포 파이프라인 및 대상을 구성하는 방법을 설명합니다.

이 안내에는 카나리아 구성과 관련된 내용만 포함됩니다. 애플리케이션 배포 문서에는 배포 파이프라인을 구성하고 실행하기 위한 일반적인 안내가 있습니다.

필수 권한 필요

Cloud Deploy를 사용하는 데 필요한 다른 Identity and Access Management 권한 외에도 카나리아 배포에 필요할 수 있는 추가 작업을 수행하기 위해 다음 권한이 필요합니다.

clouddeploy.rollouts.advance
clouddeploy.rollouts.ignoreJob
clouddeploy.rollouts.cancel
clouddeploy.rollouts.retryJob
clouddeploy.jobRuns.get
clouddeploy.jobRuns.list
clouddeploy.jobRuns.terminate

이러한 권한이 포함된 사용 가능한 역할에 대한 자세한 내용은 IAM 역할 및 권한을 참조하세요.

`skaffold.yaml` 준비

표준 배포와 마찬가지로 카나리아에는 매니페스트와 서비스 정의가 렌더링되고 배포되는 방법을 정의하는 skaffold.yaml 파일이 필요합니다.

카나리아 배포를 위해 만드는 skaffold.yaml에는 표준 배포에 필요한 항목 외에 특별한 요구사항이 없습니다.

매니페스트 또는 서비스 정의 준비

표준 배포와 마찬가지로 카나리아에는 Kubernetes 매니페스트 또는 Cloud Run 서비스 정의가 필요합니다.

GKE 및 GKE Enterprise

카나리아의 경우 매니페스트에 다음이 포함되어야 합니다.

배포 및 서비스
서비스는 app 선택기를 정의해야 하며 지정된 배포의 포드를 선택해야 합니다.
Gateway API 기반 카나리아를 사용하는 경우 매니페스트에 HTTPRoute도 있어야 합니다.

Cloud Run

Cloud Run에서 카나리아를 사용하는 경우 일반 Cloud Run 서비스 정의 파일로 충분하지만 traffic 스탠자가 없습니다. Cloud Deploy는 마지막으로 성공한 수정과 신규 수정 사이에 트래픽 분할을 관리합니다.

자동화된 카나리아 구성

다음은 Cloud Run, GKE 및 GKE Enterprise 서비스 기반 네트워킹 대상에 대한 안내입니다. GKE 또는 GKE Enterprise에서 Kubernetes Gateway API를 사용하는 경우 이 문서를 참조하세요.

배포 파이프라인 정의에서 자동화된 카나리아를 구성합니다.

GKE 및 GKE Enterprise

파이프라인 단계에서 다음과 같이 strategy 속성을 포함합니다.

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false

이 구성에서

SERVICE_NAME은 매니페스트에 정의된 Kubernetes 서비스의 이름입니다.
DEPLOYMENT_NAME은 매니페스트에 정의된 Kubernetes 배포의 이름입니다.
PERCENTAGES는 카나리아 증분을 나타내는 쉼표로 구분된 백분율 값 목록입니다(예: [5, 25, 50]).

또한 카나리아에서 100% 배포가 간주되고 stable 단계에서 처리되므로 여기에는 100이 포함되지 않습니다.
배포 확인(verify: true)을 사용 설정할 수 있습니다. 이렇게 하면 각 단계에서 verify 작업이 사용 설정됩니다.

Cloud Run

파이프라인 단계에서 다음과 같이 strategy 속성을 포함합니다.

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false

이 구성에서

PERCENTAGES는 카나리아 증분을 나타내는 쉼표로 구분된 백분율 값 목록입니다(예: [25, 50, 75]). 카나리아에서 100% 배포가 간주되고 stable 단계에서 처리되므로 여기에는 100이 포함되지 않습니다.
배포 확인(verify: true)을 사용 설정할 수 있습니다. 이렇게 하면 각 카나리아 단계에 verify 작업이 추가됩니다.

커스텀 카나리아 구성

Cloud Deploy에서 제공하는 자동화에 완전히 의존하는 대신 카나리아를 수동으로 구성할 수 있습니다. 커스텀 카나리아 구성을 사용하면 배포 파이프라인 정의에 다음을 지정합니다.

출시 단계 이름

완전 자동화된 카나리아에서 Cloud Deploy는 단계 이름을 지정합니다(예: canary-25, canary-75, stable). 그러나 커스텀 카나리아를 사용하면 이 카나리아 단계의 모든 단계에서 고유하고 리소스 이름 제한을 준수하는 한 각 단계에 이름을 지정할 수 있습니다. 하지만 최종(100%) 단계 이름은 stable이어야 합니다.
단계별 백분율 목표

단계마다 백분율을 별도로 지정합니다.
단계에 사용할 Skaffold 프로필

각 단계 또는 동일한 프로필 또는 모든 조합에 대해 별도의 Skaffold 프로필을 사용할 수 있습니다. 각 프로필은 서로 다른 Kubernetes 매니페스트 또는 Cloud Run 서비스 정의를 사용할 수 있습니다. 또한 지정된 단계에 대해 하나를 초과하는 프로필을 사용할 수 있습니다. Cloud Deploy는 이를 결합합니다.
단계에 확인 작업이 있는지 여부

확인을 사용 설정하는 경우 확인을 위해 skaffold.yaml도 구성해야 합니다.

커스텀 카나리아는 모든 대상 유형을 지원합니다.

커스텀 카나리아 구성 요소

다음 YAML은 완전 커스텀 카나리아 배포 단계의 구성을 보여줍니다.

strategy:
  canary:
    # Custom configuration for each canary phase
    customCanaryDeployment:
      phaseConfigs:
      - phaseId: "PHASE1_NAME"
        percentage: PERCENTAGE1
        profiles: [ "PROFILE_NAME" ]
        verify: true | false
      - …
      - phaseId: "stable"
        percentage: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        verify: true|false

이 YAML에서

PHASE1_NAME

단계 이름입니다. 각 단계 이름은 고유해야 합니다.
[ "PROFILE_NAME" ]

단계에 사용할 프로필의 이름입니다. 각 단계에 동일한 프로필을 사용하거나 단계마다 다른 프로필을 사용하거나 이를 조합하여 사용할 수 있습니다. 또한 프로필을 하나 넘게 지정할 수 있습니다. Cloud Deploy는 지정된 모든 프로필과 함께 전체 단계에서 사용되는 프로필 또는 매니페스트를 사용합니다.
PERCENTAGE1

첫 번째 단계에 배포할 백분율입니다. 각 단계에는 고유한 백분율 값이 있어야 하며 해당 값은 전체 백분율(예: 10.5 아님)이어야 하며 단계는 오름차순이어야 합니다.
verify: true|false

단계에 대해 확인 작업을 포함할지 여부를 Cloud Deploy에 알려줍니다. 확인을 사용할 각 단계에 대해 Scaffold는 해당 단계에 대해 렌더링 및 배포에 지정된 동일한 프로파일을 확인에 사용합니다.
stable

마지막 단계의 이름은 stable이어야 합니다.

마지막 단계의 백분율은 100이어야 합니다. 이 customCanaryDeployment 스탠자에서 구성한 순서에 따라 단계가 실행되지만 백분율 값이 오름차순이 아닌 경우 배포 파이프라인을 등록하는 명령어가 실패하고 오류가 발생합니다.

커스텀 카나리아 구성에는 runtimeConfig 스탠자가 포함되지 않습니다. runtimeConfig를 포함하면 커스텀 자동 카나리아로 간주됩니다.

커스텀 자동 카나리아 구성

커스텀 자동 카나리아는 커스텀 단계 이름, 백분율 값, Skaffold 프로필, 확인 작업을 사용하여 별도의 카나리아 단계를 지정하므로 커스텀 카나리아와 비슷합니다. 그러나 커스텀 카나리아를 사용하면 사용자는 트래픽 할당을 정의하는 구성을 제공하지 않습니다. Cloud Deploy가 이를 대신 수행합니다. 그러나 사용자는 여전히 각 단계에 사용될 Skaffold 프로필을 제공합니다.

커스텀 자동 카나리아를 구성하려면 여기에 표시된 대로 runtimeConfig 스탠자를 포함하고 여기에 표시된 대로 customCanaryDeployment 스탠자를 포함하세요.

Kubernetes Gateway API 서비스 메시를 사용하여 카나리아 배포 구성

Cloud Deploy 카나리아 배포를 사용할 수 하여 Kubernetes 서비스 기반 네트워킹에 애플리케이션 배포할 수 있지만 Kubernetes Gateway API 서비스 메시를 사용하는 다른 대안이 있습니다. 이 섹션에서는 이를 수행하는 방법을 모두 설명합니다.

Istio 또는 모든 지원되는 구현에서 Gateway API를 사용할 수 있습니다.

Gateway API 리소스를 설정합니다.
- Istio 사용
- GKE 게이트웨이 컨트롤러
다음은 이해를 돕기 위한 예시입니다.
출시 버전을 만들 때 Cloud Deploy에 제공되는 Kubernetes 매니페스트에는 다음이 포함됩니다.
- 게이트웨이 리소스를 참조하는 HTTPRoute입니다.
- 배포
- 서비스
카나리아 배포를 수행할 배포 파이프라인과 대상을 구성합니다.
- 대상의 구성은 모든 대상과 동일합니다.
- 특정 대상에 대한 진행 시퀀스의 배포 파이프라인 구성에는 Kubernetes Gateway API HTTPRoute 구성, 배포, 서비스를 참조하는 gatewayServiceMesh 스탠자가 포함되어 있습니다.
```
strategy:
 canary:
   runtimeConfig:
     kubernetes:
       gatewayServiceMesh:
         httpRoute: "ROUTE"
         service: "SERVICE"
         deployment: "DEPLOYMENT"
         routeUpdateWaitTime: "WAIT_TIME"
   canaryDeployment:
     percentages:
     - 50
```
  각 항목의 의미는 다음과 같습니다.
  - ROUTE는 원하는 라우팅 동작을 정의하는 httpRoute 구성입니다.
  - SERVICE는 GKE 및 GKE Enterprise에 대한 카나리아 배포를 위해 Cloud Deploy에 필요한 서비스 구성입니다.
  - DEPLOYMENT는 GKE 및 GKE Enterprise에 대한 카나리아 배포를 위해 Cloud Deploy에 필요한 배포 구성입니다.
  - WAIT_TIME은 삭제된 요청이 없도록 HTTPRoute 리소스 변경사항이 전파를 완료할 때까지 Cloud Deploy에서 대기하는 시간입니다. 예를 들면 routeUpdateWaitTime: 60s입니다.
    
    Istio 없이 Gateway API를 사용해서 카나리아를 실행하는 중이고 Gateway API가 Google Cloud 부하 분산기에 연결되어 있으면 카나리아 인스턴스를 축소할 때 소량의 트래픽이 손실될 수 있습니다. 이 동작이 관찰되면 이 설정을 구성할 수 있습니다.

카나리아 배포 전략으로 동시 배포 사용

병렬 배포를 사용하여 카나리아 배포를 실행할 수 있습니다. 즉, 점진적으로 배포하는 대상이 두 개 이상의 하위 대상으로 구성될 수 있다는 의미입니다. 예를 들어 동시에 개별 리전의 클러스터에 점진적으로 배포할 수 있습니다.

동시 카나리아와 단일 대상 카나리아의 차이점

단일 대상 카나리아 배포와 마찬가지로 GKE 대상에 배포하는 경우 매니페스트에 Kubernetes 배포 구성과 Kubernetes 서비스 구성이 필요합니다.
단일 대상 카나리아 배포와 마찬가지로 배포 파이프라인 구성에는 해당 단계에 대한 단계 정의 내에 strategy.canary 스탠자가 포함되어야 합니다.
또한 다중 대상을 구성해야 하며 이 다중 대상이 참조하는 하위 대상을 구성해야 합니다.
출시 버전을 만들면 컨트롤러 출시와 하위 출시가 생성됩니다.

컨트롤러와 하위 출시 유형 모두 구성된 모든 카나리아 백분율에 대해 별도의 단계가 있으며 카나리아 100%에 대한 stable 단계가 있습니다.
하위 출시를 진행할 수 없습니다.

컨트롤러 출시만 진행할 수 있습니다. 컨트롤러 출시를 다음 단계로 진행하면 하위 항목 출시도 Cloud Deploy에서 진행됩니다.
컨트롤러 출시에서 실패한 작업은 재시도할 수 없습니다.

하위 출시에서만 작업을 재시도할 수 있습니다.
컨트롤러 출시에서 실패한 작업을 무시할 수 없습니다.

하위 출시에서만 실패한 작업을 무시할 수 있습니다.
컨트롤러 출시를 취소할 수 있지만 하위 출시를 취소할 수는 없습니다.
컨트롤러 출시가 아닌 하위 출시에서만 작업 실행을 종료할 수 있습니다.

카나리아에서 동시 출시가 실패할 경우 취해야 할 조치

하위 출시가 실패하면 하위 출시의 상황에 따라 컨트롤러 출시가 다른 상태로 전환될 수 있습니다.

하나 이상의 하위 출시가 실패하지만 하위 출시 중 하나라도 여전히 IN_PROGRESS인 경우, 컨트롤러 출시가 IN_PROGRESS 상태로 유지됩니다.
하나 이상의 하위 출시가 실패하지만 하위 출시 중 하나라도 성공하는 경우, 현재 단계 이후 단계가 더 있으면 컨트롤러 출시는 HALTED됩니다.

이 단계가 stable 단계인 경우 컨트롤러 출시는 FAILED입니다.

HALTED를 사용하면 실패한 하위 출시 내에서 실패한 작업을 무시하거나 재시도할 수 있습니다. 또는 컨트롤러 출시를 취소하고 하위 출시에서 추가 작업을 방지합니다.
하위 출시가 실패하여 컨트롤러 출시가 HALTED 상태가 되고 하위 출시에서 실패한 작업을 무시하면 컨트롤러 출시가 IN_PROGRESS 상태로 되돌아갑니다.

구성된 카나리아 실행

카나리아 배포를 실행하려면 다음 안내를 따르세요.

구성된 배포 파이프라인 및 대상 등록
```
gcloud deploy apply --file=PIPELINE
```
배포 파이프라인에는 선택한 런타임에 자동 또는 커스텀 카나리아 구성이 포함됩니다.

이 명령어는 대상이 동일한 파일에 정의되거나 이미 등록되어 있다고 가정합니다. 그렇지 않으면 대상도 등록해야 합니다.
출시 버전 만들기
```
gcloud deploy releases create RELEASE_NAME \
                              --delivery-pipeline=PIPELINE_NAME \
                              --region=REGION
```
PIPELINE_NAME으로 식별된 배포 파이프라인에는 이 문서에 설명된 자동 또는 커스텀 카나리아 구성이 포함되어 있습니다.
카나리아를 진행합니다.
gcloud CLI
```
gcloud deploy rollouts advance ROLLOUT_NAME \
                            --release=RELEASE_NAME \
                            --delivery-pipeline=PIPELINE_NAME \
                            --region=REGION
```
각 항목의 의미는 다음과 같습니다.

ROLLOUT_NAME은 다음 단계로 진행하려는 현재 출시의 이름입니다.

RELEASE_NAME은 이 출시가 속한 출시 버전의 이름입니다.

PIPELINE_NAME은 이 출시 버전의 배포를 관리하는 데 사용하는 배포 파이프라인의 이름입니다.

REGION은 출시 버전이 생성된 리전의 이름입니다(예: us-central1). 필수 항목입니다.

gcloud deploy rollouts advance 명령어에 대한 자세한 내용은 Google Cloud SDK 참조를 확인하세요.
Google Cloud 콘솔
1. 배포 파이프라인 페이지를 엽니다.
2. 배포 파이프라인 목록에 표시된 파이프라인을 클릭합니다.
  
  배포 파이프라인 세부정보 페이지에는 배포 파이프라인의 진행 상태가 그래픽으로 표시됩니다.
3. 출시 탭의 배포 파이프라인 세부정보에서 출시 이름을 클릭합니다.
  
  해당 출시의 출시 세부정보 페이지가 표시됩니다.
  
  이 예시에서 출시에 canary-50 단계와 stable 단계가 있습니다. 출시에는 더 많은 단계 또는 다른 단계가 있을 수 있습니다.
4. 고급 출시를 클릭합니다.
  
  출시는 다음 단계로 진행됩니다.

건너뛴 단계

카나리아를 배포할 때 애플리케이션이 이 런타임에 아직 배포되지 않았으면 Cloud Deploy가 카나리아 단계를 건너뛰고 안정 단계를 실행합니다. 왜 이렇게 되는지 확인하려면 처음으로 단계 건너뛰기를 참조하세요.

다음 단계

카나리아 배포 빠른 시작 사용해 보기
카나리아의 출시 수명 주기를 관리하는 방법 알아보기
병렬 배포 자세히 알아보기

카나리아 배포 전략 사용

카나리아 배포란 무엇인가요?

지원되는 대상 유형

카나리아 배포 전략을 사용하는 이유는 무엇인가요?

카나리아 유형

카나리아 배포 단계

자동 카나리아 또는 커스텀 자동 카나리아에서 발생하는 일

GKE/GKE Enterprise(네트워크)

오버프로비저닝이 사용 설정된 포드 프로비저닝

오버프로비저닝이 중지된 포드 프로비저닝

GKE/GKE Enterprise(게이트웨이)

Cloud Run

카나리아 배포 구성

필수 권한 필요

skaffold.yaml 준비

매니페스트 또는 서비스 정의 준비

GKE 및 GKE Enterprise

Cloud Run

자동화된 카나리아 구성

GKE 및 GKE Enterprise

Cloud Run

커스텀 카나리아 구성

커스텀 카나리아 구성 요소

커스텀 자동 카나리아 구성

Kubernetes Gateway API 서비스 메시를 사용하여 카나리아 배포 구성

카나리아 배포 전략으로 동시 배포 사용

동시 카나리아와 단일 대상 카나리아의 차이점

카나리아에서 동시 출시가 실패할 경우 취해야 할 조치

구성된 카나리아 실행

gcloud CLI

Google Cloud 콘솔

건너뛴 단계

다음 단계

`skaffold.yaml` 준비