A team is implementing a canary deployment for a microservice on GKE using traffic splitting. They want to gradually shift 1% of traffic to a new version, monitor for errors, and then increase the percentage. Which tool or configuration should they use?
Trap 1: Configure a GKE Ingress with weighted backend services
GKE Ingress with weighted backends is possible but does not provide the built-in canary pipeline and monitoring integration that Cloud Deploy offers.
Trap 2: Deploy the new version to a separate namespace and use DNS weighting
DNS weighting is not accurate for traffic splitting and does not provide the control and observability needed for canary deployments.
Trap 3: Use Kubernetes Deployment with rolling update strategy
Rolling update gradually replaces pods but does not support precise traffic splitting percentages (e.g., 1%).
- A
Configure a GKE Ingress with weighted backend services
Why it fails: GKE Ingress with weighted backends is possible but does not provide the built-in canary pipeline and monitoring integration that Cloud Deploy offers.
- B
Deploy the new version to a separate namespace and use DNS weighting
Why it fails: DNS weighting is not accurate for traffic splitting and does not provide the control and observability needed for canary deployments.
- C
Use Cloud Deploy with a canary deployment strategy and Istio traffic splitting
Cloud Deploy's canary strategy orchestrates the progressive rollout, while Istio traffic splitting provides the fine-grained percentage control needed to shift exactly 1% of requests, monitor errors, and incrementally increase. This combination satisfies the gradual, measurable traffic-shifting requirement on GKE.
- D
Use Kubernetes Deployment with rolling update strategy
Why it fails: Rolling update gradually replaces pods but does not support precise traffic splitting percentages (e.g., 1%).