Skip to main content

How it works

Signadot is used to create and manage Sandbox Environments within Kubernetes clusters. Sandbox Environments are test environments that are as close as possible to production, and inexpensive to create and manage at scale. The scalability of these Sandbox Environments enables them to shift left a lot of testing that previously was only possible much later in the development lifecycle.

Traditional integration or staging environments are independent copies of the entire microservices stack. With increasing numbers of microservices, it becomes difficult to create and manage multiple copies of these environments without incurring significant infrastructure costs and maintenance burdens.

Sandbox Environments make use of the fact that when a new environment is created, only a few services have changed and the other service dependencies remain unchanged. Service dependencies can be satisfied from a shared pool of services corresponding to the latest stable version. This shared pool of services is called the baseline and is continuously updated to run the latest code that corresponds to the main or master branch. This method of leveraging a shared baseline enables a scalable way to create high-fidelity environments that spin up in seconds and are always up to date.

Platform Components

The Signadot platform consists of two high-level components - a control plane that is hosted by Signadot, and a Kubernetes Operator that installs into your Kubernetes cluster.

This Kubernetes cluster that Signadot installs into is running the entire application stack, with all microservices and external cloud services, which we referred to in the previous section as the baseline.

Once installed into the cluster and connected with the control plane, you can use Signadot's APIs, SDKs or CLI to spin up and manage Sandbox Environments inside the Kubernetes cluster. These Sandbox Environments live within the Kubernetes cluster, and you can access them via authenticated Sandbox URLs. Refer to the section on architecture for more details.

Creating Sandboxes

You use the CLI, SDK or API to create and manage Sandboxes. The Signadot Control Plane communicates with the Signadot Operator to create Sandboxes in the specified cluster.

Accessing Sandboxes

Sandbox URLs are created and hosted by Signadot to access services running in Sandboxes. Requests made to these URLs are routed to your cluster via the secure tunnel established by the Operator. These Sandbox URLs offer several benefits over traditional methods of accessing services within Kubernetes:

  • These URLs automatically add the headers used to dynamically route requests to services in Sandboxes as described in Request Routing.
  • It enables access to internal services without exposing any ports to the internet or requiring new ingress/egress rules.
  • As an identity-aware proxy, it allows authenticated access to your sandboxed workloads securely without a VPN or port-forwarding.
  • Sandboxes are immediately accessible as soon as they're created, without having to configure any new infrastructure such as DNS, TLS certificates, or load balancers.

Sandbox Environments & Isolation

For an environment to be effective and useful, isolation is a critical need. To isolate requests to your service under test from other services, Sandboxes use request tenancy and request routing. For data isolation, Sandboxes use resource plugins to create ephemeral resources tied to their lifecycle. Using these mechanisms, Sandbox Environments can be completely isolated from one another, and the baseline environment.