Device specific TinkerbellTemplateConfig in the multi node cluster environmental.

[bnousilal]

I want to create the multi-node cluster using bare metal.
how can I pass the device-specific information in the TinkerbellTemplateConfig section?

For example, I have below the configuration, where the hard disk type is different, I cannot use the same template in the TinkerbellTemplateConfig section.

eksa-cp01,10.10.44.1,root,PrZ8W93i,CC:48:3A:00:00:01,10.10.50.2,255.255.254.0,10.10.50.1,8.8.8.8|8.8.4.4,type=cp,/dev/sda
eksa-cp02,10.10.44.2,root,Me9xQf93,CC:48:3A:00:00:02,10.10.50.3,255.255.254.0,10.10.50.1,8.8.8.8|8.8.4.4,type=cp,/dev/nvme0n1
eksa-cp03,10.10.44.3,root,Z8x2M6hl,CC:48:3A:00:00:03,10.10.50.4,255.255.254.0,10.10.50.1,8.8.8.8|8.8.4.4,type=cp,/dev/sda
eksa-wk01,10.10.44.4,root,B398xRTp,CC:48:3A:00:00:04,10.10.50.5,255.255.254.0,10.10.50.1,8.8.8.8|8.8.4.4,type=worker,/dev/nvme0n1
eksa-wk02,10.10.44.5,root,w7EenR94,CC:48:3A:00:00:05,10.10.50.6,255.255.254.0,10.10.50.1,8.8.8.8|8.8.4.4,type=worker,/dev/sda

[uldyssian-sh]

In EKS Anywhere Bare Metal (Tinkerbell), the TinkerbellTemplateConfig is applied at the cluster level. There is no supported “per-machine template override” where different machines in the same cluster reference different templates directly from the cluster spec.

So if you need device-specific differences (like disk device path /dev/sda vs /dev/nvme0n1), you have to handle that inside the template itself rather than trying to attach different templates per host.

The two practical patterns are:

Pattern 1 (recommended): make the template device-agnostic

Instead of hardcoding a disk path, detect the target disk at runtime in the workflow actions.

Typical approaches inside the template:

• choose the boot disk automatically (the disk that contains the EFI/boot partition)
• pick the largest non-removable disk
• pick the first disk that is not a USB device
• prefer NVMe if present, otherwise fall back to SATA

For example, run a small shell step that sets a variable like DISK=/dev/nvme0n1 if it exists, else DISK=/dev/sda, and then use that variable in partitioning/installation steps.

This lets a single TinkerbellTemplateConfig work across mixed hardware.

Pattern 2: encode per-host values via Hardware metadata (and read it in the template)

If you already have per-machine data (your CSV includes the disk path), store it as metadata on the Tinkerbell Hardware object (or as an annotation/field that ends up available to the workflow).

Then, in the template, read that machine-specific metadata and use it as the disk device.

This is the closest you can get to “device-specific settings” while still using one template reference in the cluster config: one template, but parameterized by per-hardware metadata.

What you cannot do today (in a supported way):

• Define multiple TinkerbellTemplateConfig objects and assign them to individual machines in the same EKS Anywhere bare metal cluster via the cluster spec.
• Pass a different disk path per host through the cluster YAML directly into template selection.

Summary:

You can’t attach different templates per node from the EKS Anywhere cluster config.

Use one template that is device-agnostic (auto-detect disk), or store per-host disk path in hardware metadata and have the template read it at runtime.

[uldyssian-sh]

Thanks! If this helps, please consider marking it as “Helpful” or “Accepted” 😊