Free tools Windows power users keep installed
One-click scans. No signup required.
Istio can route Kubernetes service requests between application versions, either by percentage or by request conditions such as a header. That gives you the traffic-control part of an A/B test—not the experiment itself. Your application or an experiment platform still needs to assign people consistently to groups, record outcomes, and determine whether a change helped.
What Istio handles—and what your experiment still needs
Istio’s traffic-management configuration controls where requests go. A VirtualService defines routing rules for a host, while a DestinationRule can define named subsets of that service, such as workloads selected by version labels. A route can send traffic to one or more subsets, using weights or request-match conditions. See Istio’s traffic-management overview and request-routing task.
That routing alone does not define an experiment. It does not establish who belongs in each group, guarantee that a person sees the same version on later requests, choose a meaningful success measure, or analyze the result. Those responsibilities belong in your application or an experiment platform. If the same user must consistently see one treatment, implement stable assignment upstream and make the resulting selector available to the routing layer; Istio’s header-based routing examples show how to act on a request header, not how to create a complete durable allocation system.
Choose how requests should be assigned
| Routing approach | How it works | Best fit | Important limit |
|---|---|---|---|
| Percentage-weighted routes | Give each destination subset a relative weight. Istio’s documentation illustrates 75 for v1 and 25 for v2; those are example weights, not measured results or a recommended allocation. |
Distributing requests broadly between versions, including staged traffic shifts. | A request split is not, by itself, proof of random, persistent user assignment. |
| Request-conditioned routes | Match a request property, such as a URI or header, and route matching traffic to a chosen destination. | Targeting traffic when the request carries a reliable cohort selector. | You must decide how that selector is assigned and kept stable; the routing rule does not supply that experiment logic. |
Both approaches are supported by Istio’s traffic-management concepts and request-routing examples. Pick the one that matches your assignment design: use weights for a broad distribution, or a request condition when the request contains a dependable selector.
#1 Best Overall
Prepare the cluster and application versions
Check the environment
You need a Kubernetes cluster and an Istio installation. Istio’s getting-started guide walks through cluster preparation, installing Istio, deploying a sample application, accessing it, and opening a dashboard; it names kind or another supported Kubernetes platform as possible environments. Follow the setup instructions appropriate to your cluster and Istio release.
If you use the traffic-shifting task’s Kubernetes Gateway API path, account for its stated prerequisite: Gateway API CRDs do not come installed by default on most clusters. Istio documents both Gateway API and Istio API instructions in its traffic-shifting task. It supports Gateway API and describes an intention for it to become the default traffic-management API in the future; that intention should not be mistaken for a completed migration. Choose based on the APIs installed in your cluster, compatibility with your Istio release, and your team’s standards rather than assuming one API is universally preferable.
Deploy distinguishable versions
Deploy both application versions behind the service identity that will receive traffic. Ensure their workloads have labels or another selector that lets Istio distinguish the versions. In the DestinationRule, define a subset for each version using the appropriate workload selector; then use those subset names as route destinations in the VirtualService. The subset names and selectors must correspond to the workloads you actually deployed.
Use fully qualified service hostnames in production configuration. Istio warns that short names are interpreted relative to the VirtualService namespace and can therefore lead to misconfiguration. See the traffic-management documentation.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Configure routes in a safe order
Istio configuration propagation is eventually consistent. If a route begins referencing a subset before the relevant destination configuration has reached the proxy, Envoy may not have an upstream pool for it and requests can return 503 errors. Apply changes in dependency order and allow time for propagation, following Istio’s traffic-management best practices.
- Add the new subset first. Update the
DestinationRuleto define the new version’s subset. - Wait for propagation. Confirm the updated destination configuration has reached the relevant proxies before routing requests to the subset.
- Add or change the route. Update the
VirtualServiceto direct traffic to the existing and new subsets, using weights or a request match. - Verify behavior. Check that requests reach the intended versions and that each version is healthy before increasing exposure.
For cleanup, reverse the dependency: remove the subset from the VirtualService first, wait for that change to propagate, and only then remove the unused subset from the DestinationRule. This avoids leaving a route that points at a subset being removed.
Shift traffic gradually, separately from scaling
Istio’s traffic-shifting example demonstrates routing a 50/50 split and then sending 100% of traffic to the new version. Those values illustrate configuration changes, not a standard A/B-test allocation or evidence of a successful result. The same task explains that traffic routing and workload scaling are separate controls: you can scale versions independently of the share of requests each receives. See Traffic Shifting.
A practical rollout is to start with a limited exposure appropriate to your risk, watch both versions, and adjust routing only when health signals support it. If a version is failing or degrading service, reduce or remove its traffic through the route configuration. Do not treat a percentage change as a substitute for checking that the application is functioning or that the test is measuring the intended outcome.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesMeasure service health and experiment outcomes separately
Use telemetry to detect operational problems
Istio describes three broad telemetry types: metrics, distributed traces, and access logs. Service-level metrics cover latency, traffic, errors, and saturation. Istio says standard service metrics are exported to Prometheus by default, although operators can turn their generation and collection off. Its observability overview explains the telemetry model, and its metrics task demonstrates querying and visualizing Istio metrics with Prometheus and Grafana.
Compare the versions’ error rates and latency, alongside other service-health signals relevant to the application. Metrics, traces, and logs can help identify a broken route, a degraded version, or a change in service behavior.
Define and analyze the outcome your test is meant to change
Operational telemetry cannot establish that users or the business benefited. Define the application-specific success measure before interpreting the test—for example, the action your product is designed to improve—and collect it with the experiment assignment so outcomes can be attributed to the intended groups. Decide how your team will evaluate the results before acting on them. Istio’s routing and observability documentation describes traffic control and service telemetry, not a statistical analysis method or evidence of a particular conversion lift.
Do not confuse application experiments with waypoint traffic sharing
Istio’s ambient waypoint documentation describes a separate capability for gradually shifting traffic between waypoints. The page says it is supported starting with Istio 1.31 and is Alpha; it is for changing which waypoint handles traffic, such as when validating a waypoint revision. It is not the same as routing application requests between service versions for an A/B test, and the page warns that labels, annotations, and behavior may change. See Configure waypoint proxies.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
