Skip to main content

Deploy with Helm

The aperturedata/aperturedb-helm OCI chart deploys distributed ApertureDB into an existing Kubernetes cluster. The default topology has three database pods, three ZooKeeper pods, two database gateways, two HTTP proxies, one checkpointer, a Web UI, and telemetry.

Prerequisites​

  • Kubernetes 1.23 or later, kubectl configured for the intended cluster, and Helm 3.8 or later.

  • An object storage bucket and credentials; see Deploying ApertureDB.

  • A storage class that can provision persistent volumes for ZooKeeper and, when telemetry is enabled, a shared 100Gi monitoring volume.

  • Enough cluster capacity for the configured workloads. By default, each database pod and the checkpointer requests 8Gi of memory, and each Lenz pod requests 1Gi, in addition to the other components.

  • LoadBalancer support for separate database TCP and HTTP/HTTPS services, or a plan to expose NodePort or ClusterIP services instead.

Use a separate namespace per deployment: several resource names, including lenz and lenz-external, are fixed within the namespace.

Configure and install​

Save the following as my-values.yaml, replacing the placeholders with credentials, a bucket name, and your hostname:

masterKey:
  password: "<strong-database-password>"

storage:
  type: s3
  bucket: "<your-bucket-name>"
  credentials: '{"access_key":"<access-key>","secret_access_key":"<secret-access-key>","region":"us-west-2"}'

service:
  type: LoadBalancer

http:
  host: aperturedb.example.com
  tls: true

telemetry:
  enabled: true
  auth:
    password: "<separate-monitoring-password>"
  grafana:
    adminPassword: "<strong-grafana-password>"

For Google Cloud Storage, set storage.type: gs and use the service account JSON as storage.credentials. The HTTP service is included; no ingress controller is required.

Select a published package tag and install:

chmod 600 my-values.yaml
helm install aperturedb oci://registry-1.docker.io/aperturedata/aperturedb-helm \
  --version <package-version> \
  --namespace aperturedb --create-namespace \
  -f my-values.yaml --wait --timeout 30m
kubectl -n aperturedb get pods,svc,pvc

Keep this values file for later upgrades. To inspect all settings for the selected package:

helm show values oci://registry-1.docker.io/aperturedata/aperturedb-helm \
  --version <package-version>

Secrets and TLS​

For production, reference existing secrets in the deployment namespace instead of placing credentials in the values file. Set the corresponding reference below and omit its inline password or credentials value:

Existing Kubernetes secrets

Helm value

Required secret key

masterKey.existingSecret

password

storage.existingSecret

credentials (the credential JSON)

telemetry.auth.existingSecret

password

telemetry.grafana.existingSecret

password

tls.existingSecret

tls.crt and tls.key in a kubernetes.io/tls secret

For private workload images, set imagePullSecrets to a list such as [{name: my-registry-secret}]. That secret must exist in the same namespace.

TLS selection, in order of precedence, is an existing secret, inline tls.cert and tls.key, cert-manager via tls.certManager, and an automatically generated self-signed certificate. Supply a trusted certificate covering the hostnames used by both web and TCP clients. The self-signed fallback is for evaluation; clients must explicitly trust it or use an evaluation-only certificate verification override.

Connect and verify​

Find the database and HTTP/HTTPS endpoints:

kubectl -n aperturedb get service lenz-external http-proxy

Point the DNS record for http.host at the http-proxy address. Native clients use the separate lenz-external address. The TLS certificate must cover all hostnames used by web and native clients.

  • Web UI: https://aperturedb.example.com/.

  • REST API: https://aperturedb.example.com/api/.

  • Native clients: the lenz-external address, port 55555, with TLS enabled. In-cluster clients can use the lenz service on that port.

  • Grafana: https://aperturedb.example.com/grafana/, with telemetry enabled. Log in as admin with telemetry.grafana.adminPassword or the password in its referenced secret.

Use admin with the master key in the runnable client check at Connect and verify the deployment. Prometheus uses the separate monitoring bearer password to discover and scrape database metrics through Lenz. See Deployment settings and process boundaries for server and gateway settings.

If pods remain pending, inspect kubectl -n aperturedb describe pod <pod-name> and the PVC status for capacity or storage-class problems. For image pull or startup failures, check pod events and kubectl -n aperturedb logs <pod-name> --all-containers --tail=100. An external address that stays pending usually requires checking your cluster’s LoadBalancer implementation. For HTTP routing problems, check DNS, http.host, and the HTTP service logs.

NodePort access​

For direct access through cluster nodes, configure distinct, available HTTP and HTTPS NodePorts and allow them through your firewall:

http:
  host: aperturedb.example.com
  service:
    type: NodePort
    httpNodePort: 30080
    httpsNodePort: 30443

Point http.host at a reachable node. With these example ports, the Web UI is at https://aperturedb.example.com:30443/; append api/ or grafana/ for the API or dashboards. HTTP on port 30080 redirects to that HTTPS address. Choose ports from your cluster’s configured NodePort range, normally 30000–32767. To expose native clients through NodePort as well, set service.type to NodePort and inspect lenz-external for its allocated port.

Behind an external load balancer serving ports 80/443, use NodePort and set http.publicPort to 443. Leave the HTTP and HTTPS NodePorts at zero for automatic allocation. Redirects and Grafana URLs use public port 443. Both database and HTTP Services are always created; use ClusterIP for private access.

Workflow routes and request limits​

Use http.routes to expose workflow HTTP services under the deployment’s web hostname. Each route specifies a path prefix, an in-cluster service name, and its HTTP port. For example:

http:
  host: aperturedb.example.com
  routes:
    - path: /notebooks
      host: workflow-notebooks-ingresses
      port: 8888

Paths must be unique and omit the trailing slash; /api and /grafana are reserved. Requests retain their path prefix and query string. WebSockets and streamed responses are supported, and route updates take effect automatically.

http.bodyLimit limits each request body to 256 MiB by default. Oversized requests receive 413. http.timeoutSeconds controls upstream inactivity and defaults to 300 seconds; workflow routes and Grafana allow one hour between response reads. Active requests have up to five minutes to finish during shutdown. Long-lived sessions should reconnect after an update.

Valid replacements in the configured TLS Secret are loaded automatically. Existing connections can finish with the previous certificate; invalid replacements leave the last valid certificate active.

Customize, upgrade, and remove​

Common values include aperturedb.replicas, lenz.replicas, http.replicas, global.storageClass, and telemetry.persistence.storageClass. Telemetry is enabled by default; use telemetry.enabled: false to disable it. Grafana, Loki, and Prometheus share the web Pod, alongside the Web UI when it is enabled. Promtail runs in each database Pod and forwards its logs to Loki. The monitoring volume is fixed at 100Gi; telemetry.retentionDays controls metrics and log retention and defaults to 28 days. Adjust workload resource settings to your dataset and available capacity before installation.

The chart version selects matching versions of all ApertureData service images.

Review the compatibility notes in Release Notes for your target version, then complete Changing a deployment. The following command applies the chart with your values file:

helm upgrade aperturedb oci://registry-1.docker.io/aperturedata/aperturedb-helm \
  --version <package-version> --namespace aperturedb \
  -f my-values.yaml --wait --timeout 30m

To remove the deployment:

helm uninstall aperturedb --namespace aperturedb

Uninstall removes the active monitoring PVC and may delete its underlying metrics and log data according to the storage reclaim policy. ZooKeeper PVCs created by StatefulSet claim templates remain. The chart does not delete your object storage bucket. Preserve the bucket and retained claims until you have determined which data must be kept for recovery.