Skip to content
MCP server built inHow that works
lavalake

Installing on Kubernetes

An umbrella Helm chart ships for cluster deployments. It installs the platform along with SeaweedFS, Nessie, Trino, Keycloak, PostgreSQL, cert-manager and an nginx ingress into a namespace of its own.

On this page

To simply try the platform, the Docker Compose stack is the faster route. This page covers the cluster installation.

A separate deployment path

The reference deployment uses Docker Compose; the Ansible playbook installs that stack on Debian/Ubuntu. Helm is a separate path with outstanding operational work. Daily backups and workload classes from Compose are not automatically configured here.

Enable policy integration

The infra/helm/flaky-platform/values-datenrechte.yaml overlay connects generated policies to Trino. A sidecar distributes policy and group files through a ConfigMap, read by Trino and warehouse coordinators. Enforcement is not active without the overlay. Check status and test a restricted account.

Installing

  1. Create the cluster and roll out the chart

    On first run this generates .env with the secrets and installs into the namespace flaky-platform.

    ./scripts/bootstrap.sh

  2. Configure Keycloak

    Realm, Trino client with its audience mapper, and a test user.

    ./scripts/configure-keycloak.sh

  3. Prove that it holds

    An end-to-end proof: authenticated SQL, an Iceberg time-travel read, and the expected 401 and 403 refusals.

    ./scripts/verify.sh

  4. Reach the ingress

    One port-forward is enough; the console is then at http://localhost:8080/.

    kubectl -n flaky-platform port-forward svc/flaky-platform-ingress-nginx-controller 8080:8080

One issuer, in lockstep

As in the compose stack: Keycloak is served under /auth, which pins the public issuer. Every token — from the browser login as well as from the exchange for Trino — carries exactly that iss, while backchannel calls stay inside the cluster. Trino therefore runs with OIDC discovery disabled and every OAuth2 endpoint pinned to the in-cluster Keycloak service.

The purpose of this construction: the public address never has to resolve inside the cluster — and the issuer in every token still matches.

Tearing down

kind delete cluster --name flaky-platform

That removes all data; the .env file stays behind.

Deployment profiles and acceptance

The Helm chart includes additional profiles for data permissions, internal TLS, AI SQL, warehouses and high availability. The HA profile has been rendered and partly verified against PostgreSQL; live-cluster installation and node-failure testing remain outstanding. It is not a proven availability guarantee.

  • HA profile values-ha.yaml: cluster and failure acceptance outstanding
  • Health, alerts and logs in the console; /metrics for your own Prometheus
  • Secrets through Kubernetes Secrets, Vault or External Secrets following the operations guide
  • Internal TLS layer through values-tls-intern.yaml for documented connections
  • Check images and chart dependencies against the current release
  • Offline bundle for Compose; Kubernetes requires its own image registry and provisioning

Applies to: This page describes lavalake 0.201.0. Product and documentation live in separate repositories — when in doubt, what the console shows is authoritative.

Something missing?

If these pages do not answer your question, we will walk through the platform against your own case in half an hour.

Book a demo