Google Cloud has released canary and parallel deployment support for Google Cloud Deploy. Both features work for Google Kubernetes Engine, Cloud Run, and Anthos. The features can be combined together for more advanced rollout strategies.
Canary deployments allow for splitting traffic between the old release and the new release to facilitate validation that the new code is functioning as expected. Traffic is typically split such that the new release receives a small fraction of the overall traffic. As validation and testing prove that the new code release is stable, more traffic can be cut over to the new release. Within Google Cloud Deploy, advancing the percentage of traffic directed to the new release is done either via the console or calling gcloud deploy beta rollouts advance.
A canary release can be defined within the YAML configuration file:
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
name: my-canary-demo-app-1
description: main application pipeline
serialPipeline:
stages:
- targetId: prod
profiles: []
strategy:
canary:
runtimeConfig:
kubernetes:
serviceNetworking:
service: "my-service"
deployment: "my-deployment"
canaryDeployment:
percentages: [50]
verify: false
Once the rollout is created via gcloud deploy, it can be tracked within the console:
For troubleshooting purposes, both phase and job status and rollout logs are available. Jobs that are failing can be retried, terminated, or ignored as required. In addition, the entire canary deployment can either be canceled or rolled back.
Parallel deployments can deploy multiple targets in lockstep; if one deployment fails, the entire rollout fails. This treats the various deploys as one deployment where all targets must pass to move onto the stage. When used with a multi-target, a controller rollout will orchestrate multiple child rollouts. Each child rollout performs its own deployment and operates within its own execution environment.
A multi-target can be created within the YAML configuration file:
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
name: my-parallel-demo-app-1
description: main application pipeline
serialPipeline:
stages:
- targetId: qsprod-multi
profiles: []
---
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name: qsprod-multi
description: production clusters
multiTarget:
targetIds: [qsprod-a, qsprod-b]
---
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name: qsprod-a
description: production cluster 1
gke:
cluster: projects/PROJECT_ID/locations/us-central1/clusters/quickstart-cluster-qsprod1
---
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name: qsprod-b
description: production cluster 2
gke:
cluster: projects/PROJECT_ID/locations/us-west1/clusters/quickstart-cluster-qsprod2
This sets up three targets where qsprod-a and qsprod-b are child targets of qsprod-multi. For qsprod-multi to be considered successful, both qsprod-a and qsprod-b must complete successfully.
Canary deployments can be combined with parallel deployments. When combined, it isn't possible to advance a child rollout directly, instead, only the controller rollout can be advanced. This then advances all child rollouts automatically. This prevents child rollouts from advancing ahead of other children in the deployment.
Only child rollouts can be retried or ignored within a combined deployment. However, canceling a rollout can only be done at the controller level. If a child rollout fails, but some children are still marked as IN PROGRESS, the entire rollout will remain in the IN PROGRESS state.
Canary deployments can be set up within AWS using API Gateway. Canary settings can be set on a deployment stage and a percentage of traffic can be directed to the new code. Within Azure, canary deployments can be done using the Kubernetes manifest task's canary strategy.
More details about the release can be found on the Google Cloud blog or within the tutorials and documentation. Questions and feedback can be brought to the Google Cloud community forums.