Architecture
Architectural decisions and overview of the self-hosted management plane
Overview
The self-hosted management plane is intended to be deployed into a Kubernetes cluster managed by the customer or user. The following table shows the various components (some optional) of the entire management plane after deployment.
| Component | Description |
|---|---|
Cloud API / Management plane | The management plane that orchestrates the data plane and provides abstraction for metric server and config server. |
Metric server (InfluxDB) | The optional metric server where metrics are automatically stored. |
Config server (Postgres) | The helm chart deploys a local in-cluster non-HA deployment. We also support using any other managed Postgres. |
Frontend / UI | This is the component that includes the UI for Calyptia Core. |
Calyptia Core / Data Plane | The data plane that is installed within the same cluster, and can also exist in external environments as well. This is where the workloads run. |
A simple visualisation tool to provide access to logs, metrics and traces. Useful to debug workloads or similar. |
Single tenant
The self-hosted management plane provides no separate user authentication or project division like the hosted Calyptia versions. As such, it is intended to be deployed into a Kubernetes cluster with authentication and authorisation managed through Kubernetes mechanisms (for example, a custom Ingress).
Separate namespaces can be used to host different instances of the management plane and segregate that way but fundamentally the management plane is still single tenant rather than multiple tenancy. Ingress or other network forwarding would need to target the service in the right namespace.
The management plane stores state in a Postgres database so consideration around how this segregates data also needs to be carried out.
Workloads
Workloads can be run in the same cluster as the management plane or separate clusters as per the normal usage on the hosted Calyptia versions. Using the same cluster means no external network access is required as the workloads can talk direct to the control plane - it also means they may not have to go through any custom Ingress or other networking set up for user access.
Services
Every service in the cluster by default aims to follow the naming of the hosted version, (for example, the UI service is called core to match up with core.calyptia.comthat provides the hosted UI). They should be individually controlled by specific sections in the Helm values file.
Last updated