What is Gloo?
Gloo is a feature-rich, Kubernetes-native ingress controller, and next-generation API gateway. Gloo is exceptional in its function-level routing; its support for legacy apps, microservices and serverless; its discovery capabilities; its numerous features; and its tight integration with leading open-source projects. Gloo is uniquely designed to support hybrid applications, in which multiple technologies, architectures, protocols, and clouds can coexist.
Gloo Gateway is capable of routing incoming requests by running Virtual Services that contain routing rules pointing to Upstream destinations. When a service is deployed on Kubernetes, Gloo's Discovery system can automatically find the service and create an Upstream Custom Resource Definition for it.
The purpose of this scenario is to learn more about Gloo Upstreams, Virtual Services, and the process of connecting Kubernetes services to the Gloo Gateway. By the end of this scenario, you will have a rudimentary understanding of how to configure Gloo using the
glooctl command line utility, how a Gloo Virtual Service can route requests to an Upstream destination, and how a Gloo Virtual Service can balance requests against multiple Upstreams for canary testing.
In the Gloo Gateway - Canary scenario, you will start with a Kubernetes cluster that already has Tiller, Gloo, and Gloo Enterprise installed on the cluster. The tools
glooctl are also preinstalled.
kubectl is used to manage Kubernetes clusters, and
glooctl is used to manage the Gloo installation. YAML files have also been copied to the home directory for use in the scenario. These include two versions of the Pet Store sample application and an updated version of the Virtual Service to demonstrate the weighted routing capabilities of Gloo Gateway.
Within the provisioned Kubernetes cluster, you will deploy the Pet Store application and validate that it is running.
Then you will validate that Gloo has automatically created an Upstream for the service that is part of the Pet Store application.
Next you will create a Virtual Service and add a route sending traffic to a specific path on the Pet Store Upstream based on incoming web requests, and validate the route using
Once the first version of the Pet Store application is running, you will deploy a second version of the application, validate it is running, and add a second route to the Virtual Service for this new version of the application.
Next you will test the new route rule to demonstrate that the new Pet Store application is accessible using a header entry.
Finally, you will update the Virtual Service to use weighted routing, distributing the traffic between the two versions of the Pet Store application.
Gloo Gateway - Canary
Please wait until setup completes ...