When moving applications to the cloud, how can we do without containers! Click on the Container Cube above to follow me.
Fault Injection Testing
Fault injection testing, as the name suggests, checks whether the fault tolerance mechanism of an application works correctly when some components or functionalities of the tested application encounter potential failures, ensuring that normal components or functionalities can still be used. Istio provides HTTP fault injection capabilities, allowing users to set one or more faults during the HTTP request forwarding process. The modifications for fault injection apply to the Virtual Service and there are two different fault modes: abort and delay.
Type
Belongs To
Description
abort
HTTPFaultInjection.Abort
Interrupt the HTTP request and return a predetermined error status code to the requester.
delay
HTTPFaultInjection.Delay
Return the HTTP request response after a preset delay.
To facilitate understanding of the content in this article, we have pre-deployed the bookinfo example.
The image shows the original complete virtual service, which is set to route requests to the v4 version of reviews when the cookie matches user=vip, while all others will flow to the v1 version.
Abort Fault
When a user injects an abort fault into a certain load, all HTTP requests accessing that load will receive the predetermined error status code instead of the correct content response. The image shows a YAML snippet from the reviews virtual service file.
We can see that in the routing rules for version v1, a fault object has been added. This fault object contains the set fault properties. It can be interpreted as the v1 version adding an abort fault and setting the returned HTTP status code to 501, with a percent set to 100, meaning that all requests to v1 will receive a 501 HTTP response. It is evident that if this were set to 50, only half of the requests would receive a 501 response, while the other half would receive a normal response.
If we access the product page, we can only see basic error information and cannot determine whether this is due to the preset abort fault or if the service has “crashed” for some other reason.
To confirm that the service interruption was caused by our manual injection and not by something else, we must directly access reviews. Configure an external IP for the Reviews component, open the browser, press F12, select network, and enter “address/reviews/0” in the address bar. In the network tab, there will be a red error message; clicking on it will reveal our preset 501 error status code. Thus, the abort fault has been successfully injected. To remove it, simply delete the fault object.
If at this point we access v4 with the cookie set to user=vip, we can see that the reviews can be displayed normally.
Delay Fault Injection
In addition to the previously mentioned interruption service fault, delay faults can also be manually injected into components. In the previously used bookinfo example, there are two versions: v1 and v4. We have already injected an abort fault into version v1, and now we will inject a delay fault into version v4, setting the delay time to 2 seconds, meaning all requests accessing v4 will have a 2-second delay.
As shown, we open the product page and the reviews page to verify:
From here we can see the product page response took 2.39 seconds.
The reviews page response took 2.27 seconds.
We have introduced two basic methods of fault injection with examples.
Next, let’s look at some other fault injection examples.
Virtual Service Example 1:
In this example, when the cookie matches user=vip, a delay fault will be triggered, accessing the v4 version after a 2-second delay. When user=svip, an abort fault will be triggered, and when the cookie does not meet either of the above conditions, normal access to the v1 version is allowed.
Virtual Service Example 2:
In this example, regardless of whether the cookie matches vip or svip, or does not meet either condition, access to the v1 version is allowed. This is due to the route object being placed first, which has no matching conditions; therefore, regardless of the cookie value, it “meets the condition,” allowing all traffic to flow directly to version v1 without any processing. It is important to note that if you manually add fault injection, be cautious of the relative order, or you may not achieve the desired result.
Virtual Service Example 3:
In this virtual service, we have injected two different faults into the same version. Any one of the conditions can trigger the corresponding fault. If none of the conditions are met, normal access to version v1 will occur by default. The question arises: if I do not configure the last route, and there is a request that meets neither the abort fault matching condition nor the delay fault matching condition, where will the request go? For this type of YAML configuration, the outcome is straightforward: if the request does not meet any conditions, it will directly receive a 404 response and will not automatically flow into any other version.
Fault injection testing provides comprehensive reliability testing for applications before they go live. Istio makes it extremely convenient for users to perform fault injection by allowing them to add 3-4 lines of configuration in the correct places without modifying application code. I hope more people can utilize the convenience provided by Istio’s fault injection capabilities to enhance their development and testing efficiency.
Recommended Reading
Idou Teacher Teaches You Istio: Introduction to Monitoring Capabilities
Idou Teacher Teaches You Istio: How to Provide Security Protection for Services
ClickRead Original, Sign Up Immediately