diff --git a/Standards/scs-0210-v1-k8s-new-version-policy.md b/Standards/scs-0210-v1-k8s-new-version-policy.md index af35bef17..3e5825b7d 100644 --- a/Standards/scs-0210-v1-k8s-new-version-policy.md +++ b/Standards/scs-0210-v1-k8s-new-version-policy.md @@ -19,13 +19,12 @@ Here we will describe how fast providers need to keep up with the upstream Kuber To create a informed decision we summarize here the Kubernetes rules regarding versioning at the time of writing (2023-01-16): -Kubernetes usually provides about **3 minor** releases per year. -[Kubernetes Release Cycle](https://kubernetes.io/releases/release/#the-release-cycle) +Kubernetes usually provides about **3 minor** releases per year (see [Kubernetes Release Cycle][k8s-release-cycle]). -Patch release cadence is typically monthly. However, the first patches after the first minor release usually arrive 1-2 weeks after the first minor release. -[Patch Release Cadence](https://kubernetes.io/releases/patch-releases/#cadence) +Patch release cadence is typically monthly. However, the first patches after the first minor release usually arrive 1-2 weeks after the first minor release +(see [Patch Release Cadence][k8s-release-cadence]). -In general the latest 3 minor versions are maintained by the Kubernetes project. +As stated in [Kubernetes Support Period][k8s-support-period], in general the latest 3 minor versions are maintained by the Kubernetes project. Every release will be maintained for about 14 months. The first 12 months are the standard support period. The remaining 2 months are only for: @@ -34,8 +33,6 @@ The remaining 2 months are only for: - dependency issues (including base image updates) - critical core component issues -[Kubernetes Support Period](https://kubernetes.io/releases/patch-releases/#support-period) - ## Motivation Kubernetes is a fast-paced project. @@ -52,10 +49,15 @@ However, providers should have reasonable time to implement the new Kubernetes v ## Related Documents -All important documents regarding versioning, releases, etc. for the official Kubernetes project can be found here: [Kubernetes Releases](https://kubernetes.io/releases/) +All important documents regarding versioning, releases, etc. for the official Kubernetes project can be found on the [Kubernetes Releases page][k8s-releases]. ## Conformance Tests The conformance test is written in the 'k8s-version-recency-check.py' script. The script requires the path to a valid kubeconfig file, which should describe the k8s cluster under test. This can either be done by creating a config from the also provided 'config.yaml.template' or by calling the test script with its cli arguments. + +[k8s-releases]: https://kubernetes.io/releases/ +[k8s-release-cycle]: https://kubernetes.io/releases/release/#the-release-cycle +[k8s-release-cadence]: https://kubernetes.io/releases/patch-releases/#cadence +[k8s-support-period]: https://kubernetes.io/releases/patch-releases/#support-period diff --git a/Standards/scs-0210-v2-k8s-version-policy.md b/Standards/scs-0210-v2-k8s-version-policy.md index 0d4efaf59..88ed5738b 100644 --- a/Standards/scs-0210-v2-k8s-version-policy.md +++ b/Standards/scs-0210-v2-k8s-version-policy.md @@ -21,11 +21,12 @@ support period. The remaining 2 months are the end-of-life support period for th More information can be found under [Kubernetes Support Period]. -The Kubernetes release cycle is set around 4 months, which usually results in about -**3 minor** releases per year [Kubernetes Release Cycle](https://kubernetes.io/releases/release/#the-release-cycle). +The [Kubernetes release cycle][k8s-release-cycle] is set around 4 months, which +usually results in about **3 minor** releases per year. 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). +which is usually provided 1-2 weeks after the initial release (see [Patch Release +Cadence][k8s-release-cadence]). ## Motivation @@ -51,32 +52,45 @@ window period. ## 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. +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 new upstream releases: - The latest minor version MUST be provided no later than 4 months after release. - The latest patch version MUST be provided no later than 1 week after release. -- This time period MUST be even shorter for patches that target critical CVEs (CVSS >= 8). +- This time period MUST be even shorter for patches that fix critical CVEs. + In this context, a critical CVE is a CVE with a CVSS base score >= 8 according + to the CVSS version used in the original CVE record (e.g., CVSSv3.1). It is RECOMMENDED to provide a new patch version in a 2 day time period after their release. - New versions MUST be tested before being rolled out on productive infrastructure; - at least the CNCF E2E tests should be passed beforehand. + at least the [CNCF E2E tests][cncf-conformance] should be passed beforehand. At the same time, providers must support Kubernetes versions at least as long as the -official sources as mentioned in the [Kubernetes Support Period](https://kubernetes.io/releases/patch-releases/#support-period). +official sources as described in [Kubernetes Support Period][k8s-support-period]: -- Kubernetes versions MUST be supported as long as the official sources support them. - The current support period can therefore be found in [Kubernetes Support Period](https://kubernetes.io/releases/patch-releases/#support-period). +- Kubernetes versions MUST be supported as long as the official sources support them + according to the [Kubernetes Support Period][k8s-support-period] and their end-of-life + date according to the [Kubernetes Releases page][k8s-releases]. - It is RECOMMENDED to not support versions after this period in order to not encourage usage of out-of-date versions. ## Related Documents -All documents regarding versioning, releases, etc. for the official Kubernetes projects can be found here: -[Kubernetes Releases](https://kubernetes.io/releases/) -[Kubernetes Support Period](https://kubernetes.io/releases/patch-releases/#support-period) -[Kubernetes Release Cycle](https://kubernetes.io/releases/release/#the-release-cycle) -[Patch Release Cadence](https://kubernetes.io/releases/patch-releases/#cadence) - -## Validation / Conformance - -*This section will be updated when the conformance tests are written.* +All documents regarding versioning, releases, etc. for the official Kubernetes projects can +be found on the [Kubernetes Releases page][k8s-releases]. + +## Conformance Tests + +The script `k8s_version_policy.py` requires a kubeconfig file with connection details for +a set of existing Kubernetes clusters that should be checked, with each of these clusters +representing one of the currently supported upstream Kubernetes releases. +It will check the encountered cluster versions according to the rules of this standard. +Rule violations will be reported on various logging channels: ERROR for mandatory rules +and INFO for recommended rules. +The script will exit with a non-zero status if a mandatory rule has been violated or if +the test could not be performed. + +[k8s-releases]: https://kubernetes.io/releases/ +[k8s-release-cycle]: https://kubernetes.io/releases/release/#the-release-cycle +[k8s-release-cadence]: https://kubernetes.io/releases/patch-releases/#cadence +[k8s-support-period]: https://kubernetes.io/releases/patch-releases/#support-period +[cncf-conformance]: https://github.com/cncf/k8s-conformance