Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Dokumen ini menjelaskan cara mengonfigurasi dan menggunakan strategi deployment canary.
Apa yang dimaksud dengan deployment canary?
Deployment canary adalah peluncuran progresif aplikasi yang membagi
traffic antara versi yang sudah di-deploy dan versi baru, meluncurkannya
ke sebagian pengguna sebelum meluncurkan sepenuhnya.
Jenis target yang didukung
Deployment canary di Cloud Deploy mendukung semua jenis target, termasuk yang berikut:
Deployment canary memberi Anda kesempatan untuk merilis aplikasi sebagian. Dengan
cara ini, Anda dapat memastikan versi baru aplikasi Anda andal sebelum
Anda menyajikannya kepada semua pengguna.
Jika Anda men-deploy ke GKE atau GKE Enterprise, misalnya, Anda akan men-deploy versi baru aplikasi ke sejumlah kecil pod. Versi lama akan terus berjalan, tetapi dengan lebih banyak traffic yang dikirim ke pod baru.
Jika Anda men-deploy ke Cloud Run, Cloud Run
sendiri akan membagi traffic antara revisi lama dan baru, sesuai dengan
persentase yang Anda konfigurasi.
Jenis canary
Cloud Deploy memungkinkan Anda mengonfigurasi jenis deployment canary berikut:
Otomatis
Dengan deployment canary otomatis (untuk jaringan layanan, API gateway, atau Cloud Run), Anda mengonfigurasi Cloud Deploy dengan serangkaian
persentase yang menyatakan deployment progresif. Cloud Deploy
melakukan operasi tambahan atas nama Anda, untuk membagi persentase traffic antara versi lama dan baru.
Profil Skaffold yang akan digunakan untuk fase ini
Apakah akan menyertakan tugas verifikasi atau tidak
Apakah akan menyertakan tugas pra-deploy atau pasca-deploy, atau keduanya
Namun, Anda tidak perlu memberikan informasi penyeimbangan traffic;
Cloud Deploy
membuat resource yang diperlukan (untuk jaringan layanan, gateway API, atau Cloud Run).
Kustom
Dengan canary kustom, Anda
mengonfigurasi setiap fase canary secara terpisah, termasuk hal berikut:
Nama fase
Sasaran persentase
Profil Skaffold yang akan digunakan untuk fase ini
Apakah akan menyertakan tugas verifikasi atau tidak
Apakah akan menyertakan tugas pra-deploy atau pasca-deploy, atau keduanya
Selain itu, untuk canary yang sepenuhnya kustom, Anda memberikan semua
konfigurasi penyeimbangan traffic.
Saat Anda membuat rilis untuk deployment canary, peluncuran akan dibuat dengan
tahap untuk setiap penambahan canary, ditambah tahap stable akhir untuk 100%.
Misalnya, jika Anda mengonfigurasi canary untuk inkremen 25%, 50%, dan 75%, peluncuran akan memiliki fase berikut:
canary-25
canary-50
canary-75
stable
Anda dapat membaca lebih lanjut tentang fase peluncuran, tugas, dan eksekusi tugas di
Mengelola peluncuran.
Menggunakan deployment paralel dengan strategi deployment canary
Anda dapat menjalankan deployment canary menggunakan deployment paralel.
Artinya, target yang Anda deploy secara progresif dapat terdiri dari dua atau lebih
target turunan. Misalnya, Anda dapat men-deploy secara progresif ke cluster di region
terpisah, secara bersamaan.
Perbedaan antara canary paralel dan canary target tunggal
Seperti deployment canary target tunggal, jika men-deploy ke target GKE, Anda memerlukan konfigurasi Deployment Kubernetes dan konfigurasi Layanan Kubernetes dalam manifes.
Seperti deployment canary target tunggal, konfigurasi pipeline pengiriman Anda
harus menyertakan stanza strategy.canary di dalam definisi tahap untuk
tahap yang berlaku.
Kedua jenis peluncuran—pengontrol dan turunan—memiliki fase terpisah
untuk semua persentase canary yang dikonfigurasi, dan fase stable untuk
canary 100%.
Anda hanya dapat memajukan peluncuran pengontrol. Saat Anda memajukan peluncuran pengontrol ke tahap berikutnya, peluncuran turunan juga akan dimajukan oleh Cloud Deploy.
Anda tidak dapat mencoba ulang
tugas yang gagal dalam peluncuran pengontrol.
Anda hanya dapat mencoba ulang tugas dalam peluncuran anak.
Anda tidak dapat mengabaikan
tugas yang gagal dalam peluncuran pengontrol.
Anda hanya dapat mengabaikan tugas yang gagal dalam peluncuran turunan.
Yang harus dilakukan jika peluncuran paralel gagal di canary
Jika peluncuran turunan gagal, peluncuran pengontrol dapat bertransisi ke status yang berbeda, bergantung pada apa yang terjadi dengan peluncuran turunan:
Jika satu atau beberapa peluncuran turunan gagal, tetapi setidaknya satu peluncuran turunan masih
IN_PROGRESS, peluncuran pengontrol tetap IN_PROGRESS.
Jika satu atau beberapa peluncuran anak gagal, tetapi setidaknya satu peluncuran anak berhasil,
peluncuran pengontrol adalah HALTED jika ada lebih banyak fase setelah fase
saat ini.
Jika ini adalah fase stable, peluncuran pengontrol adalah FAILED.
Jika peluncuran pengontrol berada dalam status HALTED karena peluncuran turunan gagal, dan Anda mengabaikan tugas yang gagal dalam peluncuran turunan, peluncuran pengontrol akan kembali ke status IN_PROGRESS.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-17 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)"]]