Skip to main content
Version: v1.2.x

Compute Configs

A Compute Config is a reusable blueprint of cluster settings. Platform administrators capture infrastructure details such as networking, Secure Shell (SSH) keys, and node configuration in a Compute Config once. Data scientists and ML engineers then deploy against those defaults without repeating boilerplate.

You can create and manage Compute Configs from the Settings > Compute Config menu at the project and tenant scope. Advanced and GitOps users can also manage them declaratively through the ComputeConfig custom resource. For the complete schema, examples, and validation rules, refer to the ComputeConfig Configuration reference.

tip

A Compute Config stores the cluster settings you would otherwise enter manually in Palette's cluster deployment workflow. For Edge clusters, it covers most settings from the Cluster Config and Nodes Config pages.

How Compute Configs Are Used​

Every Project references a Compute Config. When users deploy AI/ML applications or models, PaletteAI provisions clusters from the Compute Config so the same settings apply every time.

Users can also apply a Compute Config on demand while creating a Compute Pool: the gear icon on the Node config page opens the Advanced settings drawer, where selecting a Compute Config and choosing Apply auto-populates the control plane, worker pool, and deployment settings. Values from the Compute Config are defaults — anything you change in the workflow afterward takes precedence.

A Compute Config holds two groups of settings:

  • Cluster defaults — Control plane and worker pool configuration (node counts, architecture, CPU, memory, GPU requirements, labels, and taints), SSH keys, and the deletion policy.

  • Edge settings — Cluster-wide Edge defaults such as NTP servers and network overlay configuration. The virtual IP (VIP) is not part of a Compute Config; it is set per deployment.

At the tenant scope, a Compute Config can be shared with all Projects or with a selected list of Projects.

Worker Node Eligibility​

The workerNodeEligible setting, displayed as Run workloads on control plane in the console, determines whether control plane nodes can run workloads in addition to managing the cluster.

Turn it on for single-node deployments, where one machine serves as both control plane and worker. For single-node clusters, scheduling follows the worker pool's requirements, and control plane labels, taints, and annotations are merged into the pool and override worker pool values where they conflict.

For multi-node deployments, two configurations are valid:

  • Dedicated control plane (workerNodeEligible: false) — Control plane nodes handle only cluster management; at least one worker pool is required for workload scheduling.

  • Worker-eligible control plane (workerNodeEligible: true) — Control plane nodes can schedule workloads. You may define worker pools for additional capacity, or omit worker pools entirely to create an HA control-plane-only topology where all workloads run on control plane nodes.

Refer to Deploy a Single-Node Compute Pool for a step-by-step guide.

Minimum Worker Nodes​

Several places can set a minimum worker node count: a Workload Profile's palette.ai/min-nodes label (highest priority), the worker pool configuration on the deployment or Compute Pool, and the Compute Config's worker pool defaults (lowest priority). If none of them specify a minimum, no minimum is enforced. Refer to Minimum Worker Node Sources for details and examples.

Next Steps​