Architecture

Kardinal deploys a service into your cluster called the Kardinal Manager, which is responsible for reading your Kubernetes annotations and managing Istio to implement routing rules per request.

Kardinal uses the existing distributed tracing infrastucture in your application to keep track of requests as they trace their way through the cluster.

To manage any persisted state in your cluster, Kardinal relies on a plugin ecosystem that define, service-by-service, how to properly share state between environments, or how to spin up new, empty "dev" versions of given stateful services.

There are two kinds of plugins:

Stateful service plugins

Define state access modes for stateful services that are deployed and managed via Kubernetes, like a Postgres database.

External service plugins

Define state access modes for external services that are not managed by Kubernetes, like Stripe or Twilio.

These plugins can be installed with Kardinal, enabling you to properly configure your flows to maximally reuse any persisted state in your application across development workflows, allocating new development instances of stateful services whenever necessary.

In order to visualize your cluster, and to support management of multi-user use cases, Kardinal uses a control plane which the Kardinal Manager connects to. The control plane receives your service dependency graph and uses it to display your cluster visually. For now, the control plane is hosted on our cloud, but we're working on making it available on-premise as well.