Cluster install values

This page documents the Helm values accepted by tau cluster install. The distribution chart bundles Kueue, KubeRay, the Tau core controller, GPU monitoring, the taugrid-core services chart, and a portable baseline queue into a single versioned release. Portal is enabled by default for the operator quickstart; Stellar, lifecycle recorder, and image prewarm remain disabled until the platform opts in.

Print this reference from your terminal:

tau cluster explain-values

The Helm release namespace is the only namespace setting for TauGrid system workloads and Services. tau cluster install defaults it to tau-system; --namespace <name> moves the Kueue, KubeRay, Tau controller, Portal, GPU monitoring, and other enabled first-party workloads together. The first-party charts follow their Helm release namespace, and the deprecated gpu-monitoring.namespace override must remain empty. Cluster-scoped resources remain cluster-scoped, and Kueue keeps its Kubernetes API aggregation binding in kube-system.

MultiKueue capability

The standard installation includes MultiKueue API/controller support and read-only prerequisite observation. Operators separately create worker credentials, AdmissionChecks, MultiKueueConfigs, MultiKueueClusters, dedicated queues, and profiles. TauCluster.status.conditions[MultiKueueReady] reports the health of those actual operator-owned prerequisites. See Multi-cluster execution before publishing a MultiKueue profile.

Components

Toggle sub-charts with components.<key>.enabled:

Baseline Queue

A portable Kueue queue bootstrapped on first install. These quotas bound concurrent Kueue admission; Kubernetes scheduling still enforces real capacity. Production operators should replace them with deliberate capacity policy.

CPU, memory, and GPU share one Kueue resource group so each GPU pod set receives one node flavor across all of its requested resources. taugrid-default-cpu has zero GPU quota, while the generic taugrid-default-gpu has CPU/memory plus GPU quota and supports gpu_class: any on a fresh install. When hardware is known, replace the GPU flavor list with class-specific flavors and label matching nodes with the canonical A10, A100, H100, H200, GB200, or GB300 class from policy.gpu_class. Only GPU flavors carry topologyName and the managed kueue.x-k8s.io/podset-required-topology metadata annotation. Connected TauGrid submission copies that requirement onto generated GPU pod templates when no explicit placement policy is present. Raw Kubernetes manifests remain expert-controlled. The CPU/memory flavor remains non-TAS. For upgrades with saved legacy values, remove GPU resources from baselineQueue.resources and move all GPU class/series labels and GPU-node tolerations out of baselineQueue.flavor before adding their replacements under baselineQueue.gpu.flavors. Declare GPU-node taints under each flavor’s nodeTaints. TauGrid fails template rendering if the old mixed values would duplicate GPU coverage or constrain CPU-only admission. Replace the generic GPU flavor with class-specific flavors rather than keeping both: exact class quota must not fall back to an unlabeled ResourceFlavor.

Portal

The following are defaults of the TauGrid umbrella distribution used by tau cluster install. The standalone taugrid-core chart keeps Portal disabled, so platforms that install that child chart directly must opt in explicitly. Portal follows the Helm release namespace selected by tau cluster install --namespace; the CLI default is tau-system.

These defaults make the Portal shell, Runs and run-detail views, Cluster Nodes view, and live Ray discovery available to an operator through the ClusterIP Service. See Configure Portal to separately configure Kusto-backed boards, the scoped computed Jobs board, KueueViz, an authenticated researcher endpoint, and a durable experiment store.

baselineQueue.gpu.flavors

Declare GPU-node taints (for example sku=gpu:NoSchedule) in each GPU flavor’s nodeTaints. This makes the flavor ineligible for CPU-only pods if generic CPU quota is exhausted. TauGrid injects sku=gpu and nvidia.com/gpu tolerations into GPU workloads, so those workloads remain eligible. Keep a matching taint out of the flavor’s tolerations: repeating it there would make Kueue automatically tolerate it for every pod and remove the CPU-isolation guard.

# taugrid-values.yaml
baselineQueue:
  gpu:
    flavors:
      - name: a100-pool
        nodeLabels:
          kubernetes.io/os: linux
          tau.azure.com/gpu-class: a100-80gb
        nodeTaints:
          - key: sku
            value: gpu
            effect: NoSchedule
        tolerations: []
        resources:
          - name: nvidia.com/gpu
            nominalQuota: "1"

Sub-Chart Pass-Through

The remaining top-level keys pass values directly to embedded sub-charts:

Example: GPU Cluster

TauGrid’s controller derives the node contract from node.kubernetes.io/instance-type and repairs drift:

Use tau-core-controller.tauCluster.extraNodeLabelRules for another reviewed VM size. Setting nodeLabelRules replaces the built-in catalog. CPU-only clusters and GPU pools scaled to zero remain ready when no catalog entry currently matches.

# taugrid-values.yaml: H200 cluster with GPU taints
baselineQueue:
  gpu:
    flavors:
      - name: h200-pool
        nodeLabels:
          kubernetes.io/os: linux
          kueue.azure.com/gpu-series: nd-h200-v5
          tau.azure.com/gpu-class: h200-141gb
        nodeTaints:
          - key: sku
            value: gpu
            effect: NoSchedule
        tolerations: []
        resources:
          - name: nvidia.com/gpu
            nominalQuota: "8"

See Also

• CLI reference: tau cluster
• Install TauGrid
• Source: charts/taugrid/values.yaml