How to understand VirtualService and DestinationRule in Istio?

Istio defined dozens of CRDs when it was just open-sourced, including RouteRule , DestinationPolicy , EgressRule , etc. for traffic governance, and later launched the v1alpha3 API
Replaced the previous API with VirtualService and DestinationRule etc. However, the definition of these resource objects is not as intuitive as in Kubernetes, and it is somewhat difficult to understand. For example, VirtualService , you may think that it is only the first “virtual service” just by looking at the name, but this is not the case.

This article will give you an intuitive and brief introduction to the two core traffic governance objects in Istio— VirtualService and DestinationRule —by making an analogy with actual traffic.

Traffic vs Traffic

Many people who are new to Istio may not understand VirtualService and DestinationRule and the two resource objects very well. If we limit the environment to Kubernetes clusters only, we can compare routing to traffic in the real world. There are many vehicles driving on the road. This is traffic. DestinationRule is equivalent to opening up a road/path/lane, ensuring reachability between two points and controlling the number, width, etc. of lanes. And VirtualService is like traffic lights and road markings, directing vehicles where to drive and how to drive. That is to say, if you only define DR, it will not have any impact on the traffic, because you do not direct how the traffic goes, so you must define the VirtualService to control the direction of the traffic.

To sum it up in one sentence: DestinationRule opens up the passage between the two places, just like building roads and bridges to connect tunnels, while controlling lanes to set up roadblocks; VirtualService does vehicle command and dispatch.

Take a look at the following chart comparing traffic and traffic to help you understand this metaphor more intuitively.

image

Traffic and traffic comparison chart

Traffic governance

The following lists the traffic governance behaviors that you can do on these two resource objects respectively.

VirtualService

  • Routing: Canary publishing, matching routing based on user body, URI, Header, etc.;
  • Error injection: HTTP error code injection, HTTP delay injection;
  • Traffic segmentation: percentage-based traffic segmentation routing;
  • Traffic mirroring: send a certain percentage of traffic mirroring to other clusters;
  • Timeout: Set the timeout time, the request will fail after the set time;
  • Retry: Set the retry strategy, such as trigger conditions, number of retries, interval time, etc.;

DestinationRule

  • Load balancing: Set load balancing strategies, such as simple load balancing, region-aware load balancing, and regional weighted load balancing;
  • Circuit Breaking: Eliminate abnormal nodes from the load balancing pool through Outlier Detection and connection pool settings;

Summarize

This article compares abstract traffic management with real traffic management to help you understand the traffic management objects VirtualService and DestinationRule in Istio more intuitively. At the same time, the traffic governance functions that can be performed based on them are introduced. VirtualService is mainly used to set routing rules, and service elasticity (timeout, retry, fuse, etc.) needs to be maintained together with DestinationRule.

refer to

This article is reprinted from https://jimmysong.io/blog/understand-istio-vs-and-dr/
This site is for inclusion only, and the copyright belongs to the original author.