Skip to main content

Kubernetes

The Helm chart is the flagship install. It deploys the sensor DaemonSet, the gateway, the hub, the ui, and ClickHouse. The chart is published to GHCR as an OCI artifact, so there is no repository to add.

# Flagship install — the chart is published to GHCR as an OCI artifact,
# eBPF auto-discovers your services. No repo to add.
helm install avuruobs oci://ghcr.io/avuruvision/charts/avuruobs \
  --version <X.Y.Z> -n avuruobs --create-namespace

# Point apps at the gateway (OTLP):
#   http://avuruobs-gateway:4318   (HTTP)
#   http://avuruobs-gateway:4317   (gRPC)

# Open the UI:
kubectl -n avuruobs port-forward svc/avuruobs-ui 8080:80

Requirements​

  • Kubernetes ≥ 1.26
  • Helm ≥ 3.8 (OCI support)
  • Linux nodes with BTF (kernel ≥ 5.8) for full eBPF; older kernels degrade gracefully (map + OTLP still work).
  • A default StorageClass for ClickHouse's PersistentVolume.

Install​

helm install avuruobs oci://ghcr.io/avuruvision/charts/avuruobs \
  --version <X.Y.Z> -n avuruobs --create-namespace

Pick a published version from the releases. Prefer a one-liner that resolves the latest release and waits for rollout? The installer runs only helm and kubectl against your current context — read it first, or pass --dry-run to print the exact command:

curl -fsSL https://raw.githubusercontent.com/avuruvision/avuru-obs/main/deploy/install.sh | sh

The chart and every image are cosign-signed and built for amd64 + arm64. Verify a release with the commands in the engine's RELEASING guide.

Point apps at the gateway​

Already exporting OTLP? Change only the endpoint — no SDK or code change:

# OTLP/HTTP
http://avuruobs-gateway:4318
# OTLP/gRPC
http://avuruobs-gateway:4317

Open the UI​

The UI is its own deployable; /api is proxied to the hub from the same origin.

kubectl -n avuruobs port-forward svc/avuruobs-ui 8080:80
# then browse http://localhost:8080/

In production, expose it through an ingress (ingress.enabled=true, ingress.host=…) behind your own auth (OIDC / oauth2-proxy).

Choose your signals​

Every signal family is a module you can switch off to run a leaner install — see Modules. The service map, traces and RED core is always on.

Upgrading & sizing​

  • Upgrades are helm upgrade with the same values; schema migrations are additive, idempotent and forward-only. See Upgrade.
  • Sizing, retention and high availability (small / medium / external-HA ClickHouse) are covered in Scaling & retention.
  • The full values list lives in the Configuration reference.