Setup

Complete the prerequisites before fetching the chart. Then follow the installation steps to deploy Kumo.

Prerequisites

Complete every item before running helm install. The conformance probe in the installation steps validates most of them automatically.

Cluster and tooling

• Kubernetes 1.28 or later (EKS, GKE). AKS with encrypted transport mode requires 1.33 or later and AKS Managed Istio with native sidecars enabled. ARO requires OpenShift 4.20 or later.

• Helm installed locally.

• CNI that enforces NetworkPolicy - required for backend authorization in all transport modes. EKS VPC CNI network policy or AKS network-policy implementation both satisfy this.

• Release namespace created before installation. Prerequisite Secrets must be pre-staged in this namespace before helm install runs.

  kubectl create ns <namespace>

External dependencies

The chart installs Kumo’s application services. It does not install the following; you must provision them before installation:

• Temporal - self-hosted and reachable at the address you set in temporal.address. The chart registers a namespace in Temporal but does not install Temporal itself. The Temporal OSS Helm chart is the common choice: github.com/temporalio/helm-charts.
• PostgreSQL (the StateDB) - reachable from the cluster. Configure postgres.authMode, postgres.host, postgres.port, postgres.database, and postgres.username in your values. Set postgres.region when postgres.authMode is aws_iam.
• Object storage bucket or prefix - Kumo writes ingested data and model artifacts to object storage you control. Configure a bucket or prefix in AWS S3, Azure Data Lake Storage Gen2 (ADLS Gen2), or Google Cloud Storage. Set kumoConfig.storage.dataBucket; the chart appends /<global.tenant>. The bucket or prefix must be writable by Kumo’s pod workload identity.
• Workload identity - configure the control, worker, and controller service accounts to access the object storage location:
  • AWS S3: IRSA role ARN annotation on each service account.
  • Azure ADLS Gen2: Managed identity client ID annotation on each service account.
  • Google Cloud Storage: GSA email annotation on each service account. Helm uses workload identity exclusively and does not store object-storage access keys in environment files.
• Ingress and TLS - provide the ingress controller, load balancer, DNS record, and TLS certificate. The chart can create the route for supported edge modes; otherwise, route all paths to kumo-ui on port 80. HTTPS is required in all transport modes.
• Service mesh - required for encrypted transport mode only. Use Istio ambient, or on AKS, AKS Managed Istio with native sidecars.

GPU node pools and CSI storage

• Cache pool and ephemeral pool with the required DiskGraph labels (refer to GPU Sizing for Helm). NVIDIA driver 580.65.06 or later on all GPU nodes. GPU device plugin or GPU Operator installed.
• CSI StorageClass with volumeBindingMode: WaitForFirstConsumer, registered in CSINode on every DiskGraph cache node. AWS common choice: ebs-gp3-xfs (AWS EBS CSI). Azure common choice: managed-csi-xfs (Azure Disk).

OpenShift

Apply profiles/openshift.yaml before your custom values. The overlay targets the restricted-v2 SCC; do not grant anyuid or a custom SCC. The default ARO recipe does not install or require a service mesh.

Install Kumo

1. Fetch the chart from NGC

You need an NGC API key with access to nvstaging/sd-kumo3.

helm fetch \
  https://helm.ngc.nvidia.com/nvstaging/sd-kumo3/charts/kumo-helm-<VERSION>.tgz \
  --username='$oauthtoken' \
  --password=<YOUR_NGC_API_KEY>

Single-quote '$oauthtoken' so your shell does not expand it. Newer chart versions are published to the same NGC path. Confirm the chart version to use with your NVIDIA contact.

2. Make the container images pullable

The chart deploys kumo-backend-cpu, kumo-backend-gpu, and kumo-ui from the registry configured in image.registry and image.repoPath. Ensure your cluster nodes or an image pull Secret can pull those images.

If your nodes do not already have registry credentials, create a kubernetes.io/dockerconfigjson Secret:

kubectl create secret docker-registry kumo-pull \
  --docker-server=<registry-host> \
  --docker-username=<registry-username> \
  --docker-password=<registry-password> \
  -n <namespace>

Set image.pullSecretName: kumo-pull in your values. For air-gapped or mirror registries, set image.registry and image.repoPath. The chart applies <registry>/<repoPath>/<name>:<tag> uniformly across all images, including runtime-derived pool workers.

3. Configure the chart and run conformance

Create a values file and set the image registry, repository path, and a current image tag. Never use an alias tag such as latest. The same tag must be present in kumo-backend-cpu, kumo-backend-gpu, and kumo-ui.

helm show values kumo-helm-<VERSION>.tgz > my-values.yaml
tar xzf kumo-helm-<VERSION>.tgz
kumo-helm/conformance/check.sh -f my-values.yaml -n <namespace> prereq

# my-values.yaml
image:
  registry: "<registry-host>"
  repoPath: "<repository-path>"
  tag: "<current-tag>"
  pullSecretName: kumo-pull # omit when your nodes already have access

Resolve all FAIL and BLOCK items before proceeding. ADV items are advisory and non-blocking. Start with kumo-helm/conformance/RUNBOOK.md and conformance/prerequisites.md for remediation guidance.

4. Install and verify

helm install kumo kumo-helm-<VERSION>.tgz \
  --namespace <namespace> \
  -f my-values.yaml
kumo-helm/conformance/check.sh -f my-values.yaml -n <namespace> health

Your values file must include the required chart settings for your deployment.

Next Steps

Continue with GPU planning, platform workflows, SDK development, or your first model.