From 7ed368d0be2f5b31bb38655e19f7899db167f3d1 Mon Sep 17 00:00:00 2001 From: windsonsea Date: Mon, 7 Aug 2023 10:05:47 +0800 Subject: [PATCH] Clean up /releases --- content/en/releases/_index.md | 13 ++- content/en/releases/download.md | 6 +- content/en/releases/notes.md | 8 +- content/en/releases/release-managers.md | 5 +- content/en/releases/version-skew-policy.md | 114 ++++++++++++++------- 5 files changed, 100 insertions(+), 46 deletions(-) diff --git a/content/en/releases/_index.md b/content/en/releases/_index.md index 5b62f95d82add..092729a2f477f 100644 --- a/content/en/releases/_index.md +++ b/content/en/releases/_index.md @@ -4,13 +4,17 @@ title: Releases type: docs --- - -The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive [approximately 1 year of patch support](/releases/patch-releases/#support-period). Kubernetes 1.18 and older received approximately 9 months of patch support. +The Kubernetes project maintains release branches for the most recent three minor releases +({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). +Kubernetes 1.19 and newer receive +[approximately 1 year of patch support](/releases/patch-releases/#support-period). +Kubernetes 1.18 and older received approximately 9 months of patch support. Kubernetes versions are expressed as **x.y.z**, -where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology. +where **x** is the major version, **y** is the minor version, and **z** is the patch version, +following [Semantic Versioning](https://semver.org/) terminology. More information in the [version skew policy](/releases/version-skew-policy/) document. @@ -22,6 +26,7 @@ More information in the [version skew policy](/releases/version-skew-policy/) do ## Upcoming Release -Check out the [schedule](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}}) for the upcoming **{{< skew nextMinorVersion >}}** Kubernetes release! +Check out the [schedule](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}}) +for the upcoming **{{< skew nextMinorVersion >}}** Kubernetes release! ## Helpful Resources diff --git a/content/en/releases/download.md b/content/en/releases/download.md index 0cee6e3556afb..c728ec015f9a8 100644 --- a/content/en/releases/download.md +++ b/content/en/releases/download.md @@ -43,6 +43,7 @@ You can fetch that list using: ```shell curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/stable.txt)/release" | grep "SPDXID: SPDXRef-Package-registry.k8s.io" | grep -v sha256 | cut -d- -f3- | sed 's/-/\//' | sed 's/-v1/:v1/' ``` + For Kubernetes v{{< skew currentVersion >}}, the only kind of code artifact that you can verify integrity for is a container image, using the experimental signing support. @@ -50,11 +51,10 @@ signing support. To manually verify signed container images of Kubernetes core components, refer to [Verify Signed Container Images](/docs/tasks/administer-cluster/verify-signed-artifacts). - - ## Binaries -Find links to download Kubernetes components (and their checksums) in the [CHANGELOG](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) files. +Find links to download Kubernetes components (and their checksums) in the +[CHANGELOG](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) files. Alternately, use [downloadkubernetes.com](https://www.downloadkubernetes.com/) to filter by version and architecture. diff --git a/content/en/releases/notes.md b/content/en/releases/notes.md index 1bb60c810627c..bcda7d0a04437 100644 --- a/content/en/releases/notes.md +++ b/content/en/releases/notes.md @@ -8,6 +8,10 @@ sitemap: priority: 0.5 --- -Release notes can be found by reading the [Changelog](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) that matches your Kubernetes version. View the changelog for {{< skew currentVersionAddMinor 0 >}} on [GitHub](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew currentVersionAddMinor 0 >}}.md). +Release notes can be found by reading the [Changelog](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) +that matches your Kubernetes version. View the changelog for {{< skew currentVersionAddMinor 0 >}} on +[GitHub](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew currentVersionAddMinor 0 >}}.md). -Alternately, release notes can be searched and filtered online at: [relnotes.k8s.io](https://relnotes.k8s.io). View filtered release notes for {{< skew currentVersionAddMinor 0 >}} on [relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew currentVersionAddMinor 0 >}}.0). +Alternately, release notes can be searched and filtered online at: [relnotes.k8s.io](https://relnotes.k8s.io). +View filtered release notes for {{< skew currentVersionAddMinor 0 >}} on +[relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew currentVersionAddMinor 0 >}}.0). diff --git a/content/en/releases/release-managers.md b/content/en/releases/release-managers.md index 34fab5552f9b5..cbfd77b66e597 100644 --- a/content/en/releases/release-managers.md +++ b/content/en/releases/release-managers.md @@ -31,7 +31,10 @@ The responsibilities of each role are described below. ### Security Embargo Policy -Some information about releases is subject to embargo and we have defined policy about how those embargoes are set. Please refer to the [Security Embargo Policy](https://github.com/kubernetes/committee-security-response/blob/main/private-distributors-list.md#embargo-policy) for more information. +Some information about releases is subject to embargo and we have defined policy about +how those embargoes are set. Please refer to the +[Security Embargo Policy](https://github.com/kubernetes/committee-security-response/blob/main/private-distributors-list.md#embargo-policy) +for more information. ## Handbooks diff --git a/content/en/releases/version-skew-policy.md b/content/en/releases/version-skew-policy.md index 7a9f1c753a1b2..7031402e5c356 100644 --- a/content/en/releases/version-skew-policy.md +++ b/content/en/releases/version-skew-policy.md @@ -20,13 +20,19 @@ Specific cluster deployment tools may place additional restrictions on version s ## Supported versions -Kubernetes versions are expressed as **x.y.z**, where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology. -For more information, see [Kubernetes Release Versioning](https://git.k8s.io/sig-release/release-engineering/versioning.md#kubernetes-release-versioning). +Kubernetes versions are expressed as **x.y.z**, where **x** is the major version, +**y** is the minor version, and **z** is the patch version, following +[Semantic Versioning](https://semver.org/) terminology. For more information, see +[Kubernetes Release Versioning](https://git.k8s.io/sig-release/release-engineering/versioning.md#kubernetes-release-versioning). -The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive [approximately 1 year of patch support](/releases/patch-releases/#support-period). Kubernetes 1.18 and older received approximately 9 months of patch support. +The Kubernetes project maintains release branches for the most recent three minor releases +({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). +Kubernetes 1.19 and newer receive [approximately 1 year of patch support](/releases/patch-releases/#support-period). +Kubernetes 1.18 and older received approximately 9 months of patch support. -Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility. -Patch releases are cut from those branches at a [regular cadence](/releases/patch-releases/#cadence), plus additional urgent releases, when required. +Applicable fixes, including security fixes, may be backported to those three release branches, +depending on severity and feasibility. Patch releases are cut from those branches at a +[regular cadence](/releases/patch-releases/#cadence), plus additional urgent releases, when required. The [Release Managers](/releases/release-managers/) group owns this decision. @@ -36,7 +42,8 @@ For more information, see the Kubernetes [patch releases](/releases/patch-releas ### kube-apiserver -In [highly-available (HA) clusters](/docs/setup/production-environment/tools/kubeadm/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version. +In [highly-available (HA) clusters](/docs/setup/production-environment/tools/kubeadm/high-availability/), +the newest and oldest `kube-apiserver` instances must be within one minor version. Example: @@ -51,7 +58,8 @@ Example: Example: * `kube-apiserver` is at **{{< skew currentVersion >}}** -* `kubelet` is supported at **{{< skew currentVersion >}}**, **{{< skew currentVersionAddMinor -1 >}}**, **{{< skew currentVersionAddMinor -2 >}}**, and **{{< skew currentVersionAddMinor -3 >}}** +* `kubelet` is supported at **{{< skew currentVersion >}}**, **{{< skew currentVersionAddMinor -1 >}}**, + **{{< skew currentVersionAddMinor -2 >}}**, and **{{< skew currentVersionAddMinor -3 >}}** {{< note >}} If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kubelet` versions. @@ -60,18 +68,24 @@ If version skew exists between `kube-apiserver` instances in an HA cluster, this Example: * `kube-apiserver` instances are at **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}** -* `kubelet` is supported at **{{< skew currentVersionAddMinor -1 >}}**, **{{< skew currentVersionAddMinor -2 >}}**, and **{{< skew currentVersionAddMinor -3 >}}** (**{{< skew currentVersion >}}** is not supported because that would be newer than the `kube-apiserver` instance at version **{{< skew currentVersionAddMinor -1 >}}**) +* `kubelet` is supported at **{{< skew currentVersionAddMinor -1 >}}**, **{{< skew currentVersionAddMinor -2 >}}**, + and **{{< skew currentVersionAddMinor -3 >}}** (**{{< skew currentVersion >}}** is not supported because that + would be newer than the `kube-apiserver` instance at version **{{< skew currentVersionAddMinor -1 >}}**) ### kube-proxy * `kube-proxy` must not be newer than `kube-apiserver`. -* `kube-proxy` may be up to three minor versions older than `kube-apiserver` (`kube-proxy` < 1.25 may only be up to two minor versions older than `kube-apiserver`). -* `kube-proxy` may be up to three minor versions older or newer than the `kubelet` instance it runs alongside (`kube-proxy` < 1.25 may only be up to two minor versions older or newer than the `kubelet` instance it runs alongside). +* `kube-proxy` may be up to three minor versions older than `kube-apiserver` + (`kube-proxy` < 1.25 may only be up to two minor versions older than `kube-apiserver`). +* `kube-proxy` may be up to three minor versions older or newer than the `kubelet` instance + it runs alongside (`kube-proxy` < 1.25 may only be up to two minor versions older or newer + than the `kubelet` instance it runs alongside). Example: * `kube-apiserver` is at **{{< skew currentVersion >}}** -* `kube-proxy` is supported at **{{< skew currentVersion >}}**, **{{< skew currentVersionAddMinor -1 >}}**, **{{< skew currentVersionAddMinor -2 >}}**, and **{{< skew currentVersionAddMinor -3 >}}** +* `kube-proxy` is supported at **{{< skew currentVersion >}}**, **{{< skew currentVersionAddMinor -1 >}}**, + **{{< skew currentVersionAddMinor -2 >}}**, and **{{< skew currentVersionAddMinor -3 >}}** {{< note >}} If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kube-proxy` versions. @@ -80,26 +94,36 @@ If version skew exists between `kube-apiserver` instances in an HA cluster, this Example: * `kube-apiserver` instances are at **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}** -* `kube-proxy` is supported at **{{< skew currentVersionAddMinor -1 >}}**, **{{< skew currentVersionAddMinor -2 >}}**, and **{{< skew currentVersionAddMinor -3 >}}** (**{{< skew currentVersion >}}** is not supported because that would be newer than the `kube-apiserver` instance at version **{{< skew currentVersionAddMinor -1 >}}**) +* `kube-proxy` is supported at **{{< skew currentVersionAddMinor -1 >}}**, **{{< skew currentVersionAddMinor -2 >}}**, + and **{{< skew currentVersionAddMinor -3 >}}** (**{{< skew currentVersion >}}** is not supported because that would + be newer than the `kube-apiserver` instance at version **{{< skew currentVersionAddMinor -1 >}}**) ### kube-controller-manager, kube-scheduler, and cloud-controller-manager -`kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` must not be newer than the `kube-apiserver` instances they communicate with. They are expected to match the `kube-apiserver` minor version, but may be up to one minor version older (to allow live upgrades). +`kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` must not be newer than the +`kube-apiserver` instances they communicate with. They are expected to match the `kube-apiserver` minor version, +but may be up to one minor version older (to allow live upgrades). Example: * `kube-apiserver` is at **{{< skew currentVersion >}}** -* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}** +* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported + at **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}** {{< note >}} -If version skew exists between `kube-apiserver` instances in an HA cluster, and these components can communicate with any `kube-apiserver` instance in the cluster (for example, via a load balancer), this narrows the allowed versions of these components. +If version skew exists between `kube-apiserver` instances in an HA cluster, and these components +can communicate with any `kube-apiserver` instance in the cluster (for example, via a load balancer), +this narrows the allowed versions of these components. {{< /note >}} Example: * `kube-apiserver` instances are at **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}** -* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` communicate with a load balancer that can route to any `kube-apiserver` instance -* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **{{< skew currentVersionAddMinor -1 >}}** (**{{< skew currentVersion >}}** is not supported because that would be newer than the `kube-apiserver` instance at version **{{< skew currentVersionAddMinor -1 >}}**) +* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` communicate with a load balancer + that can route to any `kube-apiserver` instance +* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at + **{{< skew currentVersionAddMinor -1 >}}** (**{{< skew currentVersion >}}** is not supported + because that would be newer than the `kube-apiserver` instance at version **{{< skew currentVersionAddMinor -1 >}}**) ### kubectl @@ -108,7 +132,8 @@ Example: Example: * `kube-apiserver` is at **{{< skew currentVersion >}}** -* `kubectl` is supported at **{{< skew currentVersionAddMinor 1 >}}**, **{{< skew currentVersion >}}**, and **{{< skew currentVersionAddMinor -1 >}}** +* `kubectl` is supported at **{{< skew currentVersionAddMinor 1 >}}**, **{{< skew currentVersion >}}**, + and **{{< skew currentVersionAddMinor -1 >}}** {{< note >}} If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the supported `kubectl` versions. @@ -117,21 +142,24 @@ If version skew exists between `kube-apiserver` instances in an HA cluster, this Example: * `kube-apiserver` instances are at **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}** -* `kubectl` is supported at **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}** (other versions would be more than one minor version skewed from one of the `kube-apiserver` components) +* `kubectl` is supported at **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}** + (other versions would be more than one minor version skewed from one of the `kube-apiserver` components) ## Supported component upgrade order -The supported version skew between components has implications on the order in which components must be upgraded. -This section describes the order in which components must be upgraded to transition an existing cluster from version **{{< skew currentVersionAddMinor -1 >}}** to version **{{< skew currentVersion >}}**. +The supported version skew between components has implications on the order +in which components must be upgraded. This section describes the order in +which components must be upgraded to transition an existing cluster from version +**{{< skew currentVersionAddMinor -1 >}}** to version **{{< skew currentVersion >}}**. Optionally, when preparing to upgrade, the Kubernetes project recommends that you do the following to benefit from as many regression and bug fixes as -possible during your upgrade: +possible during your upgrade: -* Ensure that components are on the most recent patch version of your current - minor version. -* Upgrade components to the most recent patch version of the target minor - version. +* Ensure that components are on the most recent patch version of your current + minor version. +* Upgrade components to the most recent patch version of the target minor + version. For example, if you're running version {{}}, ensure that you're on the most recent patch version. Then, upgrade to the most @@ -142,12 +170,19 @@ recent patch version of {{}}. Pre-requisites: * In a single-instance cluster, the existing `kube-apiserver` instance is **{{< skew currentVersionAddMinor -1 >}}** -* In an HA cluster, all `kube-apiserver` instances are at **{{< skew currentVersionAddMinor -1 >}}** or **{{< skew currentVersion >}}** (this ensures maximum skew of 1 minor version between the oldest and newest `kube-apiserver` instance) -* The `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` instances that communicate with this server are at version **{{< skew currentVersionAddMinor -1 >}}** (this ensures they are not newer than the existing API server version, and are within 1 minor version of the new API server version) -* `kubelet` instances on all nodes are at version **{{< skew currentVersionAddMinor -1 >}}** or **{{< skew currentVersionAddMinor -2 >}}** (this ensures they are not newer than the existing API server version, and are within 2 minor versions of the new API server version) +* In an HA cluster, all `kube-apiserver` instances are at **{{< skew currentVersionAddMinor -1 >}}** or + **{{< skew currentVersion >}}** (this ensures maximum skew of 1 minor version between the oldest and newest `kube-apiserver` instance) +* The `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` instances that + communicate with this server are at version **{{< skew currentVersionAddMinor -1 >}}** + (this ensures they are not newer than the existing API server version, and are within 1 minor version of the new API server version) +* `kubelet` instances on all nodes are at version **{{< skew currentVersionAddMinor -1 >}}** or **{{< skew currentVersionAddMinor -2 >}}** + (this ensures they are not newer than the existing API server version, and are within 2 minor versions of the new API server version) * Registered admission webhooks are able to handle the data the new `kube-apiserver` instance will send them: - * `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` objects are updated to include any new versions of REST resources added in **{{< skew currentVersion >}}** (or use the [`matchPolicy: Equivalent` option](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy) available in v1.15+) - * The webhooks are able to handle any new versions of REST resources that will be sent to them, and any new fields added to existing versions in **{{< skew currentVersion >}}** + * `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` objects are updated to include + any new versions of REST resources added in **{{< skew currentVersion >}}** + (or use the [`matchPolicy: Equivalent` option](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy) available in v1.15+) + * The webhooks are able to handle any new versions of REST resources that will be sent to them, + and any new fields added to existing versions in **{{< skew currentVersion >}}** Upgrade `kube-apiserver` to **{{< skew currentVersion >}}** @@ -161,7 +196,9 @@ require `kube-apiserver` to not skip minor versions when upgrading, even in sing Pre-requisites: -* The `kube-apiserver` instances these components communicate with are at **{{< skew currentVersion >}}** (in HA clusters in which these control plane components can communicate with any `kube-apiserver` instance in the cluster, all `kube-apiserver` instances must be upgraded before upgrading these components) +* The `kube-apiserver` instances these components communicate with are at **{{< skew currentVersion >}}** + (in HA clusters in which these control plane components can communicate with any `kube-apiserver` + instance in the cluster, all `kube-apiserver` instances must be upgraded before upgrading these components) Upgrade `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` to **{{< skew currentVersion >}}**. There is no @@ -175,7 +212,8 @@ Pre-requisites: * The `kube-apiserver` instances the `kubelet` communicates with are at **{{< skew currentVersion >}}** -Optionally upgrade `kubelet` instances to **{{< skew currentVersion >}}** (or they can be left at **{{< skew currentVersionAddMinor -1 >}}**, **{{< skew currentVersionAddMinor -2 >}}**, or **{{< skew currentVersionAddMinor -3 >}}**) +Optionally upgrade `kubelet` instances to **{{< skew currentVersion >}}** (or they can be left at +**{{< skew currentVersionAddMinor -1 >}}**, **{{< skew currentVersionAddMinor -2 >}}**, or **{{< skew currentVersionAddMinor -3 >}}**) {{< note >}} Before performing a minor version `kubelet` upgrade, [drain](/docs/tasks/administer-cluster/safely-drain-node/) pods from that node. @@ -183,7 +221,8 @@ In-place minor version `kubelet` upgrades are not supported. {{}} {{< warning >}} -Running a cluster with `kubelet` instances that are persistently three minor versions behind `kube-apiserver` means they must be upgraded before the control plane can be upgraded. +Running a cluster with `kubelet` instances that are persistently three minor versions behind +`kube-apiserver` means they must be upgraded before the control plane can be upgraded. {{}} ### kube-proxy @@ -192,8 +231,11 @@ Pre-requisites: * The `kube-apiserver` instances `kube-proxy` communicates with are at **{{< skew currentVersion >}}** -Optionally upgrade `kube-proxy` instances to **{{< skew currentVersion >}}** (or they can be left at **{{< skew currentVersionAddMinor -1 >}}**, **{{< skew currentVersionAddMinor -2 >}}**, or **{{< skew currentVersionAddMinor -3 >}}**) +Optionally upgrade `kube-proxy` instances to **{{< skew currentVersion >}}** +(or they can be left at **{{< skew currentVersionAddMinor -1 >}}**, **{{< skew currentVersionAddMinor -2 >}}**, +or **{{< skew currentVersionAddMinor -3 >}}**) {{< warning >}} -Running a cluster with `kube-proxy` instances that are persistently three minor versions behind `kube-apiserver` means they must be upgraded before the control plane can be upgraded. +Running a cluster with `kube-proxy` instances that are persistently three minor versions behind +`kube-apiserver` means they must be upgraded before the control plane can be upgraded. {{}}