Running Tersane without BKE

Tersane may be licensed on its own, for any conformant Kubernetes distribution. The charts ship with the defaults of the Bahriya Kubernetes Engine, so on another distribution some components must be supplied, or some defaults changed, before the charts install and behave as documented. This page lists each of them.

Running Tersane this way calls for experience with Kubernetes and with the components below. Organisations that prefer not to take that on can engage Mamluk for Kubernetes consulting or support.

What the charts expect

Calico is BKE’s network fabric and is always present. Kong, Longhorn and cert-manager are BKE components, each enabled per cluster; on a BKE cluster, enable the ones the charts you install depend on.

Expectation	Provided by BKE	Charts affected	By default
Calico, for projectcalico.org/v3 NetworkPolicy	Yes, always: it is BKE’s network fabric	mysql, valkey, memcached	On for mysql and valkey; off for memcached
A StorageClass named longhorn	Yes, when Longhorn is enabled	mysql, valkey	Used for every volume
Longhorn itself	Yes, when Longhorn is enabled	mysql	Only for volume encryption and volume snapshots, both off by default
The Kong ingress controller	Yes, when Kong is enabled	safeena; mysql and valkey when exposed	On for safeena
cert-manager	Yes, when cert-manager is enabled	safeena; mysql when its web client is enabled	Only when certificates are requested
The image credential for 1x.ax	Not a cluster component	Charts that run Mamluk’s images	Always

Calico

The mysql, valkey and memcached charts render their NetworkPolicy as a Calico projectcalico.org/v3 resource. On a cluster without Calico that resource type does not exist, and an installation with the policy enabled fails. Either install Calico, or turn the chart’s policy off and write your own policy for the release:

networkPolicy:
  enabled: false

The policy is enabled by default in mysql and valkey.

Storage

The mysql and valkey charts ask for a StorageClass named longhorn. On a cluster without one, the volumes are never bound and the pods stay Pending. Name a ReadWriteOnce class your cluster provides:

# mysql
storage:
  data:
    storageClass: "<your class>"
  binlog:
    storageClass: "<your class>"

# valkey
storage:
  storageClass: "<your class>"

Two mysql features depend on Longhorn itself rather than on the class name: volume encryption (encryption.volume), which creates a Longhorn StorageClass with LUKS parameters, and volume snapshots (pitr.volumeSnapshots), which create Longhorn RecurringJobs. Both are off by default. Without Longhorn, leave them off and use your storage platform’s own encryption and snapshots.

The storage class is fixed when a release is installed; see Upgrading a chart.

Kong

The safeena chart publishes services through the Kong ingress controller, with IngressClass kong. Its redirection from HTTP to HTTPS, its basic authentication, its rate limiting and its IP restriction are all Kong plugins, and have no effect under another ingress controller. Install the Kong ingress controller to use the chart as documented.

The mysql chart’s web client and its external access, and the valkey chart’s external access, also route through Kong. All three are off by default.

cert-manager

The safeena chart issues certificates through cert-manager Certificate resources, one per entry in its certificates list, each naming a ClusterIssuer in your cluster. The list is empty by default. The mysql chart’s web client requests its certificate from cert-manager when it is enabled. Install cert-manager, with a ClusterIssuer of your choosing, before using either.

Neither chart requires a particular issuer. The certificates the mysql and valkey charts use for their own in-cluster TLS are generated by the charts and do not need cert-manager.

Images

Charts that run images built by Mamluk pull them from 1x.ax with your organisation’s image credential, whatever the distribution. See Access and credentials.