> 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-5/a-spoke-as-a-working-environment.md).

# A Spoke as a working environment

A new environment should arrive with the services its applications need: controlled developer access, a deployment path, networking, ingress, certificates and storage. Maintaining those choices together lets us provide the same baseline when the next environment is requested.

For the worked installation, we use the automation and configuration templates in the [govstack-bootstrap repository](https://git.vanillacore.net/govstack/govstack-bootstrap). A **Spoke** is a cluster environment managed from the central Management cluster. The platform creates its Kubernetes machines, prepares its foundations and provides a local application-delivery system. We use two kinds of Spoke: a **LoadBalancer Spoke** for shared routing, and **workload Spokes** for applications. In source documents, *child cluster* also refers to these managed Spokes. [\[9\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/docs/spoke-lifecycle.md)[\[13\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/templates/loadbalancer-foundation-apps.yaml.j2)

The foundation configuration supplies developer VPN access, local Argo CD, networking, ingress, certificate management and storage. Before an application team uses the environment, we configure its authorized VPN peers, repositories, namespaces and certificate issuer. The LoadBalancer and workload Spokes share this foundation baseline; we give each its own addresses, delivery permissions and routing configuration. [\[13\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/templates/loadbalancer-foundation-apps.yaml.j2)

<figure><img src="https://1406653965-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkZFMZ3jCMUwHtTN0sL4J%2Fuploads%2Fgit-blob-e33e7f0779f2c30ad67ec08911d679f99b4de3d3%2Ffinal.png?alt=media" alt="A workload Spoke groups Kubernetes capacity, developer VPN access, local workload Argo CD and platform foundations. Application repositories and access policies connect teams to the prepared environment."><figcaption><p>Figure 1. The workload Spoke brings together the services needed to operate and deliver applications.</p></figcaption></figure>

## Platform delivery and application delivery

**Management Argo CD** runs in the Management cluster. It delivers the configured Management software and the declarations used to create Spokes. After a Spoke is registered, it also installs and maintains that Spoke's foundations, including its local Argo CD. The initial Management installation uses Ansible to establish the services that this delivery path depends on. [\[9\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/docs/spoke-lifecycle.md)[\[13\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/templates/loadbalancer-foundation-apps.yaml.j2)[\[14\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/gitops/management/management-monitoring.yaml.j2)

Each Spoke has a dedicated **local Argo CD**, called Workload Argo CD in the repository. Its job is the rollout and lifecycle of applications from the permitted application repositories. An application release is therefore handled inside its destination Spoke. The central platform delivery continues to maintain the environment around it. [\[13\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/templates/loadbalancer-foundation-apps.yaml.j2)

For example, creating `example-workloads` begins with a platform configuration change. Management Argo CD delivers its cluster declarations, Cluster API creates its machines, and the foundations prepare it for use. When we later publish an application revision, the local Argo CD reads the application's repository and updates its Kubernetes resources. [\[9\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/docs/spoke-lifecycle.md)[\[13\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/templates/loadbalancer-foundation-apps.yaml.j2)

<figure><img src="https://1406653965-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkZFMZ3jCMUwHtTN0sL4J%2Fuploads%2Fgit-blob-1a19c8fc08eaa1acdd854edaf3a5150d76dae34d%2Ffinal.png?alt=media" alt="Platform Git supplies Management Argo CD. Within Management it delivers configured software and Spoke declarations to the controllers; across cluster boundaries it delivers Spoke foundations and installs local Argo CD. Application Git supplies the local Argo CD, which deploys application resources inside its Spoke. Initial Management installation uses Ansible."><figcaption><p>Figure 2. Management Argo CD maintains platform delivery. Each Spoke's local Argo CD maintains application delivery.</p></figcaption></figure>

| Operating task                        | Responsible path                                                 | Configuration we supply                                             |
| ------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------- |
| Create or maintain a Spoke's machines | Management declarations, Cluster API and infrastructure provider | Machine image, sizes, addresses and requested counts                |
| Prepare the Spoke's platform services | Management Argo CD                                               | Foundation versions, ingress addresses, issuer and storage settings |
| Provide developer access              | Gateway and VPN configuration                                    | Peer public keys, routes and permissions                            |
| Release an application                | Local Argo CD in the destination Spoke                           | Application repository, namespace and resources                     |
| Inspect an environment                | GovStackSpoke and Dashboard                                      | Selected Spoke and current status                                   |

## Request and observe an environment

We want to request a new Spoke through a repeatable configuration instead of rebuilding its installation by hand. The platform represents each managed environment with a **GovStackSpoke** resource. Its **Custom Resource Definition (CRD)** registers that type in Management's Kubernetes API. Each named resource represents one Spoke, including its requested machine counts and the observed state of its cluster and foundations. Applications have their own resources and delivery status inside the Spoke. [\[9\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/docs/spoke-lifecycle.md)[\[11\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/gitops/management/govstack-spoke-crd.yaml)

For a new Spoke, we choose its name, machine sizes, image and network allocations in a cluster configuration file. A **renderer** combines that file with the environment configuration and installation outputs, then generates the GovStackSpoke resource, Cluster API declarations and foundation delivery declarations. We review and publish them together in the deployment repository. Management then has the complete request needed to create the environment. [\[9\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/docs/spoke-lifecycle.md)[\[13\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/templates/loadbalancer-foundation-apps.yaml.j2)

The **cluster bridge** connects the GovStackSpoke request to the cluster controllers. It applies requested machine counts and replacement operations, registers the resulting cluster with Management Argo CD, and reports the environment's state back to GovStackSpoke. Operators use that resource throughout creation, scaling and maintenance. [\[9\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/docs/spoke-lifecycle.md)[\[11\]](https://git.vanillacore.net/govstack/govstack-bootstrap/src/commit/1195f539afe5a1018be07d2e1865824c225ee407/gitops/management/govstack-spoke-crd.yaml)

<figure><img src="https://1406653965-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkZFMZ3jCMUwHtTN0sL4J%2Fuploads%2Fgit-blob-b16d7e9ff3f1ecd7f7abd42ea0c1ffb15c5c00a3%2Ffinal.png?alt=media" alt="GovStackSpoke spec supplies lifecycle requests to the bridge, which updates Cluster API fields. The bridge reports observations in status and registers the Spoke with Management Argo CD for foundation delivery."><figcaption><p>Figure 3. The bridge carries the environment request into Cluster API and returns observations to GovStackSpoke.</p></figcaption></figure>

We use OpenStack for the installation described here. The same operating approach applies to Proxmox or public-cloud environments when the platform has the corresponding infrastructure integration in place.


---

# 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-5/a-spoke-as-a-working-environment.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.