-
Notifications
You must be signed in to change notification settings - Fork 24
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
The standard for the K8s version policy is updated in order to add the support period for Kubernetes versions into it. Since this is a bit contradictive with the K8s version recency, this part needed to be updated as well. Signed-off-by: Hannes Baum <hannes.baum@cloudandheat.com>
- Loading branch information
Showing
1 changed file
with
75 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,75 @@ | ||
| --- | ||
| title: SCS K8S Version Policy | ||
| type: Standard | ||
| status: Draft | ||
| stabilized_at: 2023-08-16 | ||
| track: KaaS | ||
| --- | ||
|
|
||
| ## Introduction | ||
|
|
||
| The Kubernetes project maintains multiple release versions including their patched versions. | ||
| In the project, the three most recent minor releases are actively maintained, with a fourth | ||
| version being in development. As soon as a new minor version is officially released, | ||
| the oldest version is dropped out of the support period. | ||
| Kubernetes supports its releases for around 14 months. 12 of these are the standard | ||
| support period. The remaining 2 months are used for: | ||
|
|
||
| - CVEs (under the advisement of the Security Response Committee) | ||
| - dependency issues (including base image updates) | ||
| - critical core component issues | ||
|
|
||
| [Kubernetes Support Period](https://kubernetes.io/releases/patch-releases/#support-period) | ||
|
|
||
| The Kubernetes releases are planned for about 4 months, which usually results in about | ||
| **3 minor** releases per year. | ||
| [Kubernetes Release Cycle](https://kubernetes.io/releases/release/#the-release-cycle) | ||
|
|
||
| Patches to these releases are provided monthly, with the exception of the first patch, | ||
| which is usually provided 1-2 weeks after the initial release. | ||
| [Patch Release Cadence](https://kubernetes.io/releases/patch-releases/#cadence) | ||
|
|
||
| ## Motivation | ||
|
|
||
| Kubernetes is a living, fast-paced project, which follows a pre-defined release cycle. | ||
| This enables forward planning with regards to releases and patches, but also implies a | ||
| necessity to upgrade to newer versions quickly. | ||
|
|
||
| We want to achieve an up to date policy, which means that providers should be mostly in sync with the upstream and don't | ||
| fall behind the official Kubernetes releases. In our opinion, this should be achievable, since new versions are released | ||
| periodical on a well communicated schedule. This should enable processes to be set up around this. | ||
| Being up to date ensures, that security issues and bugs are addressed and new features are made available when using SCS compliant clusters. | ||
|
|
||
| On the other hand, providers should support minor Kubernetes versions at least as long as | ||
| the official support period is, since users could depend on specific versions. | ||
| This could be a bit contradicting in some cases, because the necessity to upgrade versions | ||
| would theoretically drop the support period after that upgrade period. | ||
|
|
||
| It is therefore more reasonable, to recommend a version upgrade and make the version | ||
| support period a necessity. | ||
|
|
||
| ## Decision | ||
|
|
||
| In order to keep up-to date with the latest Kubernetes features, bug fixes and security improvements, | ||
| the provided Kubernetes versions should be kept up to date with the upstream. | ||
|
|
||
| - It is RECOMMENDED, that the latest minor version is provided no later than 4 months after release. | ||
| - It is RECOMMENDED, that the latest patch version is provided no later than 1 week after release. | ||
| - It is RECOMMENDED, that this time period should be even shorter for patches that target critical CVEs (CVSS >= 8). It is probably recommended to have a patch period around 1 to 3 days for these cases. | ||
| - It is RECOMMENDED, that new versions SHOULD be tested before being rolled out on an infrastructure. How this testing will be done won't be defined in this document. | ||
|
|
||
| At the same time, provider should support Kubernetes versions at least as long as the official sources as mentioned | ||
| in the Kubernetes Support Period document. | ||
|
|
||
| - Kubernetes versions SHOULD be supported as long as the official sources support them. At the moment, this support period | ||
| is 14 months. | ||
| - It is RECOMMENDED to not support versions after this period in order to not encourage using out-of-date versions. | ||
|
|
||
| ## Related Documents | ||
|
|
||
| All documents regarding versioning, releases, etc. for the official Kubernetes projects can be founder here: | ||
| [Kubernetes Releases](https://kubernetes.io/releases/) | ||
|
|
||
| ## Validation / Conformance | ||
|
|
||
| *This section will be updated when the conformance tests are written.* |