Skip to main content

Set up Signadot Operator in Kubernetes

Introduction​

In this guide, we will walk you through the process of installing Signadot into your Kubernetes cluster. We will also cover how to configure request routing and address other infrastructure concerns. By the end of this guide, you will have a fully configured Signadot setup, ready for creating sandboxes within your cluster. This will enable you to manage and control your sandboxes directly from your cluster, ensuring a seamless and efficient workflow.

Install Signadot Operator into your cluster​

To get started with Signadot, you first need to install the Signadot Operator into your cluster. This will allow you to manage and control your sandboxes directly from your cluster.

To install Signadot into your cluster, you will need to use Helm. If you haven't installed Helm yet, you can find the installation instructions here.

Before you can install Signadot, you need to generate a cluster token. This token is used to authenticate your Kubernetes cluster with Signadot. To generate a cluster token, you need to create an account on Signadot Dashboard. Once you have an account, navigate to Clusters > Connect Cluster, and then supply a name that identifies the cluster you are connecting. After creating the connection, the dashboard will present you with installation instructions that include your cluster token.

For more detailed instructions on how to install the Signadot Operator, please refer to our Getting Started: Installation Guide.

While installing, one of the key considerations is how you will set up routing for sandboxes. See the next section for more details on the different ways and considerations when setting up Sandbox routing.

Set up Sandbox Routing​

Using Istio​

If your application is running in an Istio mesh, you can enable sandbox routing using Istio by setting the istio.enabled helm value to true during the installation of the operator. This will cause the Signadot Operator to manage routes in the Istio VirtualService for each service that is opted into Signadot.

When using Istio for sandbox routing, it is important to note that each baseline microservice or "workload" that will be tested using Signadot must have an associated VirtualService. This is because Signadot sets routing rules on these VirtualServices to direct traffic to the appropriate sandboxes as needed.

Signadot mutates VirtualServices within the cluster to manage these routing rules. This means that if you have a GitOps based system that overwrites VirtualServices, you will need to configure it to ignore the changes made by Signadot.

For more detailed instructions on how to set up sandbox routing using Istio, please refer to our Using Istio Guide.

Using DevMesh​

If your application is not running in a service mesh like Istio, you can set up sandbox routing using Signadot's DevMesh. DevMesh is a system of envoy-based sidecars that are built into the Signadot Operator and offer lightweight request routing functionality.

To enable DevMesh, you need to opt each service into Signadot DevMesh injection. This can be done by adding an annotation to each pod. If for example, the pods are created by a deployment, the annotation can be added to the deployment template.

For more detailed instructions on how to set up sandbox routing using Signadot's DevMesh, please refer to our Using the Signadot DevMesh Guide.

Verifying the Setup​

Firstly, you should check from the Signadot dashboard that the cluster has successfully connected and is healthy. This verifies that the operator installation has been successful.

Secondly if you are using DevMesh for routing, to verify that the sandbox routing is set up correctly, you should check that the pods associated with your baseline deployments or workloads are now running an extra container, called the sd-sidecar.

To test the setup, you can use a simple sandbox specification such as the following on any of the baseline workloads for which you're setting up sandboxes.

name: test-sandbox-routing
spec:
  description: Test Sandbox Routing
  cluster: "@{cluster}"
  forks:
    - forkOf:
        kind: Deployment
        namespace: "@{namespace}"
        name: "@{name}"

Click the button below to open and run this spec on Create Sandbox UI.

Once the sandbox created above reaches a healthy state, this signifies the successful completion of the setup.