Cluster templates
A template is a named blueprint with four parts:
Files are rendered with Go templating:
{{.VariableName}} anywhere in a custom file is substituted at creation time. Besides the custom variables, every template can use the built-in variables (ClusterName, Supervisor, SupervisorServerUrl, SourceRepo, StorageClass, PodsCIDR, and the rest — the full list is on the create page). Built-ins are auto-injected from the request, the supervisor, and the template’s own infrastructure fields; an explicit value you pass always wins over an injected one.
Templates are validated at save time: every
{{.Name}} referenced in customFiles must be either a declared variable or a known built-in. A typo fails the save, not the eventual cluster creation.Render, preview, create
Three endpoints take a template from blueprint to cluster, in increasing order of commitment:1
Render — resolve the variables
POST /api/cluster-templates/<id>/render merges variable defaults with the values you pass and returns the fully substituted templateData. Nothing touches a supervisor. Used by the wizard to keep its form live.2
Preview — see the exact files
POST /api/cluster-templates/<id>/preview renders every custom file and the auto-generated Cluster resource, returning the complete file set with paths. Still nothing created — this is the review screen before the confirm button.3
Create — apply the result
POST /api/cluster-templates/<id>/create renders the same file set and applies it. How it applies depends on the supervisor: with an attached GitOps repository the files are committed under clusters/<cluster>/ in one atomic commit; without one they are applied directly to the supervisor’s API. You never choose the mode — the repository attachment is the signal.StorageClassis required — via a template variable default, the infrastructure fields, or an explicit override. Creation fails fast with a clear message otherwise.- CIDRs must not collide. Leave the pod/service CIDRs blank and Celum allocates free subnets automatically, checked against the supervisor and every existing cluster. Explicit CIDRs that overlap an existing cluster are rejected with
409 Conflict.
customFiles already include a cluster.yaml, the provider (generic / tanzu / talos) dispatches an auto-generated Cluster resource from the infrastructure fields, so a minimal template needs no hand-written Cluster CR at all.
Cluster addons
An addon is a bundle of Kubernetes manifests (stored as ConfigMaps) plus a cluster selector — the database-backed form of a Cluster API ClusterResourceSet. Addons let you capture “every cluster with label X gets these manifests” once and reuse it everywhere.
Import reads an existing ClusterResourceSet — its selector, strategy, and referenced ConfigMaps — off a supervisor and saves it as an addon, so an addon that was hand-built on one supervisor becomes a portable blueprint.
Push applies the addon onto a supervisor: it recreates the ConfigMaps and the ClusterResourceSet there, after which Cluster API delivers the manifests into every matching guest cluster.
A ClusterResourceSet only matches clusters in its own namespace. Pushes default to the
default namespace; for clusters living in a project namespace, pass ?namespace=proj-demo on the push so the CRS lands next to the clusters it should select.Permissions
Cloud-init templates (Linux) and sysprep templates (Windows) are the VM-side siblings of cluster templates — same variable model, applied to individual machines. They are covered under Create a VM.
Celum AI answers template questions through the same APIs —
list_cluster_templates and get_cluster_template return the identical blueprints, variables, and files the settings page shows.Related
Create a cluster
The wizard that consumes these templates, including the built-in variable list.
Clusters overview
Where templates fit among the four cluster models.
Storage classes & profiles
What the required
StorageClass variable should point at.Permissions reference
Every
cluster-template:* and cluster-addon:* action with its KRN.