Examkin

Soru

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

An enterprise SaaS platform hosts an AI-powered data processing service on Google Kubernetes Engine (GKE) backed by Cloud SQL for PostgreSQL. The team needs to execute a zero-downtime release that includes both a non-breaking database schema modification and a new application version deployment using a canary release strategy. What is the correct sequence of operational steps to perform this release safely?

  1. 1Apply additive, backward-compatible database schema changes (Expand phase) to support both the existing and new application versions.
  2. 2Deploy the new application version to a designated canary workload target on GKE alongside the existing deployment.
  3. 3Configure GKE Gateway / Service Mesh traffic splitting to route 5% of production traffic to the canary deployment and monitor telemetry.
  4. 4Promote the new application version to handle 100% of production traffic and decommission the legacy application pods.
  5. 5Execute destructive database schema cleanup changes (Contract phase) to remove deprecated tables or columns.

Cevap

The correct sequence starts with applying backward-compatible additive database changes, followed by deploying the canary application workload to GKE, routing a small fraction of traffic for monitoring, promoting the release to 100% traffic while decommissioning old pods, and finally executing destructive database cleanup changes.
To achieve zero downtime during releases involving database schema changes, the Expand-Contract pattern must be used. First, the database schema is updated additively so both old and new code function correctly. Next, the canary release is deployed to GKE and assigned a small fraction of traffic via GKE Gateway / Service Mesh traffic splitting. Once validated, the new version is fully promoted to serve 100% of production traffic and old pods are retired. Only after all old code is completely decommissioned can destructive contract schema changes be safely applied.

Adım Adım Çözüm

1
Perform the Expand database migration.
Database contains new structural fields without breaking the active legacy application.
Applying destructive or breaking schema changes first would instantly crash running application pods that rely on the old schema.
2
Deploy the new container image version to GKE.
Canary deployment pods are running and ready to receive traffic.
The workload must exist in a ready state before routing live traffic to it.
3
Configure canary traffic splitting.
A small portion of live user requests (e.g., 5%) are served by the canary deployment.
Allows real-world validation against SLOs and error budgets while limiting potential impact.
4
Complete full rollout and decommission old pods.
100% of traffic hits the new version and zero pods run the old code version.
Ensures no active workloads rely on old schema structures before proceeding to cleanup.
5
Perform the Contract database migration.
Deprecated database fields are removed.
Unused columns and tables can now be safely removed without risking runtime errors.

Anahtar Kavram

Expand-Contract Database Schema Migration paired with Canary Deployment
Tahmini Süre:1m 30s
Bu soruyu puanla

Konular

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