Configuration

Configuring self-hosted Calyptia Core management plane

A default Helm values file is provided, and you can configure the file by using the usual Helm approach of --set key=val, or by specifying one or more additional values files with --values filename. Refer to Helm documentation for any specific questions on how to provide the configuration.

Images

The provided Helm chart you can use to install Calyptia Core management plane requires either pull secrets in place, called regcreds by default, or to pass the configuration to create a namespace-level secret to pull images from either the public registries or a separate user-defined private registry.

helm repo add calyptia https://helm.calyptia.com --force-update
helm repo update
helm upgrade --install \
    --create-namespace --namespace calyptia \
    --set imageCredentials.secretName=regcreds \
    --set imageCredentials.registry="<registry url, e.g. ghcr.io>" \
    --set imageCredentials.username="<username for authentication, e.g. Github username>" \
    --set imageCredentials.password="<password or token for authentication>" \
    --set imageCredentials.email="<email associated with user>"
    --wait --debug \
    calyptia-cloud calyptia/calyptia-standalone

Calyptia can provide a package containing all images and the Helm chart. The consumer is responsible for loading images and setting up a Kubernetes cluster with any relevant pull secrets.

To set up a pull secret, see Create a Secret by providing credentials on the command line in the Kubernetes documentation.

kubectl create ns calyptia
kubectl -n calyptia create secret docker-registry "regcreds" \
    --docker-server="<registry url, e.g. ghcr.io>" \
    --docker-username="<username for authentication, e.g. Github username>" \
    --docker-password="<password or token for authentication>" \
    --docker-email="<email associated with user>"

To use a pre-created secret:

helm repo add calyptia https://helm.calyptia.com --force-update
helm repo update
helm upgrade --install \
    --create-namespace --namespace calyptia \
    --set global.imagePullSecrets[0]="regcreds" \
    --wait --debug \
    calyptia-cloud calyptia/calyptia-standalone

Container configuration

To support self-hosted usage, the Helm chart provides common configuration for all images.

global:
  imageRegistry: ""
  imagePullSecrets: []
  storageClass: ""
  pullPolicy: IfNotPresent

A global override for all container image registries can be provided by global.imageRegistry. If the container registry requires authentication, this can be provided by a series of one or more pull secrets. This configuration can also be applied per-image to customise each individual image as required:

    cloud:
      registry: ghcr.io
      repository: calyptia/cloud
      tag: 1.4.1
      pullSecrets: []

As an example, to override the image used from the default to instead be mycompany.io/calyptia-core/cloud:9.9.9 we can set the values like so:

helm upgrade --install \
...
    --set cloudApi.images.cloud.registry="mycompany.io" \
    --set cloudApi.images.cloud.repository="calyptia-core/cloud" \
    --set cloudApi.images.cloud.tag="9.9.9" \
...

This can also be used to force the use of a different default image version (for example, using 1.5.0 instead of 1.4.1) by setting the .tag value appropriately.

Each image can be similarly customized by replacing the cloudApi. prefix with something like frontend or vivo. Refer to the default values.yaml for other options.

Services

The helm chart provides the following services:

• cloud-api: API, defaults to port 5000

• core: UI, defaults to port 3000

These match up with the hosted names (for example, cloud-api.calyptia.com and core.calyptia.com).

In addition, a Vivo service is also provided on port 3000.

All services are provided as LoadBalancer type by default so the external IP can be retrieved by making a call to kubectl -n <namesapce> get svc.

Every Calyptia component has a common set of configuration. For example, for the cloud-api component, you can control whether it's deployed and what type of service to use:

cloudApi:
  enabled: true
  service:
    type: LoadBalancer
    port: 5000

<service>.enabled controls whether to deploy the service or not.

This is repeated for frontend and vivo components.

The <service>.service section then controls how it is exposed.

To switch all service to use type ClusterIP, the following can be done for example:

helm upgrade --install \
    --create-namespace --namespace "calyptia" \
    --set cloudApi.service.type="ClusterIP" \
    --set frontend.service.type="ClusterIP" \
    --set vivo.service.type="ClusterIP" \
    --wait --debug \
    calyptia-cloud calyptia/calyptia-standalone

LoadBalancer services are used by default as they are exposed externally then automatically by the cloud providers and other tools, like K3S.

If using LoadBalancer, the external IP for a service can be retrieved by making a call to kubectl -n <namespace> get svc/<service>.

If using ClusterIP, data needs to be ingested into the cluster in some manner. One technique is to use port-forwarding, (for example, kubectl -n <namespace> port-forward svc/<service> <port>:<port>). This exposes the port locally for use.

Postgres

Calyptia Core uses Postgres to maintain all the configuration information. The chart provides a default deployment of Postgres in-cluster, but this is not recommended for production. A separate Postgres deployment (hosted or otherwise) should be used with high availability support.

To switch to an externally (not by this chart) provided Postgres, modify the following options:

cloudApi:
  postgres:
    enabled: false # Set to false to prevent deployment of the default in-cluster version
    # Set this if providing separately
    connectionString: # e.g. postgresql://postgres@postgres:5432?sslmode=disable for in-cluster

Be sure to provide the connectionString as required to use the Postgres along with any authentication or other requirements in the cluster. Calyptia Core uses the provided string directly to connect to the Postgres instance.

InfluxDB

Calyptia Core uses InfluxDB to capture metrics on the various workloads deployed.

The chart provides a default deployment of InfluxDB in-cluster but this is not recommended for production. A separate InfluxDB deployment (hosted or otherwise) should be used with high availability support.

To switch to an externally (not by this chart) provided InfluxDB, modify the following options:

cloudApi:
  influxdb:
    enabled: false # Set to false to prevent deployment of the default in-cluster version
    # Set this if providing separately
    server: # e.g. http://influxdb:8086

Ensure the server URL is routable from the cluster. Calyptia Core uses the provided string directly to connect to the InfluxDB instance.

Workloads

The chart automatically deploys the Calyptia Core operator into the same namespace to manage workloads. To disable this, modify the following options:

operator:
  enabled: true

After the operator is deployed, the core-instance chart can be used to add workloads to the cluster.