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: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: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):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: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: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.
- 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.
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.