An enterprise runs a high-throughput microservices application on Google Kubernetes Engine (GKE) serving both gRPC and HTTP/2 traffic. The DevOps engineering team is implementing a progressive deployment pipeline to release new microservice versions safely. The deployment strategy must satisfy the following technical requirements: Route a controlled 5% canary slice of live production traffic to the new version, with the ability to dynamically adjust percentage weights without altering replica counts. Route internal quality assurance and beta testers directly to the canary version based on specific HTTP/gRPC request header values. Automatically identify and temporarily eject individual backend Pod instances that fail request thresholds during the canary phase to minimize user blast radius. Which architecture and traffic management strategy should the team implement?

Enable Cloud Service Mesh on the GKE cluster with automatic Envoy proxy sidecar injection, configure mesh route rules for percentage-based traffic splitting and header matching, and enable outlier detection on the destination service.: ### What Cloud Service Mesh Is **Cloud Service Mesh** (which consolidates **Anthos Service Mesh** and **Traffic Director**) provides fully managed, application-aware service networking for microservices architectures across Google Cloud. It utilizes Envoy proxy sidecars injected directly into **Google Kubernetes Engine (GKE)** workloads to manage Layer 7 ingress and east-west mesh communication. ### How It Meets the Requirements - **Weight-Based Traffic Shifting**: Cloud Service Mesh decouples traffic routing from infrastructure scaling. By configuring route rules (such as Istio `VirtualService` or Gateway API routes), traffic can be split precisely by weight (e.g., 95% baseline, 5% canary) regardless of the number of running Pod replicas in each deployment. - **Header-Based Routing**: Layer 7 traffic routing allows granular matching on HTTP/gRPC request headers, cookies, and query parameters. Requests bearing designated internal tester headers are deterministically routed to the canary subset. - **Blast Radius Mitigation via Outlier Detection**: Cloud Service Mesh supports **outlier detection**, which continuously evaluates backend instance success rates and response codes, automatically ejecting unhealthy or failing Pods from the load-balancing pool for a configurable base ejection time. ### Key Advantages - **Dynamic Weight Adjustments**: Traffic ratios can be shifted seamlessly via control plane updates without restarting Pods or resizing deployments. - **Advanced Layer 7 Telemetry**: Provides out-of-the-box telemetry, distributed tracing, and golden metrics (latency, traffic, errors, saturation) to evaluate canary success metrics. - **Granular Resilience**: Combines circuit breaking, active outlier detection, and connection pooling to prevent cascading failures. - **Protocol Support**: Native support for **gRPC**, HTTP/1.1, and HTTP/2 traffic routing policies. ### Why This Is Optimal Cloud Service Mesh provides native Layer 7 control plane capabilities, enabling dynamic percentage weighting, advanced header-based steering, and automated host ejection via outlier detection within a single cohesive framework.

Gke Canary Deployment Cloud Service Mesh Traffic Splitting | Professional Cloud DevOps Engineer

Gke Canary Deployment Cloud Service Mesh Traffic Splitting

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise runs a high-throughput microservices application on Google Kubernetes Engine (GKE) serving both gRPC and HTTP/2 traffic. The DevOps engineering team is implementing a progressive deployment pipeline to release new microservice versions safely.

The deployment strategy must satisfy the following technical requirements:

Route a controlled 5% canary slice of live production traffic to the new version, with the ability to dynamically adjust percentage weights without altering replica counts.
Route internal quality assurance and beta testers directly to the canary version based on specific HTTP/gRPC request header values.
Automatically identify and temporarily eject individual backend Pod instances that fail request thresholds during the canary phase to minimize user blast radius.

Which architecture and traffic management strategy should the team implement?

Use native Kubernetes Service objects pointing to shared Pod labels across Deployments, scale the canary Pod replica count to represent 5% of total Pods, and configure standard Kubernetes readiness probes for health checking.

Enable Cloud Service Mesh on the GKE cluster with automatic Envoy proxy sidecar injection, configure mesh route rules for percentage-based traffic splitting and header matching, and enable outlier detection on the destination service.

Deploy an External Passthrough Network Load Balancer with weighted backend instance groups, configure 5-tuple hash session affinity, and route tester traffic based on client IP addresses.

Migrate the microservice workloads to separate Cloud Run revisions, utilize Cloud Run URL tags for tester access, and configure Cloud Tasks queues to throttle and split requests.

Professional Cloud DevOps Engineer

Gke Canary Deployment Cloud Service Mesh Traffic Splitting

Related questions