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.

StudyCerts

Professional Cloud DevOps Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Gke Canary Deployment Cloud Service Mesh Traffic Splitting

Section: Deployment strategies (e.g., canary, blue/green, rolling, traffic splitting, feature flags) and defining success metrics based on application or ML pipeline telemetry

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?

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.

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.

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.

Professional Cloud DevOps Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Gke Canary Deployment Cloud Service Mesh Traffic Splitting

Section: Deployment strategies (e.g., canary, blue/green, rolling, traffic splitting, feature flags) and defining success metrics based on application or ML pipeline telemetry

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?

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.

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.

Explanations

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.

View source documentation

Professional Cloud DevOps Engineer

Gke Canary Deployment Cloud Service Mesh Traffic Splitting

Professional Cloud DevOps Engineer

Gke Canary Deployment Cloud Service Mesh Traffic Splitting

What Cloud Service Mesh Is

How It Meets the Requirements

Key Advantages

Why This Is Optimal

Related questions