Must read! Traffic management concepts in Istio Service Mesh

This article is from Istio’s official Chinese documentation and is maintained by the ServiceMesher community.

This page provides an overview of how traffic management works in Istio, including the benefits of traffic management principles. This article assumes that you have read what Istio is? I am familiar with the top-level design architecture of Istio. You can learn more about the individual traffic management capabilities in the other guides in this section.

Pilot and Envoy

The core component of Istio traffic management is Pilot, which manages and configures all Envoy proxy instances deployed in a specific Istio service grid. It allows you to specify what routing traffic rules to use between Envoy proxies and configure failover features such as timeouts, retries, and fuses. It also maintains a canonical model of all the services in the grid and uses this model to inform the Envoy about other instances in the grid by discovering services.

Each Envoy instance maintains load balancing information from Pilot and periodic health checks on other instances in the load balancing pool. This allows it to intelligently distribute traffic between target instances while following the routing rules it specifies.

Benefits of traffic management

Using Istio’s traffic management model essentially decouples traffic from infrastructure expansion, allowing operations to specify what rules traffic follows through Pilot rather than which PODS/VMS should receive traffic — Pilot and Intelligent Envoy agents will take care of that for us. So, for example, you can specify through Pilot that 5% of traffic for a particular service can be forwarded to the Canary version, regardless of the size of the Canary deployment, or that traffic is sent to a particular version based on the content of the request.

Traffic management in Istio

Decoupling traffic from infrastructure extensions allows Istio to provide a variety of traffic management capabilities outside of the application code. In addition to dynamic request routing for A/B testing, progressive roll-out, and canary publishing, it handles fail-over using timeouts, retries, and fuses, and finally fail-over injection to test compatibility of fail-over strategies between services. These functions are implemented through Envoy Sidecar/proxies deployed in the service grid.

Pilot is responsible for the life cycle management of Envoy instances deployed in the Istio service grid.

Pilot architecture

As shown in the figure above, Pilot maintains a canonical representation of services in the grid that is independent of the underlying platform. The platform-specific adapter in Pilot is responsible for populating this specification model appropriately. For example, the Kubernetes adapter in Pilot implements the controllers necessary to monitor changes to pod registration information, ingress resources, and third-party resources used to store traffic management rules in The Kubernetes API Server. This data is translated into a canonical representation. The Envoy specific configuration is generated based on the canonical representation.

Pilot exposes apis for service discovery, load balancing pools, and dynamic updates to routing tables. These apis relieve Envoy of its platform-specific nuances, simplify design and improve portability across platforms.

O&m personnel can specify advanced traffic management Rules using the Rules API of Pilot. These rules are translated into low-level configurations and distributed to the Envoy instance via the Discovery API.

Request routing

As described in Pilot, the canonical representation of services in a particular grid is maintained by Pilot. The Istio model of a service has nothing to do with the expression in the underlying platform (Kubernetes, Mesos, Cloud Foundry, etc.). Platform-specific adapters are responsible for retrieving the various fields of metadata from their respective platforms and populating the service model.

Istio introduces the concept of service versioning, which can be further segmented by version (V1, V2) or environment (staging, PROd). These versions don’t have to be different API versions: they can be different iterations of the same service deployed in different environments (Prod, staging, dev, and so on). Common scenarios for using this approach include A/B testing or Canary deployment. Istio traffic routing rules provide additional control over the traffic between services based on the service version.

Communication between services

The service version

As shown in the figure above, the client of the service is unaware of the differences between different versions of the service. They can continue to access the service using the host name or IP address of the service. The Envoy Sidecar/proxy intercepts and forwards all requests and responses between the client and server.

The operator uses Pilot to specify routing rules that Envoy dynamically determines the actual selection of its service version. This model enables application code to decouple it from its service-dependent evolution while providing additional benefits (see Mixer). Routing rules enable Envoy to make version selections based on criteria such as headers, tags associated with the source/destination, and/or weights assigned to each version.

Istio also provides traffic load balancing for multiple instances of the same service version. You can find more information in service discovery and load balancing.

Istio does not provide DNS. An application can try to resolve an FQDN using DNS services that exist in the underlying platform (Kube-DNS, MESos-DNS, and so on).

Ingress and Egress

Istio assumes that all traffic entering and leaving a service network travels through an Envoy proxy. By deploying an Envoy proxy in front of A service, operations personnel can perform A/B testing against user-facing services, deploy canary services, and so on. Similarly, by using an Envoy to route traffic to external Web services (for example, visiting the Maps API or video service API), operations personnel can add timeout controls, retries, circuit breakers, and other features to these services, while also capturing various details from the service connections.

The request flow

Service discovery and load balancing

Service registry: Istio assumes that a service registry exists to keep track of pods/VMS for services in the application. It also assumes that new instances of the service are automatically registered in the service registry, and that unhealthy instances will be automatically deleted. Platforms such as Kubernetes, Mesos, and others already provide this functionality for container-based applications. There are even more solutions for virtual machine based applications.

Service discovery: Pilot uses information from service registries and provides a platform-independent service discovery interface. The Envoy instance in the grid performs service discovery and dynamically updates its load balancing pool accordingly.

Discovery and load balancing

As shown in the figure above, services in the grid access each other using their DNS names. All HTTP traffic for the service is automatically re-routed through the Envoy. Envoy distributes traffic between instances in a load-balancing pool. While Envoy supports a variety of complex load balancing algorithms, Istio currently allows only three load balancing modes: round-robin, random, and weighted minimum requests.

In addition to load balancing, the Envoy periodically checks the health of each instance in the pool. Envoy follows the fuse style pattern, classifying instances as unhealthy or healthy based on the failure rate of health check API calls. In other words, when the number of health check failures for a given instance exceeds a preset threshold, it will be ejected from the load balancing pool. Similarly, when the number of health checks passed exceeds a predetermined threshold, the instance is added back to the load balancing pool. You can learn more about Envoy’s fault handling capabilities in Troubleshooting.

Services can proactively lighten the load by responding to health checks using HTTP 503. In this case, the service instance is immediately removed from the caller’s load balancing pool.

Fault handling

Envoy offers a set of out-of-the-box, optional fail-over features that will greatly benefit services in applications. These features include:

1. timeout
2. Limited retry capability with time-out budget and variable jitter (interval) between retries
3. Limit the number of concurrent connections and upstream service requests
4. Proactively (periodically) run health checks on each member of the load balancing pool
5. Fine-grained fuse (passive health check) – applies to each instance in the load balancing pool

These functions can be dynamically configured at run time using Istio’s traffic management rules.

For overloaded upstream services, jitter between retries greatly reduces the impact of retries, while timeout budgeting ensures that the caller service gets a response (success/failure) within a predictable time range.

The combination of active and passive health checks (4 and 5 above) minimizes the opportunity to access unhealthy instances in the load balancing pool. When combined with platformer level health checks (such as those supported by Kubernetes or Mesos), it ensures that applications quickly remove unhealthy pods/containers/virtual machines from the service grid, minimizing the impact of request failures and latency.

Together, these capabilities enable the service grid to tolerate failed nodes and prevent local failures from degrading the stability of other nodes.

fine-tuning

Istio’s traffic management rules allow o&M to set global default failover values for each service/version. However, a consumer of the service can also override the default values for timeout and retry through request level values provided by special HTTP headers. In an Envoy proxy implementation, the corresponding headers are x-enbith-upside-rq-timeout-ms and X-enbith-max-retries.

FAQ

Q:

Yes. Istio improves the reliability and availability of services in the grid. However, the application still needs to handle failures (errors) and take appropriate fallback actions. For example, an Envoy returns HTTP 503 when all instances in the load balancing pool fail. It is the responsibility of the application to implement the necessary logic to respond appropriately to such HTTP 503 errors from the upstream service.

Q:

Don’t. Envoy is completely transparent to the application. Failure responses returned by envoys are not distinguished from failure responses returned by upstream services when a service call is made.

Q:

Given two failover policies for the same destination service (for example, two timeout Settings – one in the Envoy and one in the application library), both restrictions will be triggered when a failure occurs. For example, if an application sets a 5-second timeout for API calls to the service, and operations sets a 10-second timeout, the application’s timeout will start first. Similarly, if Envoy’s fuse fires before applying the fuse, API calls to the service will receive 503 errors from Envoy.

Fault injection

Although Envoy Sidecar/Proxy provides a number of failover mechanisms for services running on Istio, it is still necessary to test the end-to-end failover capability of the entire application. Misconfigured failover policies (for example, incompatible/restrictive timeouts across service invocations) can disrupt the user experience by causing critical services in the application to remain unavailable.

Istio can inject protocol-specific failures into the network, creating latency or corruption of packets at the TCP layer, without killing pods. Our reasoning is that no matter what the network-level failure is, the failure is observed at the application layer the same, and more meaningful failures (for example, HTTP error codes) can be injected at the application layer to verify and improve application resiliency.

Operations personnel can configure failures for requests that meet certain conditions, and they can further limit the percentage of requests that suffer failures. Two types of faults can be injected: delay and interrupt. Latency is a timing failure that simulates a rise in network latency or an overload of upstream services. An interruption is a simulated crash failure of an upstream service. Interrupts are usually in the form of HTTP error codes or TCP connection failures.

For more information, see Istio’s Traffic Management Rules.

Rule configuration

Istio provides a simple configuration model for controlling API calls and four layers of communication between multiple services within an application deployment. Operations personnel can use this model to configure service-level properties such as circuit breakers, timeouts, retries, and common continuous release tasks such as Canary release, A/B testing, and percentage traffic control to progressively release applications.

For example, the need to send 100% of incoming traffic to the Reviews service to version V1 can be implemented with the following rule:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1Copy the code

The idea behind this configuration is that traffic to the Reviews service (identified in the host field) should be routed to the V1 subset of the Reviews service instance. A subset in a route defines a predefined subset name that comes from the target rule configuration:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2Copy the code

The subset specifies one or more labels that can be used to distinguish instances of different versions. Assume that there is a service in the Istio service grid on Kubernetes where version:v1 means that only pods with “version:v1” in their tags will receive traffic.

Rules can be configured using the Istioctl client tool, or kubectl for Kubernetes deployment, but only istioctl checks the model during this process, so istioctl is recommended. Configuration examples are included in the Configuration request routing task.

Istio contains four types of traffic management configuration resources: VirtualService, DestinationRule, ServiceEntry, and Gateway. Here are some highlights of these resources. More information on this can be found in web References.

Virtual Service

How are requests for services routed within the Istio service grid? VirtualService contains this definition. For example, a Virtual Service can route requests to different versions, or even to a completely different Service than the one requested. Routing can be determined by a number of criteria, such as the source and destination of the request, the HTTP path and Header, and the weight of each service version.

The objective description of the rule

Routing rules correspond to one or more request destination hosts specified with the VirtualService configuration. These hosts may or may not be actual target loads or even routable services within the same grid. For example, to define routing rules for requests to the Reviews service, you can use either the internal name reviews or the domain name bookinfo.com. VirtualService can define a host field like this:

hosts:
  - reviews
  - bookinfo.comCopy the code

The host field defines one or more fully qualified names (FQDN) either explicitly or implicitly. The above reviews implicitly extend to a specific FQDN, for example in Kubernetes, Full name from its VirtualService cluster and inherited in the namespace (such as reviews. Default. SVC. Cluster. The local).

Split traffic between services

Each routing rule needs to identify one or more weighted backends and invoke the appropriate one. Each backend corresponds to a specific version of the target service, which is identified by the label. If a service version contains multiple registered instances, routes are routed based on the load balancing policy defined for the service. The default policy is round-robin.

For example, the following rule allocates 25% of reviews service traffic to v2 tags; The remaining 75% of traffic is allocated to V1:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
        weight: 75
    - destination:
        host: reviews
        subset: v2
        weight: 25Copy the code

Timeout and retry

By default, the timeout for HTTP requests is set to 15 seconds. Routing rules can override this limitation:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
    - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    timeout: 10sCopy the code

Routing rules can also be used to specify the number of retries for certain HTTP requests. The following code can be used to set the maximum number of retries, or to keep retrying for a specified period of time, which can also be overridden:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
    - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    retries:
        attempts: 3
        perTryTimeout: 2sCopy the code

Note that request retry and timeout can also be set individually for each request.

An example of timeout control is shown in the request timeout task.

Fault injection

You can inject one or more errors when forwarding HTTP requests to selected targets based on routing rules. The error can be either a delay or an exit.

The following example injects a 5-second delay on 10% of the traffic targeted for ratings: V1 service.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percent: 10
        fixedDelay: 5s
    route:
    - destination:
        host: ratings
        subset: v1Copy the code

Next, inject HTTP 400 errors into 10% of the traffic targeted for the Ratings :v1 service.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      abort:
        percent: 10
        httpStatus: 400
    route:
    - destination:
        host: ratings
        subset: v1Copy the code

Sometimes delay and exit are used together. For example, the following rule applies to traffic from Reviews :v2 to Ratings :v1 and delays all requests by 5 seconds, then discards 10% of them:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - sourceLabels:
        app: reviews
        version: v2
    fault:
        delay:
        fixedDelay: 5s
        abort:
        percent: 10
        httpStatus: 400
    route:
    - destination:
        host: ratings
        subset: v1Copy the code

See the error injection task for a hands-on look at this.

Condition rule

You can optionally make the rule apply only to requests that meet certain requirements:

1. Use workload labels to restrict specific client workloads. For example, a rule can indicate that it applies only to calls to workloads (PODS) that implement the Reviews service:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
      sourceLabels:
        app: reviews
    .Copy the code

The value of sourceLabels depends on the implementation of the service. For example, in Kubernetes, it might be the same label used in the POD selector of the corresponding Kubernetes service.

The above example can be further refined to a call only for Reviews service version v2:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - sourceLabels:
        app: reviews
        version: v2
    .Copy the code

2. Select a rule based on the HTTP Header. The following rule applies only to requests from a source containing an end-user header with a value of Jason:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    .Copy the code

If multiple headers are specified in a rule, all corresponding headers must match before the rule can be applied.

3. Select a rule based on the request URI. For example, if the URI path begins with/API /v1, the following rule applies only to requests:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: productpage
spec:
  hosts:
    - productpage
  http:
  - match:
    - uri:
        prefix: /api/v1
    .Copy the code

Multiple matching condition

You can set multiple matching conditions at the same time. In this case, the AND OR OR semantics are applied, depending on nesting.

If multiple conditions are nested in a single matching clause, the condition is AND. For example, the following rule only applies if the client workload is Reviews :v2 and the request contains Jason’s custom end-user header:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - sourceLabels:
        app: reviews
        version: v2
        headers:
        end-user:
          exact: jason
    .Copy the code

Conversely, if the condition occurs in a separate matching clause, only one of the conditions (OR semantics) applies:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - sourceLabels:
        app: reviews
        version: v2
    - headers:
        end-user:
          exact: jason
    .Copy the code

This rule applies if the client workload is Reviews :v2, or if the request contains Jason’s custom end-user header.

priority

When there are multiple rules for the same destination, they are applied in the order they were applied in VirtualService; in other words, the first rule in the list has the highest priority.

Why prioritization matters: When routing to a service is completely weighted, it can be done in a single rule. On the other hand, if there are multiple conditions (such as requests from a particular user) for routing, more than one rule will be required. This raises the issue of priority, which is needed to ensure that rules are executed in the correct order.

A common routing mode is to provide one or more high-priority rules. These rules use the source service and Header to determine routes, and then provide a single rule based on weight. These low-priority rules do not set matching rules, but only distribute all remaining traffic based on the weight.

For example, the following VirtualService contains two rules: All requests to the Reviews service, if the Header contains Foo=bar, will be routed to the v2 instance, while other requests will be sent to v1:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        Foo:
          exact: bar
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1Copy the code

Note that header-based rules have a higher priority. If you lower its priority, this rule will not take effect because the unrestricted weight rules will be executed first, meaning that all requests will be routed to v1 even if they contain the qualified Foo header. When traffic characteristics are judged to meet the conditions of a rule, the rule selection process ends. This is why you need to carefully consider the priority of multiple rules.

Target rules

After the request is routed by VirtualService, the set of policies configured by DestinationRule take effect. These policies are written by service owners and include configurations of circuit breakers, load balancers, and TLS.

DestinationRule also defines a routable subset (such as a named version) for the target host. VirtualService uses these subsets when sending requests to a particular service version.

Here are the DestinationRule configuration policies and subsets of the Reviews service:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
  - name: v3
    labels:
      version: v3Copy the code

Note that multiple policies (such as default and V2) can be included ina single DestinationRule configuration.

The circuit breaker

A simple circuit breaker can be defined using a number of standards, such as connection number and request number limits.

For example, the following DestinationRule places a 100 connection limit on the v1 version of the Reviews service:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100Copy the code

Rule evaluation

Similar to routing rules, the policy defined in DestinationRule is also associated with a specific host. If a subset is specified, the decision of the specific subset that takes effect is determined by routing rules.

The first step in rule evaluation is to determine the routing rule (if any) for the requested host in VirtualService. This step determines which subset (or version) of the target service the request is sent to. Next, the selected subset, if it defines a policy, begins an evaluation of whether it works.

Note: This algorithm needs to be careful that a subset defined for a certain subset takes effect only when that subset is explicitly routed. For example, the following configuration defines rules only for the Review service (there is no corresponding VirtualService routing rule).

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100Copy the code

Since no routing rules are defined for the Reviews service, the default round-robin policy is used, occasionally requesting v1 instances, and if there is only one v1 instance, all requests are sent to it. However, the preceding policy will never take effect because the default route is performed at a lower level, and the policy engine cannot know the ultimate goal or select a matching subset policy for a request.

There are two ways to solve this problem. You can raise the routing policy one level and require it to take effect for all versions:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
  subsets:
  - name: v1
    labels:
      version: v1Copy the code

A better approach is to define routing rules for the service, such as adding a simple routing rule to Reviews :v1:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1Copy the code

Istio can send traffic from all sources to all versions of the target service without defining any rules. However, once you need to differentiate between versions, you need to set rules. Setting default rules for each service from the beginning is a recommended best practice in the Istio world.

Service Entry

Istio maintains an internal registry of services to which additional entries can be added using ServiceEntry. This object is typically used to enable requests to services outside the Istio service grid. For example, ServiceEntry can be used to allow external calls to the service host on the *.foo.com domain.

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: foo-ext-svc
spec:
  hosts:
  - *.foo.com
    ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: https
    protocol: HTTPSCopy the code

ServiceEntry uses the hosts field to specify the target, which can be a fully qualified name or a wildcard domain name. It contains a whitelist that contains one or more services that are accessible to services in the grid.

The configuration of ServiceEntry is not limited to external services, it comes in two types: inside the grid and outside the grid. Entries in the grid are similar to other internal services and are used to explicitly add services to the grid. Can be used to add services to unmanaged infrastructure Settings (such as virtual machines in kubernetes-based service grids) as part of a service grid extension. Net extra entries are used to express net extra services. For such entries, two-way TLS authentication is disabled and policy implementation needs to be performed on the client side rather than the server side like internal service requests.

As long as ServiceEntry involves services that match host, it can work with VirtualService and DestinationRule. For example, the following rule can be used in conjunction with ServiceEntry above to set a 10 second timeout when accessing external services at bar.foo.com.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bar-foo-ext-svc
spec:
  hosts:
    - bar.foo.com
  http:
  - route:
    - destination:
        host: bar.foo.com
    timeout: 10sCopy the code

The redirection and forwarding of traffic, defining retry and timeout, and error injection policies all support external targets. However, because external services do not have the concept of multiple versions, weighted (version-based) routing cannot be implemented.

See the egress task to learn more about accessing external services.

Gateway

The Gateway configates a load balancer for HTTP/TCP traffic, mostly at the edge of the grid, to enable ingress traffic for a service.

Unlike Kubernetes Ingress, Istio Gateway only configures layer 4 to layer 6 functions (such as open ports or TLS configurations). By binding a VirtualService to the Gateway, users can control incoming HTTP and TCP traffic using standard Istio rules.

For example, the following provides a simple Gateway code with a load balancer that allows external HTTPS traffic to the host bookinfo.com:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - bookinfo.com
    tls:
      mode: SIMPLE
      serverCertificate: /tmp/tls.crt
      privateKey: /tmp/tls.keyCopy the code

To configure a route for a Gateway, you must define a VirtualService whose host is also defined. The Gateways field is used to bind the routes to the Gateway.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
    - bookinfo.com
  gateways:
  - bookinfo-gateway # <---- bind to the Gateway
  http:
  - match:
    - uri:
        prefix: /reviews
    route:
    .Copy the code

There is a complete Ingress Gateway example in the Ingress task.

Although the Gateway is primarily used to manage Ingress traffic, it can also be used purely between internal services or in Egress scenarios. All gateways can be configured and controlled the same way, regardless of their location. More details are described in the Gateway reference.