Skip to main content
In this lesson, you will learn how to adjust traffic weight distribution between different versions of the reviews application and implement header-based routing rules. This guide details how to define application versions with Destination Rules, create a Virtual Service to manage traffic distribution, and apply advanced routing policies based on request headers. ──────────────────────────────

1. Define Destination Rules

Before modifying traffic distribution, you must define the different versions of your application using Destination Rules. Apply the default Destination Rules from the Samples directory with the following command:
Expected output:
Destination Rules allow Istio to control traffic policies for different versions (or subsets) of an application.
──────────────────────────────

2. Create a Virtual Service with Traffic Weight Distribution

Create a Virtual Service for the reviews application to split traffic between two subsets (v1 and v2) with a 75-25% distribution. Ensure that the total weight equals 100. The YAML configuration below sets up the Virtual Service:
Apply the Virtual Service and verify its configuration with the commands below:
You should see output similar to:
──────────────────────────────

3. Verify Configuration via Kiali

Switch to Kiali to inspect your Istio configurations. In Kiali, you will see that the Destination Rule for the reviews service defines three subsets (v1, v2, and v3):
The Virtual Service confirms the weight distribution as follows:
In Kiali’s visual graph, you will observe that traffic is split between v1 and v2 based on the specified weights. ──────────────────────────────

4. Testing and Adjusting Traffic Distribution

When you access the reviews application, version v1 should be more frequent than version v2, reflecting the 75-25 traffic split. This difference becomes more apparent as traffic increases.

Adjusting Weight Distribution

To modify the split—for instance, routing 99% of traffic to v1 and only 1% to v2—update the configuration as shown below:
After applying this change, monitor the application to notice the significant traffic shift toward version v1.
Consider using load testing tools to generate sufficient traffic. This helps in accurately observing the effects of different weight distributions.
──────────────────────────────

5. Routing Requests Based on Headers

In addition to traffic splitting, Virtual Services allow you to create advanced routing policies based on request headers. This feature is particularly useful if you want to serve different application versions based on user attributes.

Example 1: Routing KodeKloud Users to v2

This configuration directs requests with an “end-user” header value of “kodekloud” to subset v2, while all other requests are routed to subset v1:
When a KodeKloud user signs in, the “end-user” header is set to “kodekloud”, and the user sees the version v2 experience (represented with a black star).

Example 2: Introducing a Test Group for a New Version

To gradually roll out a new version (v3) for test users, extend the Virtual Service with an additional match rule. In this approach:
  • Requests with “end-user: kodekloud” continue to use v2.
  • Requests with “end-user: testuser” are directed to v3.
  • All other requests default to v1.
With this configuration:
  • Requests with “end-user: kodekloud” are routed to version v2.
  • Requests with “end-user: testuser” go to the new version v3.
  • All other requests default to version v1.
When users sign in with their respective usernames, these routing rules take effect without interfering with the predefined traffic weights. ──────────────────────────────

Conclusion

Virtual Services empower you to control and manage traffic flow between different application versions seamlessly. In this lesson, you learned how to:
  • Define application versions using Destination Rules.
  • Configure weight-based traffic splitting through a Virtual Service.
  • Validate the configuration with Istio analysis tools and Kiali.
  • Implement header-based routing to tailor the user experience based on request attributes.
These strategies enable safe feature rollouts, A/B testing, and dynamic production traffic management. For more detailed information, refer to the following resources: Happy routing!

Watch Video

Practice Lab