> 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/from-workload-lifecycle-to-cluster-lifecycle.md).

# From workload lifecycle to cluster lifecycle

Creating a Kubernetes cluster requires suitable machine images, control-plane initialization, Node joins, Pod networking and a reliable link between every infrastructure machine and Kubernetes Node.

**kubeadm** initializes a Kubernetes control plane and joins Nodes. It remains useful for the first cluster and recovery, but does not continuously create, replace, scale or upgrade the IaaS resources beneath a cluster fleet. [\[8\]](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)[\[20\]](https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta4/)

**Cluster API (CAPI)** represents clusters and machines as Kubernetes resources and reconciles their lifecycle. It needs an existing Kubernetes API: the **management cluster** hosts its controllers and declarations, while the resulting **child clusters** include the workload and LoadBalancer clusters used here. [\[1\]](https://cluster-api.sigs.k8s.io/user/concepts.html)[\[2\]](https://cluster-api.sigs.k8s.io/user/quick-start.html)

An **infrastructure provider** connects CAPI's model to a platform. **Cluster API Provider OpenStack (CAPO)** translates infrastructure declarations into OpenStack operations for ports, virtual machines and private child API endpoints. The **OpenStack Resource Controller (ORC)** supplies OpenStack resource APIs required by this CAPO version. CAPI's **kubeadm bootstrap provider** and **control-plane provider** initialize and join the resulting machines. [\[2\]](https://cluster-api.sigs.k8s.io/user/quick-start.html)[\[3\]](https://cluster-api-openstack.sigs.k8s.io/clusteropenstack/configuration.html)[\[13\]](https://cluster-api.sigs.k8s.io/reference/versions.html)

CAPI creates another Machine, CAPO creates its OpenStack server, and kubeadm joins the new Node. That sequence applies during initial creation, replacement and scaling; the later practical checks follow the same object from declaration to server and Node.

## Two initial adaptation steps

CAPI needs two adaptations before its declarative interface can be used.

1. **Adapt CAPI to the infrastructure.** Install a compatible provider, such as CAPO for OpenStack, so a CAPI Machine can become platform resources.
2. **Adapt the provider to the environment.** Record approved networks, images, sizes, failure domains, ranges and security rules. CAPO needs the OpenStack project, image, network, subnet, flavors, security group and API address. [\[3\]](https://cluster-api-openstack.sigs.k8s.io/clusteropenstack/configuration.html)

Kubernetes then provides the workload abstraction, while CAPI provides cluster lifecycle. Environment inputs remain visible because they determine what CAPI can create.

The main approaches can now be compared against the same lifecycle need:

| Method                                      | What it does well                                                                                              | Main limitation for this architecture                                                                                   |
| ------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| kubeadm used directly                       | Exposes bootstrap and works well for the first cluster or controlled recovery                                  | Repeating the procedure for many clusters creates drift and leaves machine replacement to separate automation           |
| Vendor-managed cluster service              | Can provide an integrated, supported lifecycle on one platform                                                 | Its API, upgrade policy and infrastructure choices are coupled to that service                                          |
| Cluster API with an infrastructure provider | Represents clusters and machines as declarative resources and reconciles them across supported infrastructures | Requires a protected management cluster, compatible providers, prepared images and a reviewed environment configuration |

The reference uses CAPI so one reviewed Cluster request drives infrastructure and Kubernetes objects together. A vendor-managed service can still fit different lifecycle or sovereignty requirements. [\[1\]](https://cluster-api.sigs.k8s.io/user/concepts.html)[\[2\]](https://cluster-api.sigs.k8s.io/user/quick-start.html)[\[13\]](https://cluster-api.sigs.k8s.io/reference/versions.html)

<figure><img src="https://1406653965-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkZFMZ3jCMUwHtTN0sL4J%2Fuploads%2Fgit-blob-7cb3020109e00ca70c45f05628e7583758c72122%2Ffinal.png?alt=media" alt="A Cluster request is reconciled through Cluster API control-plane and worker objects, CAPO infrastructure objects, OpenStack servers and Kubernetes Nodes."><figcaption><p>Figure 3. Cluster API manages the machines that provide capacity to Kubernetes, while Kubernetes manages the workloads on those machines.</p></figcaption></figure>

**Video companion:** [C4-I2, Two reconciliation loops and the reference topology](https://git.vanillacore.net/giga/content/src/branch/main/chapter-4/VIDEO_SCOPES.md#c4-i2-two-reconciliation-loops-and-the-reference-topology)


---

# 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/from-workload-lifecycle-to-cluster-lifecycle.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.