In this installment of 5 minutes with Gloo, I’ll introduce you to the concept of a VirtualService. Understanding what a Gloo VirtualService is, and its role in traffic management, is crucial to making proper use of Gloo, the Next-Gen API Gateway.
What is a Virtual Service?
The VirtualService contains information to respond to three questions mainly:
From a technical standpoint, a virtual service is a logical aggregation of address matching rules and security & traffic management policies associated with a collection of services or endpoints. It is your Virtual API.
The rules are applied to one or many instances of Solo’s distribution of the Envoy proxy through xDS. In short, xDS means the multiple Discovery Service APIs available on Envoy. This post by Matt Klein gives an overview of the Envoy APIs and their history.
The storage component in Gloo was built to be pluggable and with that, Gloo supports storing configuration in different mechanisms such as etcd, Consul, Vault, and others. If you are using Kuberentes, VirtualServices are stored as CRDs in an etcd repository.
The Anatomy of a VirtualService
Digging into more of the capabilities of virtual services, the list of features is extensive, see the infographic below for the anatomy of a VirtualService:
The Gloo VirtualService is not to be confused with the IstioVirtual Service. Even though they may share some characteristics, such as defining a destination, the Gloo VirtualService serves as a cluster ingress technology whereas the Istio VirtualService takes action once traffic has already reached a known service-mesh service.
A better parallel would be to place the Istio Gateway and the Gloo Gateway in the same category, given both control traffic ingress. The similarities with the Istio Gateway stop there though. Gloo can perform advanced traffic manipulation such as content transformation and has broader addressing capabilities, with function-based routing, among other things.