Istio Introduction (5): Access Control and Traffic Management

VirtualService and DestinationRule

Relationship Between VirtualService and Service

Istio's VirtualService and Kubernetes' Service are both components of service governance, but they have different roles and relationships.

Below is the relationship and differences between them:

Definition and Function

Kubernetes' Service primarily handles service discovery and load balancing, providing a unified access point for a set of Pods running the same application.

On the other hand, Istio's VirtualService is primarily responsible for defining traffic routing rules, enabling fine-grained control over traffic between services.

Relationship

VirtualService and Service are interrelated.

In the definition of VirtualService, traffic can be routed to a Kubernetes Service, with VirtualService enhancing traffic management and control features on top of the Service.

Please note this carefully.

When defining VirtualService, the traffic routing must point to a Service.

    route:
    - destination:
        host: productpage
        port:
          number: 9080

    route:
    - destination:
        host: productpage.bookinfo.svc.cluster.local
        port:
          number: 9080

However, the traffic requests between services do not actually reach the Service, because when the traffic is sent to Envoy, Istio directly forwards the traffic to the corresponding Pod.

It has been emphasized many times that the traffic does not actually reach the Service.

Here, the Service provides some basic information about the Pods to Envoy, and VirtualService enhances the traffic management and control features on top of the Service.

Although Istio uses Envoy to manage traffic, Kubernetes' Service still plays a role in Istio. The Service is used to define the basic attributes of the service, such as the service name and port. Istio uses this information to get the endpoints of the service from the Kubernetes API server and passes this information to Envoy. This way, Envoy knows how to route to other services.

Functional Differences

Kubernetes' Service provides basic load balancing and service discovery features, while Istio's VirtualService offers richer traffic management capabilities such as traffic distribution by weight, request retries, fault injection, traffic mirroring, and more.

Compatibility

Istio can seamlessly integrate with Kubernetes clusters, allowing VirtualService and Service to work together for more powerful service governance features. Istio supports not only Kubernetes but can also be used with other platforms (such as VMs, Consul, etc.).

In summary, Istio's VirtualService and Kubernetes' Service complement each other, jointly providing more powerful traffic management and control features for services. When using Istio, it is usually necessary to combine VirtualService with Kubernetes' Service to achieve the desired service governance goals.

Relationship Between VirtualService and DestinationRule

In Istio, VirtualService and DestinationRule are two key Custom Resource Definitions (CRDs) used to configure and control traffic routing between services.

Their relationship can be summarized as follows: VirtualService defines traffic routing rules, while DestinationRule defines how traffic is load-balanced and connection pool managed once it reaches its destination.

VirtualService is used to define traffic routing rules. When a request goes from one service to another, VirtualService can specify how to route the traffic to different destinations (for example, different service instances, versions, or subsets). VirtualService can also match and distribute traffic based on request attributes (such as request headers, paths, sources, etc.). Additionally, VirtualService can configure complex routing behaviors such as retries, timeouts, and fault injection.

DestinationRule is used to control traffic distribution and connection pool management. DestinationRule defines subsets of a service (i.e., different versions or variants of the service) and specifies how to distribute traffic to these subsets based on load balancing strategies (such as round-robin, random, least connections, etc.). Furthermore, DestinationRule can configure connection pool settings (like maximum connections, idle timeouts, etc.) and transport layer security policies (such as TLS settings).

In short, VirtualService and DestinationRule work together in Istio to achieve fine-grained traffic control. VirtualService defines the traffic routing rules, while DestinationRule takes care of load balancing and connection pool management once traffic reaches the destination.

Definition of VirtualService

The spec of VirtualService includes five main categories of attributes.

spec:  
  hosts: 
  gateways:  
  http:     
  tls: 
  tcp: 

hosts: This is a list of strings used to specify the target hosts for which the VirtualService applies. These hosts can be Kubernetes Service names or external service domain names. Traffic will be routed based on these hosts.

  hosts:  
  - my-service.example.com  

gateways: This is a list of strings used to specify the gateways that apply to the VirtualService. Istio gateways configure traffic entering and exiting the mesh. If this field is omitted, the VirtualService only applies to traffic within the mesh by default.

  gateways:  
  - my-gateway  

http: This attribute contains a list of HTTPRoute to define HTTP traffic routing rules. Each HTTPRoute can include match conditions, routing targets, retries, timeouts, and more configuration options.

The http attribute is a field in the VirtualService spec that contains a list of HTTPRoute to define HTTP traffic routing rules. An HTTPRoute includes the following main attributes:

match: This attribute contains a list of HTTPMatchRequest to define traffic matching conditions. Each HTTPMatchRequest can include the following matching conditions:

• uri: Matching conditions for the request URI, which can be prefix matching, exact matching, or regular expression matching.
• method: Matching conditions for the request method (such as GET, POST, etc.).
• headers: Matching conditions for request headers, which can be prefix matching, exact matching, or regular expression matching.
• queryParams: Matching conditions for query parameters, which can be prefix matching, exact matching, or regular expression matching.
• sourceLabels: Matching conditions for the Pod labels from which the traffic originates.
• gateways: List of gateways from which the traffic originates.

route: This attribute contains a list of HTTPRouteDestination to define traffic routing targets. Each HTTPRouteDestination includes the following properties:

• destination: The destination of the traffic including host (target hostname), subset (target service subset), and port (target port).
• weight: The weight for traffic distributed to this destination. The total weight of all routing targets should sum to 100.

redirect: This attribute is used to configure HTTP redirection. It can specify the redirect URI, Authority, and status code.

rewrite: This attribute is used to configure rules for rewriting URI and Authority.

timeout: This attribute is used to configure the timeout duration for requests.

retries: This attribute is used to configure the retry strategy, including the number of attempts, timeout per attempt, and retriable status codes.

fault: This attribute is used to configure fault injection, including delay injection and exception injection. This is useful for testing and simulating failure scenarios.

mirror: This attribute is used to configure the traffic mirroring destination. Traffic mirroring allows traffic to be duplicated to another service for observation and testing.

corsPolicy: This attribute is used to configure CORS policy, including allowed origins, allowed methods, allowed headers, etc.

headers: This attribute is used to configure operations on request and response headers, including adding, modifying, and deleting headers.

tls: This attribute contains a list of TLSRoute to define routing rules for TLS traffic based on SNI. Each TLSRoute can include matching conditions and routing targets.

tcp: This attribute contains a list of TCPRoute to define routing rules for TCP traffic. Each TCPRoute can include matching conditions and routing targets.

Here is an example of a VirtualService.

apiVersion: networking.istio.io/v1alpha3  
kind: VirtualService  
metadata:  
  name: my-virtual-service  
spec:  
  hosts:  
  - my-service.example.com  
  gateways:  
  - my-gateway  
  http:  
  - match:  
    - uri:  
        prefix: /api/v1  
    route:  
    - destination:  
        host: my-service-v1  
      weight: 90  
    - destination:  
        host: my-service-v2  
      weight: 10  
    retries:  
      attempts: 3  
      perTryTimeout: 2s  
    timeout: 10s  
  - route:  
    - destination:  
        host: my-service-v1  

Definition of DestinationRule

The spec of DestinationRule includes three main categories of attributes.

spec:  
  host: my-service  
  trafficPolicy:  
  subsets:  

host: This attribute is a string used to specify the target hostname. It can be a Kubernetes Service name or an external service domain name.

trafficPolicy: This attribute is used to configure global traffic policies, including load balancing strategies, connection pool settings, and transport layer security policies. These settings will apply to all subsets (unless explicitly overridden within subsets).

subsets: This attribute contains a list of Subset to define the service's subsets (i.e., different versions or variants of the service). Each Subset includes the following properties:

• name: The name of the subset.
• labels: The label selectors for the subset. These labels are used to select the corresponding Kubernetes Pods for the subset.
• trafficPolicy: The traffic policy for the subset. These settings will override the global trafficPolicy.

Here is an example:

apiVersion: networking.istio.io/v1alpha3  
kind: DestinationRule  
metadata:  
  name: my-destination-rule  
spec:  
  host: my-service  
  trafficPolicy:  
    loadBalancer:  
      simple: LEAST_CONN  
    connectionPool:  
      tcp:  
        maxConnections: 100  
      http:  
        http2MaxRequests: 1000  
    tls:  
      mode: ISTIO_MUTUAL  
  subsets:  
  - name: v1  
    labels:  
      version: v1  
    trafficPolicy:  
      loadBalancer:  
        simple: ROUND_ROBIN  
  - name: v2  
    labels:  
      version: v2