Node Autoscaler Helm Values

Use the cluster’s Pre Run Command to supply custom Helm values for the AWS, Azure, or GCP Node Autoscaler (NA) controller. Typical uses include scheduling the controller onto a dedicated node pool with nodeSelector and tolerations. These values configure the NA installation, rather than the nodes it provisions; use NodePools and NodeClasses for provisioned nodes.

WA components use the independent CLOUDPILOT_WA_HELM_VALUES input. See Workload Autoscaler Helm values for its complete reference and examples combining both inputs.

Availability: the selected installation script must support CLOUDPILOT_NA_HELM_VALUES. Older generated installers ignore this variable. GCP controller.nodeSelector also requires a chart that renders that field. Confirm that both changes are included in your target release before using them. The provider tables below describe the corresponding chart configuration; available fields and defaults depend on the target chart version.

Set values in Pre Run

1. Open the cluster’s Settings in the CloudPilot AI Console.
2. Expand Advanced Options and add an exported YAML string to Pre Run Command.
3. Save the settings, then obtain and run the console’s installation or manual upgrade command for that cluster.

For example, this partial AWS/Azure configuration adds a node selector:

export CLOUDPILOT_NA_HELM_VALUES='
nodeSelector:
  example.com/node-pool: platform
'

For GCP, place the selector under controller. See the complete scheduling examples below.

The variable must be exported because the installer runs in a child shell. You can also export it in your terminal before running the generated command. To load an existing YAML file in that environment:

export CLOUDPILOT_NA_HELM_VALUES="$(cat ./na-values.yaml)"

The file must be available in the environment where the command runs. Its contents are written literally to a temporary values file; the installer does not expand ${VARIABLE} placeholders inside customer YAML. The single-quoted examples on this page also prevent the shell from expanding their contents.

Keep the configuration for subsequent shell upgrades. Saving or editing Pre Run alone does not change running Pods. Automatic upgrades do not execute Pre Run or these installation scripts: they retain existing scheduling fields, but do not apply newly edited values. Use the shell installation/manual-upgrade path to apply changes.

Empty and partial values

You only need to provide the fields you want to change.

The installers use --reset-values. Consequently, omitted fields use the target version’s defaults, not values you manually customized in an earlier Helm release. Put all overrides you want to retain into Pre Run. Explicit installer arguments still take precedence over customer values.

Find all values for your version

Use helm show values to retrieve the complete default values document for the target chart version. Use the version selected by the installation command (CLOUDPILOT_REBALANCE_VERSION in the generated NA installer), rather than assuming that the Agent version or the latest chart version is the same.

Replace <target-chart-version> before running these commands:

helm repo add onboard https://onboard.cloudpilot.ai
helm repo update onboard
export NA_CHART_VERSION='<target-chart-version>'
 
helm show values onboard/aws-optimizer --version "${NA_CHART_VERSION}" > aws-na-defaults.yaml
helm show values onboard/azure-optimizer --version "${NA_CHART_VERSION}" > azure-na-defaults.yaml
helm show values onboard/gcp-optimizer --version "${NA_CHART_VERSION}" > gcp-na-defaults.yaml

Choose the file for your provider. These are chart defaults, not the complete effective installation configuration. The installer also supplies cluster identity, resources, and other values described below. Azure defaults can contain environment placeholders that its installer resolves; copy only the fields you intend to override, not the entire defaults file.

Inspect the installed release when checking the effective configuration:

helm list --namespace cloudpilot --filter '^cloudpilot$'
helm get values cloudpilot --namespace cloudpilot --all --output yaml

Arbitrary YAML keys are not automatically supported: Helm can accept an unknown key that no template reads. Use the fields below and verify the rendered Pod configuration after installation.

AWS and Azure value reference

Paths are relative to the YAML root. controller.resources, Kubernetes scheduling objects, labels, annotations, and lists accept their corresponding Kubernetes structures. Installer-controlled fields are listed separately under precedence.

AWS settings

These paths are relative to root-level settings.

Azure settings

These paths are relative to root-level settings.

GCP value reference

GCP places Pod scheduling, resources, update behavior, and cloud settings under controller. It does not use the AWS/Azure root-level scheduling keys.

GCP settings and feature gates

Installer precedence

The order, from lowest to highest priority, is:

1. Target chart defaults.
2. Installer-generated values, including Azure’s generated environment and defaults.
3. YAML exported as CLOUDPILOT_NA_HELM_VALUES.
4. Explicit installer --set / --set-string arguments, including image-source overrides when the selected image source requires them.

For AWS, customer YAML cannot restore affinity.nodeAffinity because the installer explicitly clears it. Other supported affinity settings still follow Helm’s merge rules. Azure clears node affinity in its generated defaults, but customer YAML is applied afterward.

Scheduling examples

The node label and taint below are illustrative. Replace them with the labels and taints on your intended nodes. A selector restricts placement; a toleration only permits a matching taint and does not select a node by itself.

AWS / EKS

Keep the default CriticalAddonsOnly toleration when adding a custom one:

export CLOUDPILOT_NA_HELM_VALUES='
nodeSelector:
  example.com/node-pool: platform
tolerations:
  - key: CriticalAddonsOnly
    operator: Exists
  - key: example.com/dedicated
    operator: Equal
    value: platform
    effect: NoSchedule
'

Azure / AKS

The managed installer also supplies an AKS Spot toleration. Retain both existing entries if the controller must remain eligible for those taints:

export CLOUDPILOT_NA_HELM_VALUES='
nodeSelector:
  example.com/node-pool: platform
tolerations:
  - key: CriticalAddonsOnly
    operator: Exists
  - key: kubernetes.azure.com/scalesetpriority
    operator: Equal
    value: spot
    effect: NoSchedule
  - key: example.com/dedicated
    operator: Equal
    value: platform
    effect: NoSchedule
'

GCP / GKE

The GCP chart has an empty default toleration list. Both scheduling fields belong under controller:

export CLOUDPILOT_NA_HELM_VALUES='
controller:
  nodeSelector:
    example.com/node-pool: platform
  tolerations:
    - key: example.com/dedicated
      operator: Equal
      value: platform
      effect: NoSchedule
'

Quote YAML label values such as "true" so that Kubernetes receives strings. Check that eligible nodes satisfy the controller’s existing affinity and topology rules. With the usual two replicas and required Pod anti-affinity, plan for at least two eligible nodes. Restricting the controller to unavailable capacity can prevent the autoscaler from provisioning more nodes.

Verify and recover

After installation or upgrade, inspect the release and controller placement:

helm get values cloudpilot --namespace cloudpilot --all --output yaml
kubectl get deployments --namespace cloudpilot
kubectl get pods --namespace cloudpilot --output wide
kubectl get events --namespace cloudpilot --sort-by=.metadata.creationTimestamp

Use kubectl describe pod <controller-pod> --namespace cloudpilot to inspect the effective selector, tolerations, and scheduling failures. Confirm the NA Deployment is available before treating the change as complete. Helm rejects malformed YAML, but the installer may already have applied CRDs before that failure; the operation is not an atomic rollback.

If the controller remains Pending, correct the selector/tolerations in Pre Run, or restore the last known working overrides, then rerun the supported installation or manual-upgrade command. An empty input restores target defaults plus installer settings on that next run; it does not recover earlier custom values automatically.