-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
47 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,47 @@ | ||
--- | ||
title: Feature Group for Managed Kubernetes in Cluster API | ||
authors: | ||
- "@g-gaston" | ||
reviewers: | ||
- "@dharmjit" | ||
- "@vincepri" | ||
- "@sbueringer”" | ||
- "@fabriziopandini" | ||
creation-date: 2023-10-16 | ||
last-updated: 2023-10-16 | ||
status: proposed | ||
see-also: | ||
- https://github.com/kubernetes-sigs/cluster-api/issues/9489 | ||
- https://docs.google.com/document/d/1CqQ1SAqJD264PsDeMj_Z3HhZxe7DViNkpJ9d5q-2Zck | ||
--- | ||
# In-place upgrades Feature Group | ||
|
||
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. | ||
|
||
## User Story and Problem Statement | ||
|
||
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. | ||
|
||
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). | ||
|
||
## Scope | ||
|
||
The scope of this effort will be the following: | ||
|
||
1. Define the scope of what In-place upgrades means in the context of Cluster API. | ||
2. Write a CAPI proposal with the recommended solution. | ||
|
||
## Communication | ||
|
||
We will meet on [TODO: agree on a day and time][zoomMeeting]. [Convert to your timezone](http://www.thetimezoneconverter.com/?t=09:00&tz=PT%20%28Pacific%20Time%29). Meeting notes will be documented in this [TODO: create Google Doc](). | ||
|
||
Regular, summarized updates of group progress will be provided during weekly Cluster API office hours on Wednesdays @ 10:00 PT. | ||
|
||
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: | ||
|
||
- Dharmjit Singh (@dharmjit, VMware) | ||
- Guillermo Gaston (@g-gaston, AWS) |