Skip to main content

Local evaluation

Datastrato Enterprise runs on a laptop against a local Kubernetes cluster, using the same chart and the same values as a real deployment. Nothing here is a special evaluation build, so what you learn transfers directly to a cluster.

Expect twenty minutes. You need Docker, a trial key from Licensing, and registry credentials.

Quick Start​

1. Create a cluster. Either kind or k3d works. Give it more memory than the default, since the Gravitino pod wants 4 GiB.

kind create cluster --name gravitino

2. Authenticate to the registry.

helm registry login {registry_host} --username {username} --password {password}

3. Install the chart with the built-in database.

helm upgrade --install gravitino \
  oci://{registry_host}/charts/datastrato-enterprise \
  --namespace gravitino --create-namespace \
  --set mysql.enabled=true \
  --set-string license.key="{license_key}"

4. Wait for readiness.

kubectl -n gravitino rollout status deployment/gravitino

5. Forward the port.

kubectl -n gravitino port-forward svc/gravitino 8090:8090

The API and the UI are now at http://localhost:8090.

Creating Something to Look At​

An empty install shows an empty UI, which is not informative. Create a metalake and attach a catalog, following Getting started.

The quickest source to attach is a database you already run. If you have none, start one in the same cluster and point a catalog at it by its in-cluster service name.

Adding an Engine​

Querying through Trino is the part that shows what federation means, and it needs the connector inside the Trino pod. See Connectors on Kubernetes, which applies here exactly as it does on a real cluster.

This is worth doing even in an evaluation. A metadata catalog with nothing querying it demonstrates the object model but not the point of it.

Resource Pressure​

Docker Desktop's default allocation is usually too small once Gravitino, its database, and an engine are all running. Raise the memory allocated to Docker to 8 GiB before adding Trino, or the pods will be evicted in a way that looks like a Gravitino fault.

kubectl -n gravitino describe pod -l app.kubernetes.io/name=gravitino | grep -A5 Events

Eviction and OOMKilled in that output mean the cluster is short of memory, not that the install is wrong.

Tearing Down​

kind delete cluster --name gravitino

Everything goes with the cluster, including the built-in database. Sources you attached that live outside the cluster are untouched.

Moving to a Real Cluster​

The chart, the values, and the license are the same. What changes for production is the storage backend, which should be a database you operate rather than the built-in one, authentication, which should be your identity provider rather than open access, and ingress, which should be a real service rather than a port forward.

Requirements and Install with Helm cover the differences.

Last updated on