> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/cloud-for-dpi/chapter-4/preparing-machine-images.md).

# Preparing machine images

A cluster declaration can create a virtual machine only from an image available to the IaaS platform. **cloud-init** receives first-boot configuration from that platform and applies it inside a new VM. It can create accounts, place files and run commands automatically, which can turn a prepared image into a configured machine within minutes instead of requiring hours of manual installation. The actual time still depends on image size, package sources, network access and the amount of first-boot work. [\[27\]](https://cloudinit.readthedocs.io/en/latest/explanation/introduction.html)

cloud-init does not make every operating-system image ready to join Kubernetes. The image must already support the selected operating system and contain, or reliably install, compatible versions of the container runtime, kubelet and kubeadm. Kernel modules, sysctl values, swap settings and trust material must also match the bootstrap procedure. If all of this is deferred to first boot, every new Node downloads and configures the same dependencies again, making creation slower and more sensitive to temporary network or repository failures.

The preferred path therefore uses **Kubernetes SIGs Image Builder** to prepare a repeatable, version-specific Node image from an approved operating-system source. The [machine-image lab](https://git.vanillacore.net/giga/content/src/branch/main/chapter-4/lab/foundation/image-builder/README.md) starts with an approved Ubuntu cloud image, pins Image Builder to a source revision, selects Kubernetes `v1.36.3`, creates a private machine image in the image registry of the underlying IaaS provider, and records its identifier and provenance. In the OpenStack implementation, that registry is the Glance image service and the identifier is an image UUID. The general cloud image used for the seed and the Kubernetes-ready image used by CAPO remain separate artifacts. [\[3\]](https://cluster-api-openstack.sigs.k8s.io/clusteropenstack/configuration.html)[\[12\]](https://image-builder.sigs.k8s.io/capi/providers/openstack.html)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/cloud-for-dpi/chapter-4/preparing-machine-images.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.