Examkin

Question

Difficulty: HardRelease Management and Deployment Strategies (Blue-Green, Canary, Rolling)

An e-commerce organization is releasing a major upgrade to its core inventory microservice running on Google Kubernetes Engine (GKE) backed by a Cloud SQL for PostgreSQL database. The release requires a breaking database schema modification alongside application code changes. The architectural goal is to execute a zero-downtime canary deployment using Cloud Service Mesh for traffic management without breaching the service's Error Budget. In what sequence should the cloud team perform these release steps?

  1. 1Apply a non-destructive database schema expansion (add new columns as optional/nullable) to Cloud SQL.
  2. 2Deploy the version 2 inventory microservice pods to the GKE cluster without routing public ingress traffic to them.
  3. 3Update Cloud Service Mesh routing policy to shift user traffic incrementally from version 1 to version 2 while monitoring SLIs.
  4. 4Decommission version 1 GKE workloads and execute a database schema contract migration to drop deprecated legacy columns.

Answer

The correct execution sequence begins with executing a non-destructive database schema expansion on Cloud SQL. Next, deploy the version 2 inventory microservice to GKE with zero incoming traffic. After staging, update Cloud Service Mesh routing policies to incrementally shift production traffic to version 2 while monitoring Service Level Indicators. Finally, once version 2 is handling 100% of traffic, decommission version 1 GKE pods and apply the database contract migration to remove legacy columns.
Executing a zero-downtime release with breaking database schema changes requires adhering to the Expand-Contract database pattern paired with canary deployment. Expanding the database schema first maintains full backward compatibility for version 1 workloads. Deploying version 2 to GKE allows readiness verification before handling live requests. Incrementally shifting traffic via Cloud Service Mesh ensures continuous observability against SLIs and error budgets. Finally, contracting the database schema and removing version 1 workloads occurs only after version 2 successfully handles 100% of production traffic.

Step-by-Step Solution

1
Execute the database expansion phase by creating new database columns as nullable or assigning default values.
The Cloud SQL database becomes fully compatible with both the legacy (v1) and newly developed (v2) microservice versions.
Prevents SQL runtime exceptions for active v1 pods while preparing the schema for v2 queries.
2
Provision version 2 Deployment resources in the target GKE cluster.
Version 2 pods achieve Ready status and pass health checks, but Cloud Service Mesh keeps their traffic weight at 0%.
Validates application startup and dependency connections safely before exposing the code to live end users.
3
Modify Cloud Service Mesh HTTPRoute weights to gradually adjust traffic percentage from v1 to v2.
Production traffic shifts gradually while operations teams monitor latency, HTTP error rates, and SLO budgets.
Enables early detection of regression bugs in production with instantaneous rollback capability if metrics degrade.
4
Terminate version 1 Deployment workloads in GKE and run DDL scripts to drop obsolete legacy columns from Cloud SQL.
Legacy compute resources are freed and database schema technical debt is cleared.
Contracting schema elements can only happen when no active workload in the architecture depends on legacy column definitions.

Key Concept

Expand-Contract Pattern with Canary Traffic Shifting
Rate this question

Topics

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