Merge pull request #44066 from sftim/20231124_revise_download_page

Revise detail about container image downloads

Author: k8s-ci-robot

content/en/releases/download.md

@@ -28,15 +28,11 @@ Find your preferred operating system below.
 - [Install kubectl on macOS](/docs/tasks/tools/install-kubectl-macos)
 - [Install kubectl on Windows](/docs/tasks/tools/install-kubectl-windows)
 
-## Container Images
+## Container images
 
 All Kubernetes container images are deployed to the
 `registry.k8s.io` container image registry.
 
-For Kubernetes {{< param "version" >}}, the following
-container images are signed using [sigstore](https://sigstore.dev)
-signatures:
-
 | Container Image                                                           | Supported Architectures           |
 | ------------------------------------------------------------------------- | --------------------------------- |
 | registry.k8s.io/kube-apiserver:v{{< skew currentPatchVersion >}}          | amd64, arm, arm64, ppc64le, s390x |
@@ -45,6 +41,14 @@ signatures:
 | registry.k8s.io/kube-scheduler:v{{< skew currentPatchVersion >}}          | amd64, arm, arm64, ppc64le, s390x |
 | registry.k8s.io/conformance:v{{< skew currentPatchVersion >}}             | amd64, arm, arm64, ppc64le, s390x |
 
+### Container image architectures
+
+All container images are available for multiple architectures, whereas the
+container runtime should choose the correct one based on the underlying
+platform. It is also possible to pull a dedicated architecture by suffixing the
+container image name, for example
+`registry.k8s.io/kube-apiserver-arm64:v{{< skew currentPatchVersion >}}`.
+
 ### Container image signatures
 
 {{< feature-state for_k8s_version="v1.26" state="beta" >}}
@@ -59,16 +63,6 @@ More information about this problem is available in the corresponding
 [GitHub issue](https://github.com/kubernetes/registry.k8s.io/issues/187).
 {{< /note >}}
 
-### Container image architectures
-
-
-All container images are available for multiple architectures, whereas the
-container runtime should choose the correct one based on the underlying
-platform. It is also possible to pull a dedicated architecture by suffixing the
-container image name, for example
-`registry.k8s.io/kube-apiserver-arm64:v{{< skew currentPatchVersion >}}`. All
-those derivations are signed in the same way as the multi-architecture manifest lists.
-
 The Kubernetes project publishes a list of signed Kubernetes container images
 in [SPDX 2.3](https://spdx.dev/specifications/) format.
 You can fetch that list using:
@@ -77,13 +71,12 @@ You can fetch that list using:
 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.
-
 To manually verify signed container images of Kubernetes core components, refer to
 [Verify Signed Container Images](/docs/tasks/administer-cluster/verify-signed-artifacts).
 
+If you pull a container image for a specific architecture, the single-architecture image
+is signed in the same way as for the multi-architecture manifest lists.
+
 ## Binaries
 
 {{< release-binaries >}}