Skip to content

Commit

Permalink
docs: add proposal for Node Bootstrapping working group
Browse files Browse the repository at this point in the history
Signed-off-by: Thilo Fromm <[email protected]>
  • Loading branch information
t-lo committed Nov 13, 2024
1 parent 1cd1543 commit 6353aad
Showing 1 changed file with 90 additions and 0 deletions.
90 changes: 90 additions & 0 deletions docs/community/20241112-node-bootstrapping.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,90 @@
---
title: ClusterAPI Node Bootstrapping Working Group
authors:
- "@t-lo"
reviewers:
- "@elmiko"
- "@eljohnson92"
- "@johananl"
- "@tormath1"

creation-date: 2024-11-12
last-updated: 2024-11-12
status: proposed
see-also:
- https://github.com/kubernetes-sigs/cluster-api/issues/5294
- https://docs.google.com/document/d/1Fz5vWwhWA-d25_QDqep0LWF6ae0DnTqd5-8k8N0vDDM/edit
- https://github.com/kubernetes-sigs/cluster-api/issues/9157
- https://youtu.be/0AhA4Box3MM?si=IfKJfMWmlA9EW7ri&t=172
---

# Node Bootstrapping Working Group ("CAPI-NoBo")

This document briefly outlines the scope, communication media, and
stakeholders for a Working Group dedicated to the Provisioning aspect of
Node Bootstrapping.

Provisioning, in this context, refers to configuring and customising the
node operating system to prepare it to serve as a ClusterAPI worker cluster node.


## User Story and Problem Statement

As a Linux Distribution maintainer aiming to support ClusterAPI, or to improve
support of ClusterAPI in my distribution, I would like to improve ClusterAPI's
node bootstrapping process and provide specifications on ClusterAPI's expectations
and requirements for provisioning-time configuration and customisation.

Initial focus of the working group is on separating node bootstrapping and node
OS configuration / customisation ("node provisioning" from here on).
At the time of writing, bootstrapping and provisioning are architecturally
intertwined; both are implemented in the bootstrap provider.
This increases maintenance effort and effectively prevents re-using provisioning
features across bootstrap providers.

For example: the kubeadm bootstrap provider implements two provisioning systems:
cloud-init and ignition.
Since there is no architectural separation between bootstrapper and provisioning,
both implementations cover all concerns, leading to duplicate code and
to maintenance overhead.
Also, other providers like e.g. MicroK8s must implement their own OS configuration
generators since kubeadm's node provisioning implementations cannot be re-used.
MicroK8s currently only supports cloud-init.

Outside of ClusterAPI, both [cloud-init](https://github.com/canonical/cloud-init)
and [ignition](https://github.com/coreos/ignition) provisioning is widely adopted
across distributions.
While cloud-init is used by general-purpose Linux distributions like Ubuntu/Debian,
SUSE Linux, Alma, Rocky, Fedora, and Red Hat Enterprise Linux, ignition is popular
with special-purpose distributions like Fedora CoreOS / Red Hat CoreOS, SuSE MicroOS
/ SLE Micro / Kalpa, and Flatcar Container Linux.
It is likely that more provisioning systems exist; a clean separation and guidelines
will make it easier to add support to ClusterAPI as well as to share implementations acrosss
bootstrap providers.

## Scope

1. Deliver a clean architectural separation between provisioning and node bootstrapping.
2. Deliver an example implementation in the kubeadm bootstrapper.
3. Approach other bootstrappers and provide help and guidance for separating provisioning
and re-using provisioning implementations.

## Communication

We will join the [regular ClusterAPI meetings](https://github.com/flatcar-hub/cluster-api?tab=readme-ov-file#-community-discussion-contribution-and-support)
and share updates on our work in the "Feature Groups" section, which is a regular part of
the ClusterAPI meetings)

Chat with stakeholders on Kubernetes [Slack](http://slack.k8s.io/) in the
[cluster-api](https://kubernetes.slack.com/archives/C8TSNPY4T) channel.

## Stakeholders

Primary Stakeholders are listed below:

- The Flatcar Container Linux project
- Johanan Liebermann (@johananl, Microsoft)
- Mathieu Tortuyaux (@tormath1, Microsoft)
- Thilo Fromm (@t-lo, Microsoft)
- Michael McCune (@elmiko, Red Hat)
- Evan Johnson, (@eljohnson92, Akamai)

0 comments on commit 6353aad

Please sign in to comment.