If you’re familiar with Gloo, you might be aware that Gloo already supports splitting traffic into multiple destinations, which is especially useful for Canary Deployments and A/B tests, and that’s great! If you’re new to Gloo, I recommend this post on the Anatomy of a Virtual Service.

In this latest release of Gloo (v0.13.7), we added a new feature called Upstream Groups. It is a top-level object, that, as the name says, allows you to logically group upstreams, giving you the ability to address them as a group in distinct VirtualServices. An upstream is the language we use to define something that will receive the traffic from Envoy, and it’s where you want your request to go ultimately.

Let’s consider the example below:

To briefly explain the example we have the following:

• cartService v3 and cartService v4 are different Upstreams that are used in multiple virtual Services.
• during a Canary Deployment, or A/B test, it’s possible that both inventoryService and orderService will interface with different versions of the cartService.

Before this new feature, if you needed to change routing logic for cartService (v3 and v4) you would need to either use a single virtualService, which could impact your ability to use different security policies; or use two virtual services, which would decrease the manageability of the solution.

The Advantages of a Higher Level Group

By logically grouping the different versions of the cartService, applications can refer to cartService as a single entity. With that, changes made to the high-level definition will now affect users of that group.

Great for Canary and A/B Tests

Consider now the scenario where the team responsible for the cartService wants to roll out a new version but not without performing some canary tests first.

By specifying the destination and destination weights at a top level, the cartService team can ensure that a percentage of traffic will be routed to the canary release regardless of who is making the request.

Example

Let’s define an UpstreamGroup:

apiVersion: gloo.solo.io/v1
kind: UpstreamGroup
metadata:
  name: test
  namespace: gloo-system
spec:
  destinations:
  - destination:
    upstream:
        name: dev-cartVOne
        namespace: gloo-system
    weight: 95
  - destination:
      upstream:
        name: dev-cartVTwo
        namespace: gloo-system
    weight: 5

And below we see a VirtualService using the UpstreamGroup defined above.

apiVersion: gateway.solo.io/v1
kind: VirtualService
metadata:
  name: vs
  namespace: gloo-system
spec:
  virtualHost:
    domains:
    - '*'
    name: default
    routes:
    - matcher:
        prefix: /
      routeAction:
        upstreamGroup:
          name: test
          namespace: gloo-system

Try it now

You can try this new feature with the Gloo right now. Get the latest glooctl release on https://github.com/solo-io/gloo and check the documentation for instructions on to Install Gloo on your preferred platform.