Skip to main content

Setting up Dynamic Routing


If Services have the capability to propagate request headers from incoming to outgoing requests, Signadot can dynamically route requests to specific versions of Services in Sandboxes. These headers are automatically set on requests that go through Signadot Endpoint URLs.

You would need to opt-in each service to Signadot sandbox routing. Routing ensures that requests made to Endpoint URLs reach the customized versions of Services in Sandboxes.

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
# Set the value to "http" or "grpc" based on
# the protocol that this service uses. http

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

kubectl -n <namespace> patch deployment <deployment-name> -p '{
"": "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.

Setting up routing 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:

kind: VirtualService
name: my-svc
namespace: ns-1
- my-svc.ns-1.svc.cluster.local
- name: default
- 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.

Setting up routing using Linkerd


Linkerd Integration is Coming Soon!