concept VirtualService in category istio

This is an excerpt from Manning's book Istio in Action MEAP V09. Login to get full access to this book.

Istio’s configuration resources are implemented as Kubernetes Custom Resource when running on Kubernetes. Custom Resource Definitions (CRDs) are used to extend the native Kubernetes API to add new functionality to a Kubernetes cluster without having to modify any Kubernetes code. In the case of Istio, we can use Istio’s CRs to add Istio functionality to a Kubernetes cluster and use native Kubernetes tools to apply/create/delete the resources. Istio implements a controller that watches for these new CRs to be added and reacts to them accordingly. For example, when we create the VirtualService CR from above, Istio recognizes this as an Istio configuration object and translates this into Envoy’s native xDS protocol and configuration format.

Istio translates Istio-specific configuration objects, like the VirtualService we saw in the previous listing, and translates it into Envoy’s native configuration. Istiod will expose this configuration intent to the service proxies as Envoy configuration through its data-plane API like this:

Listing 2.9. Example Istio configuration resource for controlling traffic routing

"domains": [
        "catalog.prod.svc.cluster.local"
    ],
"name": "catalog.prod.svc.cluster.local:80",
"routes": [
        {
            "match": {
                    "headers": [
                        {
                                "name": "x-dark-lauch",
                                "value": "v2"
                            }
                        ],
                    "prefix": "/"
                },
            "route": {
                    "cluster": "outbound|80|v2|catalog.prod.svc.cluster.local",
                    "use_websocket": false
                }
            },
        {

            "match": {
                    "prefix": "/"
                },
            "route": {
                    "cluster": "outbound|80|v1|catalog.prod.svc.cluster.local",
                    "use_websocket": false
                }
            }
    ]

This data-plane API exposed by Istiod implements Envoy’s "discovery APIs". These discovery APIs, like those for service discovery (Listener Discovery Service - LDS), endpoints (Endpoint Discovery Service - EDS), or routing rules (Route Discovery Service - RDS) are known as the xDS APIs. These APIs allow the data plane to separate how it gets configured and dynamically adapt its behavior without having to stop and reload. We’ll cover more of these xDS APIs from the perspective of Envoy proxy in Chapter 3.

To configure Istio’s Gateway to allow traffic into the cluster and through the service mesh, we’ll start by exploring two concepts: Gateway and VirtualService. Both are fundamental in general to getting traffic to flow in Istio, but we’ll look at them only within the context of allowing traffic into the cluster. We will cover VirtualService more fully in the next chapter about traffic management and routing.

So far, all we’ve done is configured the Istio Gateway to expose a specific port, expect a specific protocol on that port, and define specific hosts to serve from the port/protocol pair. When traffic comes into the gateway, we need a way to get it to a specific service within the service mesh and to do that, we’ll use the VirtualService resource. In Istio, a VirtualService resource defines how a client talks to a specific service through its fully qualified domain name, which versions of a service are available, and other routing properties (like retries and request timeouts). We’ll cover VirtualService in more depth in the next chapter when we explore traffic routing more deeply, but in this chapter it’s sufficient to know that VirtualService allows us to route traffic from the ingress gateway to a specific service.

An example of a VirtualService that routes traffic for the virtual host apigateway.istioinaction.io to services deployed in our service mesh looks like this:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: apigateway-vs-from-gw #1
spec:
  hosts:
  - "apiserver.istioinaction.io" #2
  gateways:
  - coolstore-gateway #3
  http:
  - route:
    - destination: #4
        host: apigateway
        port:
          number: 8080

With this VirtualService resource, we define what to do with traffic when it comes into the gateway. In this case, as you can see with spec.gateways field, these traffic rules apply only to traffic coming from the coolstore-gateway gateway definition which we created in the previous section. Additionally, we’re specifying a virtual host of apiserver.istioinaction.io for which traffic must be destined for these rules to match. An example of matching this rule is a client querying apiserver.istioinaction.io which resolves to an IP that the Istio gateway is listening on. Additionally, a client could explicitly set the Host header in the HTTP request to be apiserver.istioinaction.io which we’ll show through an example.