Skip to content

Commit 2061b88

Browse files
committed
Add In-place upgrades feature group
1 parent dc64556 commit 2061b88

File tree

1 file changed

+53
-0
lines changed

1 file changed

+53
-0
lines changed
Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
---
2+
title: Feature Group for In-place Upgrades support in Cluster API
3+
authors:
4+
- "@g-gaston"
5+
reviewers:
6+
- "@dharmjit"
7+
- "@vincepri"
8+
- "@sbueringer"
9+
- "@fabriziopandini"
10+
creation-date: 2023-10-16
11+
last-updated: 2023-10-16
12+
status: proposed
13+
see-also:
14+
- https://github.com/kubernetes-sigs/cluster-api/issues/9489
15+
- https://docs.google.com/document/d/1CqQ1SAqJD264PsDeMj_Z3HhZxe7DViNkpJ9d5q-2Zck
16+
---
17+
# In-place upgrades Feature Group
18+
19+
This document briefly outlines the scope, communication media, and stakeholders for a formal Feature Group dedicated to defining a Cluster API-approved solution to upgrade the kubernetes components running in CAPI managed nodes without replacing those machines.
20+
21+
## User Story and Problem Statement
22+
23+
As a CAPI Kubernetes cluster admin I want to upgrade the k8s components (for example, a minor Kubernetes upgrade) of my cluster without replacing the machines.
24+
25+
At present, CAPI has "immutable infrastructure" as one of its axioms: once created, Machines are not updated, they are just replaced (a new one is created and old one is deleted). As a consequence, the only supported upgrade strategy is rolling update. However, for certain use cases (such as Single-Node Clusters with no spare capacity, Multi-Node Clusters with VM/OS customizations for high-performance/low-latency workloads or dependency on local persistent storage), upgrading a cluster via RollingUpdate strategy could either be not feasible or a costly operation (requiring to re-apply customizations on newer nodes and hence more downtime).
26+
27+
## Scope
28+
29+
The scope of this effort will be the following:
30+
31+
1. Define the scope of what In-place upgrades means in the context of Cluster API.
32+
2. Write a CAPI proposal with the recommended solution.
33+
34+
## Communication
35+
36+
We will meet on [Wednesdays at 08:00 PT (Pacific Time)][zoomMeeting]. [Convert to your timezone](https://dateful.com/time-zone-converter?t=09:00&tz=PT%20%28Pacific%20Time%29). Meeting notes will be documented in this [Google Doc](https://docs.google.com/document/d/1GmRd6MyQ0mWAoJV6rCHhZTSTtKMKHdJzhXm0BLBXOnw).
37+
38+
Regular, summarized updates of group progress will be provided during weekly Cluster API office hours on Wednesdays @ 10:00 PT on [Zoom][zoomMeeting].
39+
40+
Chat with stakeholders on Kubernetes [Slack](http://slack.k8s.io/) in the [cluster-api](https://kubernetes.slack.com/archives/C8TSNPY4T) channel.
41+
42+
## Stakeholders
43+
44+
Primary Stakeholders are listed below:
45+
46+
- Mayur Das (@mayur-tolexo, VMware)
47+
- Alexander Demicev (@alexander-demicev, SUSE)
48+
- Scott Dodson (@sdodson, Red Hat)
49+
- Guillermo Gaston (@g-gaston, AWS)
50+
- Furkat Gofurov (@furkatgofurov7, SUSE)
51+
- Dharmjit Singh (@dharmjit, VMware)
52+
53+
[zoomMeeting]: https://zoom.us/j/861487554

0 commit comments

Comments
 (0)