Examkin

Soru

Zorluk: ZorRelease Management and Deployment Strategies (Blue-Green, Canary, Rolling)

Your Cloud Operations team is designing an automated deployment pipeline for a high-availability microservice hosted on Google Kubernetes Engine (GKE) using GKE Enterprise Service Mesh and Cloud SQL. The application update introduces a database schema change. To ensure zero-downtime and preserve the service error budget, you must execute a canary release pattern using the expand-contract strategy.

Arrange the following steps in the correct chronological sequence to execute this release strategy safely.

  1. 1Apply backwards-compatible database schema expansion to Cloud SQL, adding new fields while retaining old fields.
  2. 2Deploy the candidate (v2) workload pods to the GKE cluster alongside existing (v1) pods without updating external traffic routes.
  3. 3Configure the Service Mesh VirtualService manifest to route a 5% canary traffic share to the candidate (v2) pod subset.
  4. 4Monitor Cloud Observability metrics, tracking error budgets and latency Service Level Indicators (SLIs) during the soak duration.
  5. 5Shift 100% of production traffic to version v2, decommission v1 pods, and execute the database contract phase to remove deprecated schema fields.

Cevap

The correct sequence starts with applying backwards-compatible database schema expansion to Cloud SQL, deploying candidate (v2) pods to GKE without external traffic, configuring the Service Mesh VirtualService for a 5% canary split, monitoring SLIs and error budgets during soak, and finally promoting v2 to 100% traffic while executing the database contract phase.
Safely deploying application updates with database changes requires decoupling schema expansion from schema contraction. Expanding the schema first ensures backwards compatibility for legacy v1 instances. Once v2 workload pods are provisioned on GKE, canary traffic splitting via Service Mesh allows real-time telemetry observation. After verifying SLI health, shifting 100% of traffic and executing the contract phase completes the zero-downtime release.

Adım Adım Çözüm

1
Database Schema Expansion
Cloud SQL accepts queries from both v1 and v2 software versions without failure.
Applying non-breaking database schema changes (expand phase) ensures running v1 application instances continue operating without downtime when v2 is deployed.
2
Deploy Candidate Workload
v2 pods pass health checks on GKE while v1 continues handling 100% of live traffic.
Candidate containers must be provisioned and healthy before receiving live user requests.
3
Configure Service Mesh Canary Traffic Split
5% of inbound requests route to v2 pods and 95% continue to v1 pods.
Declarative traffic splitting via Service Mesh enables fine-grained exposure to test v2 under real user conditions.
4
SLI and Error Budget Soak Monitoring
Performance and reliability metrics confirm no regressions on the canary deployment.
Automated telemetry analysis ensures issue detection before exposing the full user base.
5
Full Promotion and Schema Contracting
100% of traffic routes to v2, v1 is retired, and legacy database structures are safely removed.
The contract phase finishes the release lifecycle after v1 is fully drained and retired.

Anahtar Kavram

Expand-Contract Database Migration in Canary Deployments
Bu soruyu puanla

Konular

Release Management and Deployment Strategies (Blue-Green, Canary, Rolling)