preface

Istio’s traffic routing rules allow you to easily control traffic and API calls between services. Istio simplifies the configuration of service level properties such as fuses, timeouts, and retries, and makes it easy to set up important tasks such as A/B testing, Canary publishing, and probability publishing based on traffic percentage segmentation.

demo

Interface specification

When learning Istio traffic management, a simple interface request is designed based on the official demo.

  • The book application:

    The main application entry, calling the other two services for interface return

  • Comment: Comment on the application
    • Default version: Use the master branch and return the default data
    • Dev version: use the dev branch and add the star field to the default
  • User: user application

    Return user information, both book and comment are called

The application list

Service list

Interface Request Example

  • The interface address: http://bookurl/book/detail? id=1
  • Return the sample
{
    "code": 200."message": "ok"."data": {
        "name": "Jane Eyre"."author": "Charlotte Bronte"."registerId": 1."commentList": [{"bookId": 1."userId": 1."content": "The book is so well written."."datetime": "The 2021-05-19 03:03"."userInfo": {
                    "id": 1."name": "Zhang"."age": 35}}, {"bookId": 1."userId": 2."content": "This is a good book."."datetime": "The 2021-05-19 03:03"."userInfo": {
                    "id": 2."name": "Bill"."age": 50}}]."registerInfo": {
            "id": 1."name": "Zhang"."age": 35}}}Copy the code
  • Field description: All fields are displayed for subsequent adjustment
    • CommentList: commentList
    • UserInfo: indicates the user information

Call structure

Description of traffic management components

A virtual service

concept

Virtual services and Destination rules are key pieces of the Istio traffic routing function. Virtual services let you configure how requests are routed to services within the service grid, based on Istio and the basic connectivity and service discovery capabilities provided by the platform.

Why use virtual services?

Virtual services play a critical role in enhancing the flexibility and effectiveness of Istio traffic management by decoupling the target address of a client request from the target workload of the actual response request. Virtual services also provide rich ways to specify different routing rules for traffic sent to these workloads.

Virtual service function points
  • Multiple application services are processed through a single virtual service.
  • Integrate with the gateway and configure traffic rules to control incoming and outgoing traffic

Target rules

concept

As with virtual services, target rules are a key part of Istio’s traffic routing capabilities. You can think of virtual services as how traffic is routed to a given target address, and then the target rules are used to configure the traffic to that target. After evaluating the virtual service routing rules, the target rules are applied to the “real” destination address of the traffic.

Load balancing options

By default, Istio uses a polling load balancing policy, and each instance in the instance pool obtains requests in turn. Istio also supports the following load balancing models, which can be specified in DestinationRule for traffic to a particular service or subset of services.

  • Random: Requests are routed to instances in the pool in a random manner.
  • Weight: The request goes to the instance based on the percentage specified.
  • Least requested: The request is forwarded to the least accessed instance.

The demo presentation

Configure target rules (mainly to demonstrate the application of COMMENT)

  • Add file:vim destinationRule.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: comment                 // Name of the target rule set
  namespace: istiopreview       // The namespace
spec:
  host: comment-svc             // Name of the corresponding service
  subsets:                      // Routing rule set
    - name: default             // Specific rule name
      labels:                   // Select according to the label
        version: master         // App tag selector
    - name: dev
      labels:
        version: dev
Copy the code
  • To set the rule to the cluster:kubectl apply -f destinationRule.yaml
  • Viewing routing rules:kubectl get destinationrules.networking.istio.io -n istiopreview

Set a virtual service rule

  • Add file:vim virtualService.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: comment-virtual-svc              // Name of a virtual service rule
  namespace: istiopreview                // Namespace Settings
spec:
  hosts:
    - "comment-svc"                      // The original service corresponding to the virtual service
  http:                                  // HTTP Rule Setting
    - route:                             // The routing configuration
        - destination:                   // describe
            host: comment-svc            // Routing the host
            subset: default              // Routing rule selection
        - destination:
            host: comment-svc
            subset: dev
Copy the code
  • To add a virtual service to a cluster:kubectl apply -f virtualService.yaml
  • View virtual services:kubectl get virtualservices.networking.istio.io -n istiopreview

Demo 1: Request routing rules by weight

  • Adjust virtual service configuration:vim virtualService.yaml
.
        - destination:
            host: comment-svc
            subset: default
          weight: 100              // Set the weight to 100
        - destination:
            host: comment-svc
            subset: dev
          weight: 0                // Set the weight to 0
Copy the code
  • Effect: Originally according to K8S service load will be 50% traffic to default, 50% traffic to dev, after this configuration. 100% traffic is going to default, and no traffic is going to dev application.

Demo 2: Setting timeout

  • Example Add a routing rule for the user application route

    • vim userdestinationRule.yaml
    apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: user
  namespace: istiopreview
spec:
  host: user-svc
  subsets:
    - name: default
      labels:
        app: user
Copy the code
    • vim uservirtualService.yaml
    apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: user
  namespace: istiopreview
spec:
  host: user-svc
  subsets:
    - name: default
      labels:
        app: user
Copy the code
    • kubectl apply -f userdestinationRule.yaml && kubectl apply -f uservirtualService.yaml

  • Set a 10-second delay for the user virtual service

    • vim uservirtualService.yaml
    .
  - route:
    - destination:
        host: user-svc
        subset: default
    fault:                          // Fault injection
      delay:                        // delay
        percent: 100                // The percentage
        fixedDelay: 10s             // Fixed delay time
.
Copy the code
    • kubectl apply -f uservirtualService.yaml
    • Authentication: The browser requests the interface, takes 20 seconds (because both services request the user), the authentication succeeds.

  • Add timeout control to the COMMENT virtual service

    • vim virtualService.yaml
    .
    - route:
      - destination:
          host: comment-svc
          subset: default
        weight: 50
      - destination:
          host: comment-svc
          subset: dev
        weight: 50
      timeout: 5s
Copy the code
    • kubectl apply -f virtualService.yaml

  • Authentication timeout: The interface request takes 15 seconds (book->user takes 10 seconds, book->comment takes 5 seconds), but the comment information is not returned, and the timeout succeeds.

Other functions will not be demonstrated, interested can refer to the document to do the demo to try

Reference document: Virtual Service

conclusion

Routing rules and virtual services are very important in ISTIO traffic management. Only through them can we perform non-intrusive operations such as fault injection, timeout, route configuration, etc. For virtual services, they can be regarded as Sidecar of the service side, which proxies all traffic of the service. The system processes the traffic according to the configured rules. This article uses two small demos to show how the virtual service performs traffic operations. Interested parties can handle more operations according to the official documents, such as routing rewrite, gray request and so on.