sigs.k8s.io/gateway-api@v1.0.0/site-src/guides/traffic-splitting.md (about) 1 # HTTP traffic splitting 2 3 The [HTTPRoute resource](/api-types/httproute) allows you to specify 4 weights to shift traffic between different backends. This is useful for 5 splitting traffic during rollouts, canarying changes, or for emergencies. 6 The HTTPRoute`spec.rules.backendRefs` accepts a list of backends that a route 7 rule will send traffic to. The relative weights of these backends define 8 the split of traffic between them. The following YAML snippet shows how two 9 Services are listed as backends for a single route rule. This route rule 10 will split traffic 90% to `foo-v1` and 10% to `foo-v2`. 11 12  13 14 ```yaml 15 {% include 'standard/traffic-splitting/simple-split.yaml' %} 16 ``` 17 18 `weight` indicates a proportional split of traffic (rather than percentage) 19 and so the sum of all the weights within a single route rule is the 20 denominator for all of the backends. `weight` is an optional parameter and if 21 not specified, defaults to 1. If only a single backend is specified for a 22 route rule it implicitly receives 100% of the traffic, no matter what (if any) 23 weight is specified. 24 25 ## Guide 26 27 This guide shows the deployment of two versions of a Service. Traffic splitting 28 is used to manage the gradual splitting of traffic from v1 to v2. 29 30 This example assumes that the following Gateway is deployed: 31 32 ```yaml 33 {% include 'standard/simple-gateway/gateway.yaml' %} 34 ``` 35 36 ## Canary traffic rollout 37 38 At first, there may only be a single version of a Service that serves 39 production user traffic for `foo.example.com`. The following HTTPRoute has no 40 `weight` specified for `foo-v1` or `foo-v2` so they will implicitly 41 receive 100% of the traffic matched by each of their route rules. A canary 42 route rule is used (matching the header `traffic=test`) to send synthetic test 43 traffic before splitting any production user traffic to `foo-v2`. 44 [Routing precedence](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteRule) 45 ensures that all traffic with the matching host and header 46 (the most specific match) will be sent to `foo-v2`. 47 48  49 50 51 ```yaml 52 {% include 'standard/traffic-splitting/traffic-split-1.yaml' %} 53 ``` 54 55 ## Blue-green traffic rollout 56 57 After internal testing has validated successful responses from `foo-v2`, 58 it's desirable to shift a small percentage of the traffic to the new Service 59 for gradual and more realistic testing. The HTTPRoute below adds `foo-v2` 60 as a backend along with weights. The weights add up to a total of 100 so 61 `foo-v1` receives 90/100=90% of the traffic and `foo-v2` receives 62 10/100=10% of the traffic. 63 64  65 66 67 ```yaml 68 {% include 'standard/traffic-splitting/traffic-split-2.yaml' %} 69 ``` 70 71 ## Completing the rollout 72 73 Finally, if all signals are positive, it is time to fully shift traffic to 74 `foo-v2` and complete the rollout. The weight for `foo-v1` is set to 75 `0` so that it is configured to accept zero traffic. 76 77  78 79 80 ```yaml 81 {% include 'standard/traffic-splitting/traffic-split-3.yaml' %} 82 ``` 83 84 At this point 100% of the traffic is being routed to `foo-v2` and the 85 rollout is complete. If for any reason `foo-v2` experiences errors, the 86 weights can be updated to quickly shift traffic back to `foo-v1`. Once 87 the rollout is deemed final, v1 can be fully decommissioned.