Support Traffic Splitting to Baseline, Stable, and Canary Pods in Experiment Step for GCP Gateway API Plugin

[vthiruveedhi]

Description
Argo Rollouts provides support for the experiment step, including weighted traffic routing, as documented in the Experiment Feature Overview. This feature automatically creates Service objects for experiment templates (e.g., baseline and canary) and dynamically splits traffic according to specified weights. For example, with the AWS ALB traffic router, Argo Rollouts updates Ingress annotations to route traffic across stable, baseline, and canary services during an experiment, reverting traffic post-experiment as needed.

However, the GCP Gateway API plugin (argoproj-labs/gatewayAPI) lacks equivalent support. When using the experiment step with the Gateway API on Google Kubernetes Engine (GKE), the HTTPRoute is not updated to reflect traffic splits to experiment services, preventing the intended behavior.

Example: Working Behavior with AWS ALB
The AWS ALB traffic router demonstrates how this should work. Here’s an example from an Ingress annotation update:

During Experiment

[alb.ingress.kubernetes.io/actions.argo-rollouts-stable-service]: 
'{"Type":"forward","ForwardConfig":{"TargetGroups":[
  {"ServiceName":"argo-rollouts-canary-service","ServicePort":"443","Weight":0},
  {"ServiceName":"test-app-79fbf7c6f7-3-0-experiment-baseline","ServicePort":"443","Weight":5},
  {"ServiceName":"test-app-79fbf7c6f7-3-0-experiment-canary","ServicePort":"443","Weight":25},
  {"ServiceName":"argo-rollouts-stable-service","ServicePort":"443","Weight":70}]}}'

Traffic splits: 70% to stable, 5% to baseline, 25% to canary.
After Experiment (Post-Migration)

[alb.ingress.kubernetes.io/actions.argo-rollouts-stable-service]: 
'{"Type":"forward","ForwardConfig":{"TargetGroups":[
  {"ServiceName":"argo-rollouts-canary-service","ServicePort":"443","Weight":0},
  {"ServiceName":"argo-rollouts-stable-service","ServicePort":"443","Weight":100}]}}'

Traffic reverts: 100% to stable.
This shows Argo Rollouts effectively managing traffic splits for experiment services with the AWS ALB plugin.

Expected Behavior with GCP Gateway API
Based on the experiment documentation and parity with other traffic routers:

1. Service Creation: During the experiment step, Argo Rollouts should auto-generate Service objects for experiment templates, e.g., test-app-experiment-baseline and test-app-experiment-canary.
2. Traffic Splitting: The Gateway API plugin should update the HTTPRoute to split traffic, e.g.:
   70% to argo-rollouts-stable-service (stable pods).
   5% to test-app-experiment-baseline (baseline pods).
   25% to test-app-experiment-canary (canary pods).
3. Post-Experiment: After the experiment duration (e.g., with setWeight: 0), traffic should revert to 100% on argo-rollouts-stable-service.

Actual Behavior

1. What Happens: The experiment pods and associated Service objects (e.g., test-app-experiment-baseline, test-app-experiment-canary) are created as expected. However, the HTTPRoute is not updated to include backendRefs or weights for these experiment services.
2. Observed Issue: Traffic routing does not occur. Plugin logs reveal errors indicating it cannot find or apply the necessary backendRefs for the experiment services, halting traffic splitting.
3. Impact: Users cannot leverage the experiment step to test baseline and canary versions with real traffic on GKE, limiting progressive delivery capabilities.

Request for Assistance
I’d greatly appreciate guidance or contributions from the GCP Arorollouts Rollouts team to implement this feature. I’m happy to assist with testing or providing additional details from my GKE setup. Thank you for considering this enhancement!