diff --git a/docs/community/20241112-node-bootstrapping.md b/docs/community/20241112-node-bootstrapping.md new file mode 100644 index 000000000000..7a2d424be866 --- /dev/null +++ b/docs/community/20241112-node-bootstrapping.md @@ -0,0 +1,111 @@ +--- +title: ClusterAPI Node Bootstrapping Working Group +authors: + - "@t-lo" +reviewers: + - "@elmiko" + - "@eljohnson92" + - "@johananl" + - "@tormath1" + - "@fabriziopandini" + - "@sbueringer" + +creation-date: 2024-11-12 +last-updated: 2024-11-15 +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 cluster node. + + +## User Story and Problem Statement + +As a Linux Distribution maintainer aiming to support ClusterAPI, or to improve +my existing support of ClusterAPI in my distribution, I would like to be able to +cleanly integrate my contributions into the node bootstrapping process without +interfering with other implementations. +I would like my contributions to be as re-usable as possible across different +bootstrap providers. +I would like to read and to follow documentation, guidelines, and specifications +on the above. +I would like to offer a choice of node bootstrapping configuration systems to users, +enable distribution vendors to extend the choces available by adding new +configuration systems, and ease maintenance and enable extension of currently +supported systems for the ClusterAPI developer community. + + +**Problem statement / Example issues** + +Currently, the kubeadm bootstrap provider implements two provisioning systems: +cloud-init and ignition. +As there is currently no abstract way to pass configuration to node bootstrapping, +both configuration system implementations - ignition and cloud-init - must cover +generic configuration as well as config language specific concerns. +This leads 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 bootstrapping 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 are 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 between bootstrap and provisioning +and guidelines on how each is developed will make it easier to add support to ClusterAPI as well as to +share implementations across bootstrap providers. + + +**Compatibility and API guarantees** + +ClusterAPI has been stable for multiple years and is in widespread production use. +Proposals and implementations of this working group must ensure to not excert operational +risk on existing integrations. +Any changes in the kubeadm bootstrap provider in particular must uphold guarantees and +expectations set by the current implementation and must continue to support current use +cases OR must provide means for current use cases to continue functioning for an appropriate +migration period, as well as define a clear path for migration. + +## Scope + +1. Propose architectural improvements that abstract system configuration with the goal of + reducing duplicate functionality in current implementations, easing development of new configuration + features, and simplifying integration of new configuration systems for node bootstrapping. +2. Deliver an example implementation in the kubeadm bootstrap provider. +3. Approach other bootstrap providers and provide help and guidance for separating provisioning + and re-using provisioning implementations. + +## Communication + +THe WG will work asynchronously, coordinated via the ClusterAPI Slack (see below), and collaborating +on documents and PRs. 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 summary updates on our work and our progress 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)