Skip to content

Virtual Service

In the Virtual Service, you can use various matching methods such as port, host, header, etc., to route and distribute requests from different regions and users to specific service versions, divided by weight.

Virtual Service provides routing support for three protocols: HTTP, TCP, and TLS.

Virtual Service List

The Virtual Service list displays the Virtual Service CRD information under the mesh. Users can view it by namespace or filter the CRDs based on scope and rule labels. The rule labels include:

  • HTTP routing
  • TCP routing
  • TLS routing
  • Rewrite
  • Redirect
  • Retry
  • Timeout
  • Fault injection
  • Proxy service
  • Traffic mirroring

For the configuration of these label fields, refer to the Istio Virtual Service Configuration Parameters.

Virtual Service provides two creation methods: graphical wizard creation and YAML creation.

Graphical Wizard Creation Steps

The specific steps for creating using the graphical wizard are as follows (refer to Virtual Service Parameters Configuration):

  1. Click Traffic Management in the left navigation bar, then click Virtual Service , and click the Create button in the upper right corner.

    Create

  2. In the Create Virtual Service page, confirm and select the namespace, service, and application scope where the virtual service will be created, then click Next .

    Create Virtual Service

  3. Configure the HTTP routes, TLS routes, and TCP routes as prompted on the screen, then click OK .

    Routing Configuration

  4. Return to the Virtual Service list, and there will be a prompt indicating successful creation. On the right side of the Virtual Service list, click the ⋮ in the "Actions" column to perform more operations from the pop-up menu.

    More Actions

YAML Creation

The operation for creating using YAML is relatively simple. You can click the Create by YAML button to enter the creation page and directly write YAML. Alternatively, users can use the provided templates on the page to simplify the editing process. The editing window provides basic syntax checking functionality to assist users in writing. Here is an example YAML:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  annotations:
    ckube.daocloud.io/cluster: dywtest3
    ckube.daocloud.io/indexes: '{"activePolices":"HTTP_ROUTE,RETRIES,","cluster":"dywtest3","createdAt":"2023-08-07T09:27:48Z","gateway":"nginx-gw/nginx-gwrule","gateways":"[\"nginx-gw/nginx-gwrule\"]","hosts":"[\"www.nginx.app.com\"]","is_deleted":"false","labels":"","name":"nginx-vs","namespace":"nginx-gw"}'
  creationTimestamp: "2023-08-07T09:27:48Z"
  generation: 10
  managedFields:
    - apiVersion: networking.istio.io/v1beta1
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:annotations:
            .: {}
            f:ckube.daocloud.io/cluster: {}
            f:ckube.daocloud.io/indexes: {}
        f:spec:
          .: {}
          f:gateways: {}
          f:hosts: {}
          f:http: {}
      manager: cacheproxy
      operation: Update
      time: "2023-08-09T03:06:31Z"
  name: nginx-vs
  namespace: nginx-gw
  resourceVersion: "477662"
  uid: 446e8dcf-3c26-47ec-8754-997c21e4df17
spec:
  gateways:
    - nginx-gw/nginx-gwrule
  hosts:
    - www.nginx.app.com
  http:
    - match:
        - uri:
            prefix: /
      name: nginx-http
      retries:
        attempts: 2
        perTryTimeout: 5s
        retryOn: 5xx
      route:
        - destination:
            host: nginx.nginx-test.svc.cluster.local
            port:
              number: 80
status: {}

Concepts

  • Hosts

    The target hosts for traffic. They can come from service registration information, service entries, or user-defined service domain names. They can be DNS names with wildcard prefixes or IP addresses. Depending on the platform, short names may be used instead of FQDN. In this case, the conversion from a short name to an FQDN is handled by the underlying platform.

    A hostname can only be defined in one VirtualService. The same VirtualService can control the traffic properties for multiple HTTP and TCP ports.

    It is important to note that when using the short name of a service (e.g., using "reviews" instead of reviews.default.svc.cluster.local ), the service mesh will handle this name based on the namespace of the rule, not the namespace where the service resides. Suppose a rule in the default namespace includes a host reference to reviews . It will be treated as reviews.default.svc.cluster.local , regardless of the namespace where the reviews service resides.

    To avoid potential misconfigurations, it is recommended to use FQDN for service references. The hosts field is valid for both HTTP and TCP services. Services in the mesh, which are registered in the service registry, must be referenced using their registered names; only services defined by Gateways can be referenced using IP addresses.

    Example:

    spec:
  hosts:
  - ratings.prod.svc.cluster.local

  • Gateways

    By binding VirtualServices to gateway rules with the same host, these hosts can be exposed outside the mesh.

    The mesh uses the reserved keyword "mesh" to refer to all Sidecars in the mesh. When this field is omitted, the default value ("mesh") will be used, which applies to all Sidecars in the mesh. If the gateways field is set with gateway rules (can have multiple), it will only apply to the declared gateway rules. If you want to apply the rules to both gateway rules and all services, you need to explicitly include "mesh" in the gateways list.

    Example:

    gateways:
- bookinfo-gateway
- mesh

  • HTTP

    An ordered list of rules that contain all the routing configurations for HTTP protocol. It applies to service ports with names prefixed with http- , http2- , grpc- , or protocols as HTTP, HTTP2, GRPC, and terminating TLS, as well as ServiceEntry using HTTP, HTTP2, and GRPC protocols. Traffic will be handled by the first rule that matches.

    Explanation of main fields in HTTP:

    • Match

      The conditions that must be satisfied for a rule to be activated. All conditions within a single match block have AND semantics, while the match blocks have OR semantics. If any match block succeeds, the rule is considered a match.

    • Route

      HTTP rules can either redirect or forward (default) traffic.

    • Redirect

      HTTP rules can either redirect or forward (default) traffic. If traffic is specified to go through an option in the rule, routing/redirecting will be ignored. Redirect primitives can be used to send HTTP 301 redirects to other URIs or authorities.

    • Rewrite

      Rewrite the HTTP URI and Authority header. Rewriting cannot be used together with redirect primitives.

    • Fault

      Fault injection policies for client-side HTTP communication. Enabling fault injection policies on the client side will disable timeouts or retries.

    • Mirror/MirrorPercent

      Mirror HTTP traffic to another destination, with the ability to set the mirroring percentage.

    • TCP

      An ordered list of routes for passthrough TCP traffic. TCP routing applies to all ports except for HTTP and TLS. Incoming traffic will be handled by the first rule that matches.

    • TLS

      An ordered list corresponding to passthrough TLS and HTTPS traffic. The routing process usually relies on the SNI in the ClientHello message. TLS routing typically applies to platform service ports with prefixes like https- or tls-, or HTTPS, TLS protocol ports passed through a Gateway, and ServiceEntry ports using HTTPS or TLS protocols. Note: HTTPS or TLS traffic on ports without an associated VirtualService will be treated as passthrough TCP traffic.

    The TCP protocol and its subfields are relatively simple, only containing "match" and "route" parts, which are similar to HTTP and will not be repeated here.

Reference

Comments