Self hosting
Overview
Calyptia provides a hosted management plane for Calyptia Core workloads through calyptia.com (opens in a new tab), 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 (opens in a new tab) 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 (opens in a new tab) also provides details on configuration.
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
doesn't 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:
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's better to separate the management plane (self-hosted) from the data plane (Core Operator). This lets you 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, run a helm upgrade ...
command with the new version of the chart as
long as it's 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:
- Apply the new Core Operator version of the CRD.
- Upgrade the Helm chart
The Core Operator version CRD is available as an artifact on the release for that version (opens in a new tab). The Core Operator version is controlled by a value in the Helm chart (opens in a new tab). 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.
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 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.