Skip to content

Commit bf5ce21

Browse files
committed
docs: add proposal for Node Bootstrapping working group
Signed-off-by: Thilo Fromm <thilofromm@microsoft.com>
1 parent 1cd1543 commit bf5ce21

File tree

1 file changed

+90
-0
lines changed

1 file changed

+90
-0
lines changed
Lines changed: 90 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,90 @@
1+
---
2+
title: ClusterAPI Node Bootstrapping Working Group
3+
authors:
4+
- "@t-lo"
5+
reviewers:
6+
- "@elmiko"
7+
- "@eljohnson92"
8+
- "@johananl"
9+
- "@tormath1"
10+
11+
creation-date: 2024-11-12
12+
last-updated: 2024-11-12
13+
status: proposed
14+
see-also:
15+
- https://github.com/kubernetes-sigs/cluster-api/issues/5294
16+
- https://docs.google.com/document/d/1Fz5vWwhWA-d25_QDqep0LWF6ae0DnTqd5-8k8N0vDDM/edit
17+
- https://github.com/kubernetes-sigs/cluster-api/issues/9157
18+
- https://youtu.be/0AhA4Box3MM?si=IfKJfMWmlA9EW7ri&t=172
19+
---
20+
21+
# Node Bootstrapping Working Group ("CAPI-NoBo")
22+
23+
This document briefly outlines the scope, communication media, and
24+
stakeholders for a Working Group dedicated to the Provisioning aspect of
25+
Node Bootstrapping.
26+
27+
Provisioning, in this context, refers to configuring and customising the
28+
node operating system to prepare it to serve as a ClusterAPI worker cluster node.
29+
30+
31+
## User Story and Problem Statement
32+
33+
As a Linux Distribution maintainer aiming to support ClusterAPI, or to improve
34+
support of ClusterAPI in my distribution, I would like to improve ClusterAPI's
35+
node bootstrapping process and provide specifications on ClusterAPI's expectations
36+
and requirements for provisioning-time configuration and customisation.
37+
38+
Initial focus of the working group is on separating node bootstrapping and node
39+
OS configuration / customisation ("node provisioning" from here on).
40+
At the time of writing, bootstrapping and provisioning are architecturally
41+
intertwined; both are implemented in the bootstrap provider.
42+
This increases maintenance effort and effectively prevents re-using provisioning
43+
features across bootstrap providers.
44+
45+
For example: the kubeadm bootstrap provider implements two provisioning systems:
46+
cloud-init and ignition.
47+
Since there is no architectural separation between bootstrapper and provisioning,
48+
both implementations cover all concerns, leading to duplicate code and
49+
to maintenance overhead.
50+
Also, other providers like e.g. MicroK8s must implement their own OS configuration
51+
generators since kubeadm's node provisioning implementations cannot be re-used.
52+
MicroK8s currently only supports cloud-init.
53+
54+
Outside of ClusterAPI, both [cloud-init](https://github.com/canonical/cloud-init)
55+
and [ignition](https://github.com/coreos/ignition) provisioning is widely adopted
56+
across distributions.
57+
While cloud-init is used by general-purpose Linux distributions like Ubuntu/Debian,
58+
SUSE Linux, Alma, Rocky, Fedora, and Red Hat Enterprise Linux, ignition is popular
59+
with special-purpose distributions like Fedora CoreOS / Red Hat CoreOS, SuSE MicroOS
60+
/ SLE Micro / Kalpa, and Flatcar Container Linux.
61+
It is likely that more provisioning systems exist; a clean separation and guidelines
62+
will make it easier to add support to ClusterAPI as well as to share implementations acrosss
63+
bootstrap providers.
64+
65+
## Scope
66+
67+
1. Deliver a clean architectural separation between provisioning and node bootstrapping.
68+
2. Deliver an example implementation in the kubeadm bootstrapper.
69+
3. Approach other bootstrappers and provide help and guidance for separating provisioning
70+
and re-using provisioning implementations.
71+
72+
## Communication
73+
74+
We will join the [regular ClusterAPI meetings](https://github.com/flatcar-hub/cluster-api?tab=readme-ov-file#-community-discussion-contribution-and-support)
75+
and share updates on our work in the "Feature Groups" section, which is a regular part of
76+
the ClusterAPI meetings)
77+
78+
Chat with stakeholders on Kubernetes [Slack](http://slack.k8s.io/) in the
79+
[cluster-api](https://kubernetes.slack.com/archives/C8TSNPY4T) channel.
80+
81+
## Stakeholders
82+
83+
Primary Stakeholders are listed below:
84+
85+
- The Flatcar Container Linux project
86+
- Johanan Liebermann (@johananl, Microsoft)
87+
- Mathieu Tortuyaux (@tormath1, Microsoft)
88+
- Thilo Fromm (@t-lo, Microsoft)
89+
- Michael McCune (@elmiko, Red Hat)
90+
- Evan Johnson, (@eljohnson92, Akamai)

0 commit comments

Comments
 (0)