Configuring a VirtualService and DestinationRule
1. Configuring a VirtualService and DestinationRule
Let's explore how to configure VirtualService and DestinationRule. Round robin is the default load balancing method used by Envoy proxies within a service. An alternative to the round robin approach is to use VirtualService to route traffic based on workload characteristics, like different versions for A/B testing or directing traffic for internal users. This fine grained control over traffic routing is achieved by specifying hostnames within virtual service. Virtual service hostnames can be IP addresses, DNS names, or, if a virtual service is in the same namespace, Kubernetes short names. Kubernetes short names can result in misconfigurations, so it's recommended that you use a fully-qualified hostname in production. Use wildcard prefixes-- for example, star .myapp.com-- to create a single set of routing rules for all matching services. Virtual service hosts are virtual destinations and do not have to be part of the Istio service registry. Traffic can be modeled for virtual hosts, even if they do not have routable entries inside the mesh. VirtualService rules and conditions are evaluated in sequential order. In this example, requests that contain the user JSON are sent to V2, while all traffic that doesn't match this condition is sent to V3. You can choose from several different VirtualService routing options, including HTTP headers, URIs, ports, and source labels. In this example, conditional syntax with a regex is used to inspect the user agent HTTP header. IPhone users are then directed to a specific service. You can also use VirtualService faults to test the resilience of your application and measure performance in unstable conditions. Finally, traffic mirroring is a technique used to test shadow deployments and detect network intrusions. Typically, a VirtualService is coupled with a DestinationRule that determines how traffic is routed. DestinationRules are used to specify named service subsets. For example, you can use them to group a service's instances by version. These subsets can then be used in VirtualService routing rules to direct traffic to specific instances of your services. These labels are defined as metadata in the deployment of a Kubernetes service. DestinationRules offer different routing strategies. Strategies include load balancing options, round robin, random, least request, and pass-through; configuring session affinity so that clients are consistently routed to the same service instance; and configuring circuit breaking to limit the impact of failures and latency spikes. Including multiple destinations in the route attribute lets you split traffic with your VirtualService. These destinations are defined as subsets. For example, a service might have deployment strategy subsets like canary, A/B, or blue/green. The labels in the DestinationRule must match your pod labels for this configuration to take effect. And the subset field in the VirtualService and DestinationRule must match. Rather than basing traffic splitting on the number of compute instances in the infrastructure, you can leverage a VirtualService's traffic splitting functionality to set specific traffic percentages. This lets you control traffic independently of the number of compute instances in each subset, resulting in traffic management that is decoupled from infrastructure scaling.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.