Helm-Based Task Creation

A Helm task deploys a Helm chart onto a GPU instance for the duration of the job. Use this approach when your workload requires multiple coordinated containers or a more complex Kubernetes resource configuration than a single container image allows.

Creating a Helm task

$
# Using CLI flags
$
nvcf-cli task create \
>
  --name my-helm-job \
>
  --gpu H100 \
>
  --instance-type GPU.H100_1x \
>
  --helm-chart my-registry/charts/my-job:1.0.0
$
$
# From a JSON file
$
nvcf-cli task create --input-file helm-task.json

Example JSON configuration

1
{
2
  "name": "my-helm-job",
3
  "gpuSpecification": {
4
    "gpu": "H100",
5
    "instanceType": "GPU.H100_1x",
6
    "backend": "GFN",
7
    "helmValidationPolicy": {
8
      "name": "Default"
9
    }
10
  },
11
  "helmChart": "my-registry/charts/my-job:1.0.0",
12
  "maxRuntimeDuration": "PT8H",
13
  "resultHandlingStrategy": "UPLOAD",
14
  "resultsLocation": "my-org/my-team/my-model",
15
  "secrets": [
16
    {"name": "NGC_API_KEY", "value": "nvapi-..."}
17
  ]
18
}

Helm validation policy

The helmValidationPolicy field controls which Kubernetes resource types the chart is permitted to create. It is nested inside gpuSpecification.

To permit additional resource types beyond the default set, supply them in extraKubernetesTypes:

1
"helmValidationPolicy": {
2
  "name": "Default",
3
  "extraKubernetesTypes": [
4
    {"group": "batch", "version": "v1", "kind": "CronJob"}
5
  ]
6
}

Differences from container tasks

Runtime limits, secrets, result handling, and monitoring work the same way as container tasks. Note: result upload is not yet supported in this release. See Container-Based Task Creation for details on those fields.