Skip to main content

Signadot Operator

Overview​

The Signadot Operator is the in-cluster component of the Signadot Platform. To see a high-level view of all components, visit the architecture page.

The operator is installed into the Kubernetes cluster using Helm into the signadot namespace. Once authorized, it connects and maintains a persistent connection with the Signadot Control Plane.

It provides the following functionality:

  1. Creating and managing workloads (Kubernetes Deployments, Rollouts, etc) associated with a Sandbox.
  2. Creating and managing resources associated with Sandboxes.
  3. Managing routing for requests between services within the cluster.

Agent​

The agent is a deployment which maintains a secure persistent connection to the Signadot Control Plane at tunnel.signadot.com:443. This connection is used to:

  1. Provide access to the Kubernetes API to the Signadot Control Plane.
  2. Proxy requests from Endpoint URLs to services within the cluster, including performing in-cluster DNS resolution.

Since the agent provides access to the cluster Kubernetes API server, it tends to have scaled down read-only permissions for resources not owned by Signadot, and read-write permissions for Signadot owned objects. You can learn more about the permissions that are requested by the agent here.

Controller Manager​

The controller manager implements Kubernetes controllers for various Signadot CRDs, including

  1. Sandboxes (sds)
  2. Resources (sdmr)
  3. Signadot Object Lifecycle Methods (solm)
  4. Signadot Routes (sdr)
  5. Signadot Route Groups (sdrg)

Additionally, the controller manager implements controllers for CRDs not owned by Signadot in specific cases when routing is managed by a service mesh. For example, the Signadot Operator makes use of VirtualServices for request routing if you are running Istio. The controller-manager needs read-write permissions for any resources which are manipulated on behalf of sandboxes. You can learn more about the permissions that are requested by the controller manager here.

Sandbox CRD & Controller​

The sandbox CRD is a low-level implementation of the Signadot Sandbox specification. The controller for a Sandbox performs all the important actions associated with creating a Sandbox such as:

  1. Creating new workloads (and associated Kubernetes Services) according to the Sandbox specification.
  2. Coordinating the addition and removal of Signadot Routes
  3. Creating and finalizing sandbox resources

Resource CRDs & Controllers​

A Resource CRD represents the state of a resource associated with a sandbox. Controlling a resource entails making it available to sandboxed workloads according to the associated resource plugin spec, and deleting the resource when the associated sandbox is terminated.

The Object Lifecycle Methods CRD is a low-level implementation of a workflow manager attached to the lifecycle of a target object. In the context of Resources, its controller is responsible for the execution of the defined workflows for the create and delete phases.

Signadot Route CRD & Controller​

In the Sandboxes and RouteGroups models, each request is tagged with specific headers that control the route taken by the request within the cluster. The Signadot Route CRD is a representation of these routing rules within the cluster.

When operating on a cluster with a service mesh installed, the Route Controller may in turn modify a CRD like Istio's VirtualService in order to realize the effect of the routing rule. When using Signadot Sidecars for in-cluster routing, the Route Server component is updated corresponding to the specified Route.

Signadot RouteGroup CRD & Controller​

A RouteGroup CRD represents a set of sandboxed workloads under a single routing context. The sandboxed workloads may belong to different sandboxes. As such, a RouteGroup CRD represents a way to route requests to a set of sandboxes. The RouteGroup controller creates Signadot Route Objects and coordinates RouteGroup status with the constituent Sandboxes.

Route Server​

The route server is a Kubernetes Deployment that is tasked with keeping track of where to route requests provided the destination address and associated sandbox. It is intended for internal Signadot use only, and serves an HTTP API for use by Signadot sidecars. For performance reasons, the route server is not intended to intervene on every request. Rather, it expects its clients to cache the results periodically.

Signadot Sidecar​

The Signadot Operator also contains optional functionality to add an annotation to inject sidecars into baseline workloads. The injection occurs into pods using a Kubernetes Mutating webhook. The sidecar automatically integrates with the Route Server and provides dynamic request routing capabilities in a cluster that does not have a Service Mesh installed.

IO Context Server​

The io context server (aka ICS) is a Kubernetes Deployment responsible for storing and serving intermediate results produced by the execution of the work units defined within a Signadot Object Lifecycle Methods workflow. In simple words, whenever a Resource is being created or deleted, a workflow of work units is executed. Each of those work units may produce outputs, which will be stored in ICS. Apart from that, work units may also consume inputs from other work units, those inputs will be read from ICS and injected into the work unit main container.

IO Init Container​

The io init container, is an init container that is appended to the work unit pods. It is responsible for reading the required inputs from ICS and injecting them into the main container.

IO Sidecar Container​

The io sidecar container, is a container that run along side with the main container, whose purpose is to collect the generated outputs from the work unit and store them in ICS.