An operations team is establishing an automated canary deployment process for a critical stateless application running on Google Kubernetes Engine (GKE) behind an External HTTP(S) Load Balancer. The deployment pipeline must minimize user risk by using progressive traffic routing and metrics validation. Arrange the steps in the correct chronological order to complete a safe canary release.
- 1Deploy the candidate release version alongside the existing stable release workload in the cluster.
- 2Configure traffic splitting on the backend service to route a small percentage (e.g., 5%) of live requests to the candidate deployment.
- 3Monitor Cloud Monitoring metrics against defined Service Level Indicators (SLIs) over a specified observation window.
- 4Progressively increase the traffic percentage allocated to the candidate release until it serves 100% of production traffic.
- 5Decommission the old stable workload resources and set the candidate version as the new baseline.
Cevap
The correct sequence for a progressive canary release is: 1) Deploy the candidate release version alongside the existing stable workload, 2) Configure traffic splitting on the backend service to route 5% of traffic to the candidate version, 3) Monitor Cloud Monitoring metrics against SLIs over an observation window, 4) Progressively increase traffic to 100%, and 5) Decommission the old stable workload resources.
A progressive canary release follows a strict sequence: first, the candidate version must be deployed in parallel without receiving traffic. Second, traffic splitting is introduced at a small ratio to limit the blast radius. Third, Cloud Monitoring metrics are evaluated over an observation window to ensure SLIs match SLO requirements. Fourth, traffic is incrementally shifted to 100% upon successful evaluation. Finally, legacy workloads are decommissioned.
Adım Adım Çözüm
Anahtar Kavram
Progressive Canary Release and Traffic Splitting Management