카나리아 배포를 사용하면 애플리케이션을 부분적으로 출시할 수 있습니다. 이렇게 하면 모든 사용자에게 새 버전의 애플리케이션을 제공하기 전에 안정성을 확인할 수 있습니다.
예를 들어 GKE 또는 GKE Enterprise에 배포하는 경우 제한된 수의 포드에 애플리케이션의 새 버전을 배포할 수 있습니다. 이전 버전은 계속 실행되지만 더 많은 트래픽이 새 포드로 전송됩니다.
Cloud Run에 배포하는 경우 Cloud Run은 구성한 백분율에 따라 자체적으로 이전 버전과 새 버전 간에 트래픽을 분할합니다.
카나리아 유형
Cloud Deploy를 사용하면 다음 유형의 카나리아 배포를 구성할 수 있습니다.
자동
자동 카나리아 배포 (서비스 네트워킹, 게이트웨이 API 또는 Cloud Run의 경우)의 경우 점진적 배포를 표현하는 일련의 백분율로 Cloud Deploy를 구성합니다. Cloud Deploy는 추가 작업을 자동으로 수행해서 이전 및 신규 버전 사이에 트래픽 백분율을 할당합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-03(UTC)"],[[["\u003cp\u003eCanary deployment is a strategy where a new application version is progressively rolled out, splitting traffic between the old and new versions to ensure reliability.\u003c/p\u003e\n"],["\u003cp\u003eCloud Deploy supports automated, custom-automated, and custom canary deployments across target types like Google Kubernetes Engine, Cloud Run, and GKE Enterprise, including multi-targets.\u003c/p\u003e\n"],["\u003cp\u003eDuring a canary deployment, Cloud Deploy creates a series of phases, each with increasing traffic percentages directed to the new version, culminating in a 'stable' phase where all traffic is routed to the new version.\u003c/p\u003e\n"],["\u003cp\u003eFor GKE/Enterprise, Cloud Deploy manages the creation of new Deployment resources and adjusts Service selectors to direct traffic between the original and canary deployments, with options for pod overprovisioning and Gateway API traffic management.\u003c/p\u003e\n"],["\u003cp\u003eUsers can configure canary deployments by specifying percentage increments, verify jobs, predeploy/postdeploy actions, and Skaffold profiles for each phase, with options to use either fully automated or customized settings.\u003c/p\u003e\n"]]],[],null,["# Use a canary deployment strategy\n\nThis document describes how to configure and use a canary deployment strategy.\n\nWhat is a canary deployment?\n----------------------------\n\nA canary deployment is a progressive rollout of an application that splits\ntraffic between an already-deployed version and a new version, rolling it out\nto a subset of users before rolling out fully.\n\n### Supported target types\n\nCanary deployment in Cloud Deploy supports all target types,\nincluding the following:\n\n- Google Kubernetes Engine and GKE Enterprise\n\n - [Using service networking](/deploy/docs/deployment-strategies/canary/gke/service-networking)\n - [Using Gateway API](/deploy/docs/deployment-strategies/canary/gke/gateway-api)\n- [Cloud Run](/deploy/docs/deployment-strategies/canary/cloud-run) (services only---not\n jobs)\n\nCanary also works with\n[multi-targets](/deploy/docs/terminology#multi-target).\n\n### Why use a canary deployment strategy?\n\nA canary deployment gives you a chance to partially release your application. In\nthis way, you can ensure the new version of your application is reliable before\nyou deliver it to all users.\n\nIf you're deploying to GKE or GKE Enterprise, for\nexample, you would deploy the new version of your application to a limited\nnumber of pods. The old version would continue to run, but with more of the\ntraffic being sent to the new pods.\n\nIf you're deploying to Cloud Run, Cloud Run\nitself splits traffic between the old and new revisions, according to the\npercentages you configure.\n\n### Types of canary\n\nCloud Deploy lets you configure the following types of canary\ndeployment:\n\n- Automated\n\n With an automated canary deployment (for [service networking](/deploy/docs/deployment-strategies/canary/gke/service-networking#configure_an_automated_canary), [gateway api](/deploy/docs/deployment-strategies/canary/gke/gateway-api#configure_an_automated_canary) or [Cloud Run](/deploy/docs/deployment-strategies/canary/cloud-run-canary#configure_an_automated_canary)), you configure Cloud Deploy with a series of\n percentages that express a progressive deployment. Cloud Deploy\n performs additional operations on your behalf, to apportion traffic\n percentages between the old and new versions.\n- Custom-automated\n\n For a custom-automated canary (for [service networking](/deploy/docs/deployment-strategies/canary/gke/service-networking#custom-automated), [gateway api](/deploy/docs/deployment-strategies/canary/gke/gateway-api#custom-automated) or [Cloud Run](/deploy/docs/deployment-strategies/canary/cloud-run-canary#custom-automated)), you can provide the\n following:\n - The phase name\n - The percentage goal\n - The Skaffold profile to use for the phase\n - Whether or not to include a verify job\n - Whether or not to include a predeploy or postdeploy job, or both\n\n But you don't need to provide traffic-balancing information;\n Cloud Deploy\n creates the necessary resources (for [service networking](/deploy/docs/deployment-strategies/canary/gke/service-networking#what_happens_during_an_automated_or_custom-automated_canary), [gateway api](/deploy/docs/deployment-strategies/canary/gke/gateway-api#what_happens_during_an_automated_or_custom-automated_canary) or [Cloud Run](/deploy/docs/deployment-strategies/canary/cloud-run-canary#what_happens_during_an_automated_or_custom-automated_canary)).\n- Custom\n\n With a [custom canary](/deploy/docs/deployment-strategies/canary/custom), you\n configure each canary phase separately, including the following:\n - The phase name\n - The percentage goal\n - The Skaffold profile to use for the phase\n - Whether or not to include a verify job\n - Whether or not to include a predeploy or postdeploy job, or both\n\n Additionally for a fully custom canary, you provide all of the\n traffic-balancing configuration.\n\n [All target types](/deploy/docs/deploying-application#set_up_for_the_runtime_environment_of_your_choice)\n are supported for custom canary.\n\n### Phases of a canary deployment\n\nWhen you create a release for a canary deployment, the rollout is created with\na phase for each canary increment, plus a final `stable` phase for 100%.\n\nFor example, if you configure a canary for 25%, 50%, and 75% increments, the\nrollout will have the following phases:\n\n- `canary-25`\n- `canary-50`\n- `canary-75`\n- `stable`\n\n| **Note:** For a [GKE, Gateway API configuration](/deploy/docs/deployment-strategies/canary/gke/gateway-api), 100% is allowed. This supports a 100% deployment from canary before switching over to `stable`. The 100% configuration is not allowed for GKE service-based canary, GKE Enterprise, or Cloud Run.\n\nYou can read more about rollout phases, jobs, and job runs in\n[Manage rollouts](/deploy/docs/deployment-strategies/manage-rollout).\n\nUse parallel deployment with a canary deployment strategy\n---------------------------------------------------------\n\nYou can run a canary deployment using [parallel deployment](/deploy/docs/parallel).\nThis means the target you're progressively deploying to can comprise two or more\nchild targets. For example, you can deploy progressively to clusters in separate\nregions, at the same time.\n\n### How is a parallel canary different from single-target canaries\n\n- As with single-target canary deployment, if you're deploying to\n GKE targets, you need a Kubernetes Deployment configuration and\n a Kubernetes Service configuration in your manifest.\n\n- As with single-target canary deployment, your delivery pipeline configuration\n must include a `strategy.canary` stanza inside the stage definition for the\n applicable stage.\n\n- Additionally, you need to\n [configure a multi-target](/deploy/docs/parallel#configure_the_multi-target),\n and you need to\n [configure the child targets](/deploy/docs/parallel#configure_the_child_targets)\n which that multi-target references.\n\n- When you create a release, a [controller rollout](/deploy/docs/terminology#controller_rollout)\n and the [child rollouts](/deploy/docs/terminology#child_rollout) are created.\n\n Both types of rollout---controller and child---have separate phases\n for all of the configured canary percentages, and a `stable` phase for the\n canary 100%.\n- You can't [advance](/deploy/docs/deployment-strategies/manage-rollout#advance_rollout)\n a child rollout.\n\n You can advance controller rollouts only. When you advance the controller\n rollout to the next stage, the child rollouts are advanced too, by\n Cloud Deploy.\n- You can't [retry](/deploy/docs/deployment-strategies/manage-rollout#retry_failed_job)\n failed jobs in the controller rollout.\n\n You can retry a job in child rollouts only.\n- You can't [ignore](/deploy/docs/deployment-strategies/manage-rollout#ignore_job)\n failed jobs in the controller rollout.\n\n You can ignore failed jobs in child rollouts only.\n- You can [cancel a controller rollout](/deploy/docs/deployment-strategies/manage-rollout#cancel_rollout),\n but you can't cancel child rollouts.\n\n- You can\n [terminate job runs](/deploy/docs/deployment-strategies/manage-rollout#terminate_job_run)\n under a child rollout only, not a controller rollout.\n\n### What to do if a parallel rollout fails in canary\n\nWhen a child rollout fails, the controller rollout can transition to different\nstates, depending on what happens with the child rollouts:\n\n- If one or more child rollouts fail, but at least one child rollout is still\n `IN_PROGRESS`, the controller rollout remains `IN_PROGRESS`.\n\n- If one or more child rollouts fail, but at least one child rollout succeeds,\n the controller rollout is `HALTED` if there are more phases after the current\n one.\n\n If this is the `stable` phase, the controller rollout is `FAILED`.\n\n `HALTED` gives you a chance to either\n [ignore](/deploy/docs/deployment-strategies/manage-rollout#ignore_job),\n [retry](/deploy/docs/deployment-strategies/manage-rollout#retry_failed_job)\n failed jobs within the failed child rollout, or\n [cancel the controller rollout](/deploy/docs/deployment-strategies/manage-rollout#cancel_rollout)\n and prevent further actions on the child rollouts.\n- If the controller rollout is in a `HALTED` state because of a failed child\n rollout, and you ignore the failed job in the child rollout, the controller\n rollout reverts to an `IN_PROGRESS` state.\n\nWhat's next\n-----------\n\n- Try the [canary deployment quickstart](/deploy/docs/deploy-app-canary).\n\n- Find out how to [manage the lifecycle of your canary's rollouts](/deploy/docs/deployment-strategies/manage-rollout).\n\n- Proceed to the guide relevant to your specific target environment:\n\n - [Canary Deployments to Cloud Run](/deploy/docs/deployment-strategies/canary/cloud-run-canary)\n - [Canary Deployments to GKE/GKE Enterprise using Service Networking](/deploy/docs/deployment-strategies/canary/gke/service-networking)\n - [Canary Deployments to GKE/GKE Enterprise using Gateway API](/deploy/docs/deployment-strategies/canary/gke/gateway-api)"]]
