Request Routing

Overview

Request routing refers to the ability to redirect requests coming into a given service to an alternative destination, such as a sandbox fork of the service, based on metadata contained within that particular request. This allows each sandbox to selectively replace only some services in the stack with forks, so you can test unmerged changes without having to launch a copy of every service in the chain.

The necessary sandbox metadata for routing is automatically added to all requests that reach your services through a endpoint. If you additionally set up context propagation within each service, request routing can take effect not only for that initial request, but also for any subsequent service-to-service requests in the chain.

Intercepting Requests

The key to request routing is the ability to intercept requests that would normally go to a particular service. The requests can then be examined for sandbox metadata and either redirected to a fork of the service or passed through to the baseline service. Signadot uses network-level mechanisms to intercept incoming connections before they even reach the baseline service.

One such mechanism is to configure Signadot Operator to inject an init container and a sidecar container into the baseline Deployment. The init container uses iptables to forward incoming connections meant for your own container to the Signadot sidecar container instead. The Signadot sidecar will then act as a L7 HTTP or gRPC proxy that examines requests for sandbox metadata and decides whether to route them to a fork or pass them through to the main container.

If you already have a supported service mesh like Istio, that mesh already does its own interception of connections and offers configuration options to achieve request routing. In this case, Signadot Operator configures the service mesh to route requests that contain sandbox metadata to the intended fork.

Setting up Routing

Using Signadot Sidecar

If your app is not running in Istio, you can enable Sandbox routing by opting each service into Signadot sidecar injection. This can be done by adding an annotation to the Pod template of each service's Deployment as shown below.

apiVersion: apps/v1
kind: Deployment
metadata:
  ...
spec:
  template:
    metadata:
      annotations:
        # Set the value to "http" or "grpc" based on
        # the protocol that this service uses.
        sidecar.signadot.com/inject: http

In order to add the inject annotation to a particular deployment, you can run the following kubectl command.

kubectl -n <namespace> patch deployment <deployment-name> -p '{
   "spec":{
      "template":{
         "metadata":{
            "annotations":{
               "sidecar.signadot.com/inject": "http"
            }
         }
      }
   }
}'

If Signadot is already installed in the cluster, the Pods will have a proxy sidecar container injected, which will perform Sandbox routing based on metadata in each request.

Using Istio

If your app is running in an Istio mesh, the only requirement to enable sandbox routing is that each Service has a matching VirtualService in the same namespace. If you don't already have a VirtualService defined, you just need to create a basic one with a default route. For example, here is a basic VirtualService for a Service called my-svc in namespace ns-1:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-svc
  namespace: ns-1
spec:
  hosts:
  - my-svc.ns-1.svc.cluster.local
  http:
  - name: default
    route:
    - destination:
        host: my-svc.ns-1.svc.cluster.local

Signadot will then add and remove routes in the VirtualService as needed to configure sandbox routing.

Using Linkerd

info

Linkerd Integration is Coming Soon!