Lakerunner Installation Guide
Use the interactive wizard below to generate a configuration for your Lakerunner deployment. Select your installation type and fill in the required details to generate a values.yaml file.
Installation Wizard
Installation Type
Organization Settings
Lakerunner is multi-tenant. Each tenant is an organization, and the collector and API key are used by that organization.
Optional Components
Cloud Provider
PostgreSQL - Lakerunner DB
PostgreSQL - Config DB
License
A valid license is required for Lakerunner to operate. Contact support@cardinalhq.com to obtain one.
Scaling
Lakerunner uses internal autoscaling from 1 pod up to the max you set here.
| Service | Max Pods |
|---|---|
| Log Processing | |
| Metric Processing | |
| Trace Processing |
Ingestion
Choose how S3 object notifications are ingested. HTTP provides a webhook endpoint. SQS polls from an AWS SQS queue.
Generated values.yaml
For the complete list of configuration options, see the full values.yaml reference on GitHub .
Post-Installation
Verify the Installation
After installation, verify all pods are running:
kubectl get pods -n lakerunner -l app.kubernetes.io/name=lakerunnerAccess Grafana
Configure an Ingress or use port-forwarding to access Grafana:
kubectl port-forward -n lakerunner svc/grafana 3000:3000Deploying on OpenShift
The chart renders cleanly under the restricted-v2 SCC with two adjustments. Add the following to the values.yaml produced by the wizard above:
1. Let the SCC assign UIDs
OpenShift’s restricted-v2 SCC rejects pods whose runAsUser/runAsGroup/fsGroup fall outside the namespace’s assigned UID range — it wants to inject them from the range itself. Null the fields so the chart emits only runAsNonRoot: true:
global:
podSecurityContext:
runAsNonRoot: true
runAsUser: null
runAsGroup: null
fsGroup: null
grafana:
podSecurityContext:
runAsNonRoot: true
runAsUser: null
runAsGroup: null
fsGroup: nullThe SCC fills in runAsUser, runAsGroup, and fsGroup. All other hardening from global.containerSecurityContext (no-privilege-escalation, drop ALL, RuntimeDefault seccomp, read-only rootfs) stays in effect.
2. Grafana needs an SCC that permits UID 472
The upstream grafana/grafana image expects UID 472 to own /var/lib/grafana. Because that UID almost never falls inside a namespace’s restricted-v2 range, Grafana needs either a custom SCC or an OpenShift-compatible image. The simplest path is:
oc adm policy add-scc-to-user nonroot-v2 -z <release>-lakerunner -n <namespace>…and then keep Grafana’s defaults (UID 472). If you prefer to avoid the SCC grant, swap grafana.image.repository for an image that supports random UIDs.
3. Perch needs elevated RBAC
The Perch component ships with a ClusterRole that includes patch on apps/deployments cluster-wide — this is its legitimate function (cross-namespace deployment management), but it counts as a privileged grant. On clusters with strict RBAC review you may need admin approval or an oc adm policy add-role-to-user edit against the chart’s ServiceAccount.
4. Ingress / Routes
The chart uses standard networking.k8s.io/v1 Ingress resources. They work with the OpenShift HAProxy router out of the box; no nginx-specific annotations are emitted.
Upgrading
To upgrade an existing installation:
helm upgrade lakerunner oci://public.ecr.aws/cardinalhq.io/lakerunner \
--values values.yaml \
--namespace lakerunnerUninstalling
To remove Lakerunner:
helm uninstall lakerunner --namespace lakerunnerNote: This does not delete your data in the cloud storage bucket.
Reach out to support@cardinalhq.io for support or to ask questions not answered in our documentation.