Configuration
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 (opens in a new tab) 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 5000core
: 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 (opens in a new tab) service is also provided on port 3000.
All services are provided as
LoadBalancer
(opens in a new tab)
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
(opens in a new tab),
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 (opens in a new tab) 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
(opens in a new tab)
chart can be used to add workloads to the cluster.