Static Upstreams

Let’s configure Gloo Edge to route to a single, static Upstream. In this case, we’ll route requests through Gloo Edge to the JSON testing API available at http://jsonplaceholder.typicode.com/.

When you create a static upstream resource that points to a Kubernetes service address, such as in the following example, Gloo Edge relies on kube-proxy to perform load balancing which might impact performance. To avoid performance impacts, you can use dynamic Upstreams or manually create upstream resources that use label selectors to find the backing destination.

apiVersion: gloo.solo.io/v1
kind: Upstream
metadata:
  name: httpbin-httpbin-static-8000
  namespace: gloo-deployments
spec:
  static:
    hosts:
      - addr: httpbin.httpbin.svc.cluster.local
        port: 8000

This guide assumes that you have deployed Gloo to the gloo-system namespace and that the glooctl command line utility is installed on your machine. glooctl provides several convenient functions to view, manipulate, and debug Gloo resources; in particular, it is worth mentioning the following command, which we will use each time we need to retrieve the URL of the Gloo Gateway that is running inside your cluster:

glooctl proxy url

Create Upstream

Let’s create a simple upstream for testing called json-upstream, that routes to a static site:


apiVersion: gloo.solo.io/v1
kind: Upstream
metadata:
  name: json-upstream
  namespace: gloo-system
spec:
  static:
    hosts:
      - addr: jsonplaceholder.typicode.com
        port: 80

glooctl create upstream static --static-hosts jsonplaceholder.typicode.com:80 --name json-upstream

Create Virtual Service

Now let’s create a virtual service that routes all requests to the foo domain to that upstream.


apiVersion: gateway.solo.io/v1
kind: VirtualService
metadata:
  name: test-static
  namespace: gloo-system
spec:
  virtualHost:
    domains:
      - 'foo'
    routes:
      - matchers:
         - prefix: /
        routeAction:
          single:
            upstream:
              name: json-upstream
              namespace: gloo-system
        options:
          autoHostRewrite: true

Test routes

Now we can verify that the proxy was updated to support routing to this upstream using curl:

curl -H "Host: foo" $(glooctl proxy url)/posts
[
  {
    "userId": 1,
    "id": 1,
    "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
    "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
  },
  {
    "userId": 1,
    "id": 2,
    "title": "qui est esse",
    "body": "est rerum tempore vitae\nsequi sint nihil reprehenderit dolor beatae ea dolores neque\nfugiat blanditiis voluptate porro vel nihil molestiae ut reiciendis\nqui aperiam non debitis possimus qui neque nisi nulla"
  },
  {
    "userId": 1,
    "id": 3,
    "title": "ea molestias quasi exercitationem repellat qui ipsa sit aut",
    "body": "et iusto sed quo iure\nvoluptatem occaecati omnis eligendi aut ad\nvoluptatem doloribus vel accusantium quis pariatur\nmolestiae porro eius odio et labore et velit aut"
  },
  ...
]

Summary

In this example, we created a static upstream and created a virtual service with a route to it. We showed using curl that the proxy was configured with this route.

Let’s cleanup the test upstream and virtual service we created:


kubectl delete vs -n gloo-system test-static
kubectl delete upstream -n gloo-system json-upstream

glooctl delete vs test-static
glooctl delete upstream json-upstream