Self hosting

Details on providing a self-hosted (on-premise) management plane

Overview

Calyptia provides a hosted management plane for Calyptia Core workloads through calyptia.com, and this is the recommended way to consume Calyptia Core. In this mode, only workloads need hosting locally to run.

For some customers and users it may be required to host their own versions of the management plane either completely offline or in a restricted network. This documentation will explain how to do so.

Installation

A Helm chart is provided to deploy the management plane on a Kubernetes cluster.

helm repo add calyptia https://helm.calyptia.com --force-update
helm repo update
helm upgrade --install --create-namespace --namespace "calyptia" --wait calyptia-cloud calyptia/calyptia-standalone

The default installation provides an out-of-the-box working management plane cluster but is not recommended for production as it does not provide a high-availability version of the Postgres database for all state and authentication information.

Refer to the configuration section for specific details to configure the management plane for your specific usage (for example, resource tuning and service configuration).

The helm chart documentation also provides details on configuration: https://github.com/calyptia/charts/tree/master/charts/calyptia-cloud-standalone

Helm provides a standard mechanism to configure through YAML, and supports YAML manifest generation or integration with other GitOps tools (such as ArgoCD or Flux).

Offline installation

For some customers, it is not possible to access any public networks for installation. For these customers, Calyptia can provide a packaged version of the Helm chart along with all supporting tooling and documentation to run on an isolated network.

Workloads

After the management plane has been deployed, you can use the following helm chart to deploy a Calyptia Core Instance (data plane or workloads) and attach it to our self-hosted management plane.

The key thing to ensure is that the api_url is set to the in-cluster endpoint so it does not use the default hosted cloud-api.calyptia.com endpoint.

helm repo add calyptia https://helm.calyptia.com --force-update
helm repo update
helm upgrade --install --namespace calyptia --create-namespace calyptia-core calyptia/core \
    --set project_token="$(kubectl get secret -n "calyptia" auth-secret -o jsonpath='{.data.ONPREM_CLOUD_API_PROJECT_TOKEN}'| base64 --decode)" \
    --set name=test --set core_instance_tags=test --set api_url="http://cloud-api.calyptia:5000" \
    --debug --wait

Similarly, using Calyptia CLI there are equivalent command line options to set the --cloud-url and the --core-cloud-url. The reason for two separate ones is whether the URL is external to the cluster or internal (for example, if you deploy workloads in a separate cluster, it can use the external --cloud-url parameter).

Production deployments

For production deployments, Calyptia recommends and supports the following:

• Separate highly available Postgres deployment.

• Separate Core Operator deployment.

The configuration for pipelines and everything else is held within the Postgres deployment. The default chart configuration deploys an in-cluster database purely to help with initial or development deployments.

Similarly, Core Operator is deployed by default as part of an initial deployment but in a production system it is better to separate the management plane (self-hosted) from the data plane (Core Operator). This will allow you to manage upgrades and the overall lifecycle of each plane separately as required.

Upgrade

The main thing to ensure is that the Postgres database being used maintains its state

• the management plane retrieves all state and authentication information from this database. As long as this is maintained during an upgrade then no workload changes or recreation should be required. Refer to Configuration for details on this.

To upgrade, it should be as simple as running a helm upgrade ... command with the new version of the chart as long as it is an adjacent version upgrade.

If all configuration is stored in a separately managed Postgres database then the old chart can be removed and the new chart installed from scratch.

helm uninstall --namespace "calyptia" calyptia-cloud

You can also remove the namespace entirely.

kubectl delete ns calyptia

Now we can install the new version of the chart as if it was in a fresh cluster. It will then pull all its configuration from the Postgres database.

helm install --create-namespace --namespace "calyptia" --wait calyptia-cloud calyptia/calyptia-standalone

Operator upgrade

For full details, refer to Core Operator upgrade documentation.

The Core Operator could be fixed at a specific version as well to prevent any future upgrades, however Calyptia only supports the versions defined as the default for a particular chart version.

Core Operator usage with the self-hosted helm chart is not recommended for production deployments. The previously provided approach is a best effort to upgrade between adjacent chart versions for non-production deployments.

Old Core Operator versions

Older versions of Core Operator (pre-2.x self-hosted chart) included the CRD in the Core Operator chart. Therefore the upgrade process is two steps:

1. Apply the new Core Operator version of the CRD.

2. Upgrade the Helm chart

The Core Operator version CRD is available as an artifact on the release for that version. The Core Operator version is controlled by a value in the Helm chart. Review the default for the chart version being used.

For version 2.0.12 of Core Operator, the command would be:

kubectl apply -f \
  https://github.com/chronosphereio/calyptia-core-operator-releases/releases/download/v2.0.12/crd.yaml

Replace the v2.0.12 version string with the appropriate new version to upgrade the Core Operator to. See Versions for a list of supported charts and operator combinations.

Supported upgrade versions

Calyptia guarantees support only for adjacent version upgrades for the Helm chart. This means assuming we have release versions 1.0.8, 1.0.9, 2.0.0, 2.0.1 the only supported upgrades are:

• 1.0.8 -> 1.0.9

• 1.0.9 -> 2.0.0

• 2.0.0 -> 2.0.1

To go from 1.0.8 to 2.0.1, the only supported route is by using the intermediate versions.

The default versions provided by a particular chart version are the ones officially supported as working together.

Refer to the release notes as well for the Core versions being deployed for any specific upgrade or feature changes that may impact you. This will provide any details for specific migrations to do around major version upgrades too.