Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Neste documento, descrevemos como configurar e usar uma estratégia de implantação canário.
O que é uma implantação canário?
Uma implantação canário é um lançamento progressivo de um aplicativo que divide
o tráfego entre uma versão já implantada e uma nova, lançando-a
para um subconjunto de usuários antes do lançamento completo.
Tipos de segmentação compatíveis
A implantação canário no Cloud Deploy é compatível com todos os tipos de destino, incluindo:
Por que usar uma estratégia de implantação canário?
Uma implantação canário oferece a chance de lançar parcialmente seu aplicativo. Assim, você garante que a nova versão do aplicativo é confiável antes de entregá-la a todos os usuários.
Se você estiver implantando no GKE ou no GKE Enterprise, por exemplo, implante a nova versão do aplicativo em um número limitado de pods. A versão antiga continuaria sendo executada, mas com mais tráfego sendo enviado para os novos pods.
Se você estiver implantando no Cloud Run, o próprio Cloud Run
dividirá o tráfego entre as revisões antigas e novas, de acordo com as
porcentagens configuradas.
Tipos de canário
Com o Cloud Deploy, é possível configurar os seguintes tipos de implantação
canary:
Automatizado
Com uma implantação canário automatizada (para redes de serviços, API Gateway ou Cloud Run), você configura o Cloud Deploy com uma série de porcentagens que expressam uma implantação progressiva. O Cloud Deploy
realiza outras operações em seu nome para dividir as porcentagens de tráfego
entre as versões antiga e nova.
Se você quer incluir um job de pré-implantação, pós-implantação ou ambos
Mas não é necessário fornecer informações de balanceamento de tráfego. O Cloud Deploy cria os recursos necessários (para rede de serviços, API de gateway ou Cloud Run).
Personalizado
Com um canary personalizado, você configura cada fase separadamente, incluindo o seguinte:
O nome da fase
A meta de porcentagem
O perfil do Skaffold a ser usado na fase.
Se um job de verificação deve ser incluído ou não
Se você quer incluir um job de pré-implantação, pós-implantação ou ambos
Além disso, para um canário totalmente personalizado, você fornece toda a configuração de balanceamento de tráfego.
Ao criar uma versão para uma implantação canário, o lançamento é criado com
uma fase para cada incremento canário, além de uma fase final de stable para 100%.
Por exemplo, se você configurar um canary para incrementos de 25%, 50% e 75%, o
lançamento terá as seguintes fases:
canary-25
canary-50
canary-75
stable
Leia mais sobre fases, jobs e execuções de jobs de lançamento em
Gerenciar lançamentos.
Usar a implantação paralela com uma estratégia de implantação canário
É possível executar uma implantação canário usando a implantação paralela.
Isso significa que o destino em que você está fazendo a implantação progressiva pode ter dois ou mais destinos filhos. Por exemplo, é possível fazer implantações progressivas em clusters de regiões separadas ao mesmo tempo.
Qual é a diferença entre um canary paralelo e um canary de destino único?
Assim como na implantação canário de destino único, se você estiver implantando em
destinos do GKE, precisará de uma configuração de implantação do Kubernetes e
uma configuração de serviço do Kubernetes no manifesto.
Assim como na implantação canário de destino único, a configuração do pipeline de entrega
precisa incluir uma estrofe strategy.canary na definição do estágio
aplicável.
Os dois tipos de lançamento (controlador e filho) têm fases separadas
para todas as porcentagens canário configuradas e uma fase stable para o
canário 100%.
Só é possível avançar lançamentos do controlador. Quando você avança o lançamento do controlador para a próxima etapa, os lançamentos filhos também são avançados pelo Cloud Deploy.
Não é possível repetir
jobs com falha no lançamento do controlador.
Só é possível tentar de novo um job em lançamentos filhos.
Não é possível ignorar
jobs com falha no lançamento do controlador.
Só é possível ignorar jobs com falha em lançamentos filhos.
O que fazer se um lançamento paralelo falhar no canário
Quando um lançamento filho falha, o lançamento do controlador pode fazer a transição para diferentes estados, dependendo do que acontece com os lançamentos filhos:
Se um ou mais lançamentos filhos falharem, mas pelo menos um ainda estiver
IN_PROGRESS, o lançamento do controlador vai continuar IN_PROGRESS.
Se um ou mais lançamentos filhos falharem, mas pelo menos um for bem-sucedido, o lançamento do controlador será HALTED se houver mais fases após a atual.
Se esta for a fase stable, o lançamento do controlador será FAILED.
Se o lançamento do controlador estiver no estado HALTED devido a uma falha no lançamento filho, e você ignorar o job com falha no lançamento filho, o lançamento do controlador vai reverter para o estado IN_PROGRESS.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)"]]