Merge pull request #35229 from sethmccombs/merged-main-dev-1.25

Merge main into dev-1.25 branch: July 21st

config.toml

@@ -139,10 +139,10 @@ time_format_default = "January 02, 2006 at 3:04 PM PST"
 description = "Production-Grade Container Orchestration"
 showedit = true
 
-latest = "v1.24"
+latest = "v1.25"
 
-fullversion = "v1.24.0"
-version = "v1.24"
+fullversion = "v1.25.0"
+version = "v1.25"
 githubbranch = "main"
 docsbranch = "main"
 deprecated = false
@@ -179,40 +179,40 @@ js = [
 ]
 
 [[params.versions]]
-fullversion = "v1.24.0"
-version = "v1.24"
-githubbranch = "v1.24.0"
+fullversion = "v1.25.0"
+version = "v1.25"
+githubbranch = "v1.25.0"
 docsbranch = "main"
 url = "https://kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.23.6"
+fullversion = "v1.24.2"
+version = "v1.24"
+githubbranch = "v1.24.2"
+docsbranch = "release-1.24"
+url = "https://v1-24.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.23.8"
 version = "v1.23"
-githubbranch = "v1.23.6"
+githubbranch = "v1.23.8"
 docsbranch = "release-1.23"
 url = "https://v1-23.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.22.9"
+fullversion = "v1.22.11"
 version = "v1.22"
-githubbranch = "v1.22.9"
+githubbranch = "v1.22.11"
 docsbranch = "release-1.22"
 url = "https://v1-22.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.21.12"
+fullversion = "v1.21.14"
 version = "v1.21"
-githubbranch = "v1.21.12"
+githubbranch = "v1.21.14"
 docsbranch = "release-1.21"
 url = "https://v1-21.docs.kubernetes.io"
 
-[[params.versions]]
-fullversion = "v1.20.15"
-version = "v1.20"
-githubbranch = "v1.20.15"
-docsbranch = "release-1.20"
-url = "https://v1-20.docs.kubernetes.io"
-
 # User interface configuration
 [params.ui]
 # Enable to show the side bar menu in its compact state.

content/en/docs/reference/command-line-tools-reference/feature-gates.md

@@ -178,7 +178,8 @@ different Kubernetes components.
 | `RemainingItemCount` | `true` | Beta | 1.16 | |
 | `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |
 | `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | |
-| `SeccompDefault` | `false` | Alpha | 1.22 | |
+| `SeccompDefault` | `false` | Alpha | 1.22 | 1.24 |
+| `SeccompDefault` | `true` | Beta | 1.25 | |
 | `ServerSideFieldValidation` | `false` | Alpha | 1.23 | - |
 | `ServiceInternalTrafficPolicy` | `false` | Alpha | 1.21 | 1.21 |
 | `ServiceInternalTrafficPolicy` | `true` | Beta | 1.22 | |

content/en/docs/reference/labels-annotations-taints/_index.md

@@ -713,14 +713,3 @@ Used on: Node
 Example: `node-role.kubernetes.io/control-plane:NoSchedule`
 
 Taint that kubeadm applies on control plane nodes to allow only critical workloads to schedule on them.
-
-### node-role.kubernetes.io/master
-
-Used on: Node
-
-Example: `node-role.kubernetes.io/master:NoSchedule`
-
-Taint that kubeadm applies on control plane nodes to allow only critical workloads to schedule on them.
-
-{{< note >}} Starting in v1.20, this taint is deprecated in favor of `node-role.kubernetes.io/control-plane`
-and will be removed in v1.25.{{< /note >}}

content/en/docs/reference/setup-tools/kubeadm/implementation-details.md

@@ -199,7 +199,7 @@ Static Pod manifest share a set of common properties:
 
 Please note that:
 
-1. All images will be pulled from k8s.gcr.io by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository
+1. All images will be pulled from registry.k8s.io by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository
 2. In case of kubeadm is executed in the `--dry-run` mode, static Pods files are written in a temporary folder
 3. Static Pod manifest generation for control plane components can be invoked individually with the [`kubeadm init phase control-plane all`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-control-plane) command
 
@@ -289,7 +289,7 @@ a local etcd instance running in a Pod with following attributes:
 
 Please note that:
 
-1. The etcd image will be pulled from `k8s.gcr.io` by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository
+1. The etcd image will be pulled from `registry.k8s.io` by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository
 2. in case of kubeadm is executed in the `--dry-run` mode, the etcd static Pod manifest is written in a temporary folder
 3. Static Pod manifest generation for local etcd can be invoked individually with the [`kubeadm init phase etcd local`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-etcd) command
 
@@ -319,12 +319,10 @@ Please note that:
 As soon as the control plane is available, kubeadm executes following actions:
 
 - Labels the node as control-plane with `node-role.kubernetes.io/control-plane=""`
-- Taints the node with `node-role.kubernetes.io/master:NoSchedule` and `node-role.kubernetes.io/control-plane:NoSchedule`
+- Taints the node with `node-role.kubernetes.io/control-plane:NoSchedule`
 
-Please note that:
-
-1. The `node-role.kubernetes.io/master` taint is deprecated and will be removed in kubeadm version 1.25
-1. Mark control-plane phase phase can be invoked individually with the [`kubeadm init phase mark-control-plane`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-mark-control-plane) command
+Please note that the phase to mark the control-plane phase phase can be invoked
+individually with the [`kubeadm init phase mark-control-plane`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-mark-control-plane) command.
 
 ### Configure TLS-Bootstrapping for node joining
 

content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md

@@ -155,15 +155,15 @@ directly to kubeadm is not supported. Instead, it is possible to pass them by
 List of feature gates:
 
 {{< table caption="kubeadm feature gates" >}}
-Feature | Default | Alpha | Beta
-:-------|:--------|:------|:-----
-`PublicKeysECDSA` | `false` | 1.19 | -
-`RootlessControlPlane` | `false` | 1.22 | -
-`UnversionedKubeletConfigMap` | `true` | 1.22 | 1.23
+Feature | Default | Alpha | Beta | GA
+:-------|:--------|:------|:-----|:----
+`PublicKeysECDSA` | `false` | 1.19 | - | -
+`RootlessControlPlane` | `false` | 1.22 | - | -
+`UnversionedKubeletConfigMap` | `true` | 1.22 | 1.23 | 1.25
 {{< /table >}}
 
 {{< note >}}
-Once a feature gate goes GA it is removed from this list as its value becomes locked to `true` by default.
+Once a feature gate goes GA its value becomes locked to `true` by default.
 {{< /note >}}
 
 Feature gate descriptions:
@@ -189,10 +189,6 @@ or `kubeadm upgrade apply`), kubeadm respects the value of `UnversionedKubeletCo
 (during `kubeadm join`, `kubeadm reset`, `kubeadm upgrade ...`), kubeadm attempts to use unversioned ConfigMap name first;
 if that does not succeed, kubeadm falls back to using the legacy (versioned) name for that ConfigMap.
 
-{{< note >}}
-Setting `UnversionedKubeletConfigMap` to `false` is supported but **deprecated**.
-{{< /note >}}
-
 ### Adding kube-proxy parameters {#kube-proxy}
 
 For information about kube-proxy parameters in the kubeadm configuration see:
@@ -220,11 +216,11 @@ kubeadm config images pull
 You can pass `--config` to the above commands with a [kubeadm configuration file](#config-file)
 to control the `kubernetesVersion` and `imageRepository` fields.
 
-All default `k8s.gcr.io` images that kubeadm requires support multiple architectures.
+All default `registry.k8s.io` images that kubeadm requires support multiple architectures.
 
 ### Using custom images {#custom-images}
 
-By default, kubeadm pulls images from `k8s.gcr.io`. If the
+By default, kubeadm pulls images from `registry.k8s.io`. If the
 requested Kubernetes version is a CI label (such as `ci/latest`)
 `gcr.io/k8s-staging-ci-images` is used.
 
@@ -233,18 +229,18 @@ Allowed customization are:
 
 * To provide `kubernetesVersion` which affects the version of the images.
 * To provide an alternative `imageRepository` to be used instead of
-  `k8s.gcr.io`.
+  `registry.k8s.io`.
 * To provide a specific `imageRepository` and `imageTag` for etcd or CoreDNS.
 
-Image paths between the default `k8s.gcr.io` and a custom repository specified using
+Image paths between the default `registry.k8s.io` and a custom repository specified using
 `imageRepository` may differ for backwards compatibility reasons. For example,
-one image might have a subpath at `k8s.gcr.io/subpath/image`, but be defaulted
+one image might have a subpath at `registry.k8s.io/subpath/image`, but be defaulted
 to `my.customrepository.io/image` when using a custom repository.
 
 To ensure you push the images to your custom repository in paths that kubeadm
 can consume, you must:
 
-* Pull images from the defaults paths at `k8s.gcr.io` using `kubeadm config images {list|pull}`.
+* Pull images from the defaults paths at `registry.k8s.io` using `kubeadm config images {list|pull}`.
 * Push images to the paths from `kubeadm config images list --config=config.yaml`,
 where `config.yaml` contains the custom `imageRepository`, and/or `imageTag`
 for etcd and CoreDNS.

content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md

@@ -134,13 +134,13 @@ etcd:
       election-timeout: 1000
 ```
 
-## Customizing the control plane with patches {#patches}
+## Customizing with patches {#patches}
 
 {{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 Kubeadm allows you to pass a directory with patch files to `InitConfiguration` and `JoinConfiguration`
-on individual nodes. These patches can be used as the last customization step before the control
-plane component manifests are written to disk.
+on individual nodes. These patches can be used as the last customization step before component configuration
+is written to disk.
 
 You can pass this file to `kubeadm init` with `--config <YOUR CONFIG YAML>`:
 
@@ -168,7 +168,8 @@ patches:
 The directory must contain files named `target[suffix][+patchtype].extension`.
 For example, `kube-apiserver0+merge.yaml` or just `etcd.json`.
 
-- `target` can be one of `kube-apiserver`, `kube-controller-manager`, `kube-scheduler` and `etcd`.
+- `target` can be one of `kube-apiserver`, `kube-controller-manager`, `kube-scheduler`, `etcd`
+and `kubeletconfiguration`.
 - `patchtype` can be one of `strategic`, `merge` or `json` and these must match the patching formats
 [supported by kubectl](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch).
 The default `patchtype` is `strategic`.
@@ -183,20 +184,22 @@ flag, which must point to the same directory. `kubeadm upgrade` currently does n
 API structure that can be used for the same purpose.
 {{< /note >}}
 
-## Customizing the kubelet
+## Customizing the kubelet {#kubelet}
 
-To customize the kubelet you can add a `KubeletConfiguration` next to the `ClusterConfiguration` or
-`InitConfiguration` separated by `---` within the same configuration file. This file can then be passed to `kubeadm init`.
+To customize the kubelet you can add a [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)
+next to the `ClusterConfiguration` or `InitConfiguration` separated by `---` within the same configuration file.
+This file can then be passed to `kubeadm init` and kubeadm will apply the same base `KubeletConfiguration`
+to all nodes in the cluster.
 
-{{< note >}}
-kubeadm applies the same `KubeletConfiguration` to all nodes in the cluster. To apply node
-specific settings you can use kubelet flags as overrides by passing them in the `nodeRegistration.kubeletExtraArgs`
-field supported by both `InitConfiguration` and `JoinConfiguration`. Some kubelet flags are deprecated,
-so check their status in the [kubelet reference documentation](/docs/reference/command-line-tools-reference/kubelet)
-before using them.
-{{< /note >}}
+For applying instance-specific configuration over the base `KubeletConfiguration` you can use the
+[`kubeletconfiguration` patch target](#patches).
 
-For more details see [Configuring each kubelet in your cluster using kubeadm](/docs/setup/production-environment/tools/kubeadm/kubelet-integration)
+Alternatively, you can use kubelet flags as overrides by passing them in the
+`nodeRegistration.kubeletExtraArgs` field supported by both `InitConfiguration` and `JoinConfiguration`.
+Some kubelet flags are deprecated, so check their status in the
+[kubelet reference documentation](/docs/reference/command-line-tools-reference/kubelet) before using them.
+
+For additional details see [Configuring each kubelet in your cluster using kubeadm](/docs/setup/production-environment/tools/kubeadm/kubelet-integration)
 
 ## Customizing kube-proxy
 

content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md

@@ -88,7 +88,7 @@ After you initialize your control-plane, the kubelet runs normally.
 ### Preparing the required container images
 
 This step is optional and only applies in case you wish `kubeadm init` and `kubeadm join`
-to not download the default container images which are hosted at `k8s.gcr.io`.
+to not download the default container images which are hosted at `registry.k8s.io`.
 
 Kubeadm has commands that can help you pre-pull the required images
 when creating a cluster without an internet connection on its nodes.
@@ -305,7 +305,7 @@ reasons. If you want to be able to schedule Pods on the control plane nodes,
 for example for a single machine Kubernetes cluster, run:
 
 ```bash
-kubectl taint nodes --all node-role.kubernetes.io/control-plane- node-role.kubernetes.io/master-
+kubectl taint nodes --all node-role.kubernetes.io/control-plane-
 ```
 
 The output will look something like:
@@ -315,14 +315,9 @@ node "test-01" untainted
 ...
 ```
 
-This will remove the `node-role.kubernetes.io/control-plane` and
-`node-role.kubernetes.io/master` taints from any nodes that have them,
-including the control plane nodes, meaning that the scheduler will then be able
-to schedule Pods everywhere.
-
-{{< note >}}
-The `node-role.kubernetes.io/master` taint is deprecated and kubeadm will stop using it in version 1.25.
-{{< /note >}}
+This will remove the `node-role.kubernetes.io/control-plane:NoSchedule` taint
+from any nodes that have it, including the control plane nodes, meaning that the
+scheduler will then be able to schedule Pods everywhere.
 
 ### Joining your nodes {#join-nodes}
 

content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md

@@ -97,7 +97,7 @@ _See [External etcd topology](/docs/setup/production-environment/tools/kubeadm/h
 
 ### Container images
 
-Each host should have access read and fetch images from the Kubernetes container image registry, `k8s.gcr.io`.
+Each host should have access read and fetch images from the Kubernetes container image registry, `registry.k8s.io`.
 If you want to deploy a highly-available cluster where the hosts do not have access to pull images, this is possible. You must ensure by some other means that the correct container images are already available on the relevant hosts.
 
 ### Command line interface {#kubectl}

content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md

@@ -87,20 +87,21 @@ networking, or other host-specific parameters. The following list provides a few
 - To specify the container runtime you must set its endpoint with the
 `--container-runtime-endpoint=<path>` flag.
 
-You can specify these flags by configuring an individual kubelet's configuration in your service manager,
-such as systemd.
+The recommended way of applying such instance-specific configuration is by using
+[`KubeletConfiguration` patches](/docs/setup/production-environment/tools/kubeadm/control-plane-flags#patches).
 
 ## Configure kubelets using kubeadm
 
-It is possible to configure the kubelet that kubeadm will start if a custom `KubeletConfiguration`
+It is possible to configure the kubelet that kubeadm will start if a custom
+[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)
 API object is passed with a configuration file like so `kubeadm ... --config some-config-file.yaml`.
 
 By calling `kubeadm config print init-defaults --component-configs KubeletConfiguration` you can
 see all the default values for this structure.
 
-Also have a look at the
-[reference for the KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/)
-for more information on the individual fields.
+It is also possible to apply instance-specific patches over the base `KubeletConfiguration`.
+Have a look at [Customizing the kubelet](/docs/setup/production-environment/tools/kubeadm/control-plane-flags#customizing-the-kubelet)
+for more details.
 
 ### Workflow when using `kubeadm init`
 

content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md

@@ -31,7 +31,7 @@ etcd cluster of three members that can be used by kubeadm during cluster creatio
   the kubeadm config file.
 * Each host must have systemd and a bash compatible shell installed.
 * Each host must [have a container runtime, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
-* Each host should have access to the Kubernetes container image registry (`k8s.gcr.io`) or list/pull the required etcd image using
+* Each host should have access to the Kubernetes container image registry (`registry.k8s.io`) or list/pull the required etcd image using
 `kubeadm config images list/pull`. This guide will setup etcd instances as
 [static pods](/docs/tasks/configure-pod-container/static-pod/) managed by a kubelet.
 * Some infrastructure to copy files between hosts. For example `ssh` and `scp`
@@ -276,7 +276,7 @@ on Kubernetes dual-stack support see [Dual-stack support with kubeadm](/docs/set
     ```sh
     docker run --rm -it \
     --net host \
-    -v /etc/kubernetes:/etc/kubernetes k8s.gcr.io/etcd:${ETCD_TAG} etcdctl \
+    -v /etc/kubernetes:/etc/kubernetes registry.k8s.io/etcd:${ETCD_TAG} etcdctl \
     --cert /etc/kubernetes/pki/etcd/peer.crt \
     --key /etc/kubernetes/pki/etcd/peer.key \
     --cacert /etc/kubernetes/pki/etcd/ca.crt \

content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md

@@ -351,7 +351,7 @@ A known solution is to patch the kube-proxy DaemonSet to allow scheduling it on
 nodes regardless of their conditions, keeping it off of other nodes until their initial guarding
 conditions abate:
 ```
-kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/master" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/control-plane" } ] } } } }'
+kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/control-plane" } ] } } } }'
 ```
 
 The tracking issue for this problem is [here](https://github.com/kubernetes/kubeadm/issues/1027).

content/en/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors.md

@@ -13,11 +13,6 @@ To avoid CNI plugin-related errors, verify that you are using or upgrading to a
 container runtime that has been tested to work correctly with your version of
 Kubernetes.
 
-For example, the following container runtimes are being prepared, or have already been prepared, for Kubernetes v1.24:
-
-* containerd v1.6.4 and later, v1.5.11 and later
-* The CRI-O v1.24.0 and later
-
 ## About the "Incompatible CNI versions" and "Failed to destroy network for sandbox" errors
 
 Service issues exist for pod CNI network setup and tear down in containerd

content/en/docs/tutorials/security/seccomp.md

@@ -39,7 +39,7 @@ profiles that give only the necessary privileges to your container processes.
 In order to complete all steps in this tutorial, you must install
 [kind](/docs/tasks/tools/#kind) and [kubectl](/docs/tasks/tools/#kubectl).
 
-This tutorial shows some examples that are still alpha (since v1.22) and
+This tutorial shows some examples that are still beta (since v1.25) and
 others that use only generally available seccomp functionality. You should
 make sure that your cluster is
 [configured correctly](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)
@@ -112,7 +112,7 @@ See [Nodes](https://kind.sigs.k8s.io/docs/user/configuration/#nodes) within the
 kind documentation about configuration for more details on this.
 This tutorial assumes you are using Kubernetes {{< param "version" >}}.
 
-As an alpha feature, you can configure Kubernetes to use the profile that the
+As a beta feature, you can configure Kubernetes to use the profile that the
 {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}
 prefers by default, rather than falling back to `Unconfined`.
 If you want to try that, see
@@ -159,11 +159,12 @@ running within kind.
 
 ## Enable the use of `RuntimeDefault` as the default seccomp profile for all workloads
 
-{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
+{{< feature-state state="beta" for_k8s_version="v1.25" >}}
 
-`SeccompDefault` is an optional kubelet
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates) as
-well as corresponding `--seccomp-default`
+To use seccomp profile defaulting, you must run the kubelet with the `SeccompDefault`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) enabled
+(this is the default). You must also explicitly enable the defaulting behavior for each
+node where you want to use this with the corresponding `--seccomp-default`
 [command line flag](/docs/reference/command-line-tools-reference/kubelet).
 Both have to be enabled simultaneously to use the feature.
 
@@ -196,12 +197,20 @@ If you were introducing this feature into production-like cluster, the Kubernete
 recommends that you enable this feature gate on a subset of your nodes and then
 test workload execution before rolling the change out cluster-wide.
 
-More detailed information about a possible upgrade and downgrade strategy can be
-found in the [related Kubernetes Enhancement Proposal (KEP)](https://github.com/kubernetes/enhancements/tree/a70cc18/keps/sig-node/2413-seccomp-by-default#upgrade--downgrade-strategy).
+You can find more detailed information about a possible upgrade and downgrade strategy
+in the related Kubernetes Enhancement Proposal (KEP):
+[Enable seccomp by default](https://github.com/kubernetes/enhancements/tree/9a124fd29d1f9ddf2ff455c49a630e3181992c25/keps/sig-node/2413-seccomp-by-default#upgrade--downgrade-strategy).
 
-Since the feature is in alpha state it is disabled per default. To enable it,
-pass the flags `--feature-gates=SeccompDefault=true --seccomp-default` to the
-`kubelet` CLI or enable it via the [kubelet configuration
+Kubernetes {{< skew currentVersion >}} lets you configure the seccomp profile
+that applies when the spec for a Pod doesn't define a specific seccomp profile.
+This is a beta feature and the corresponding `SeccompDefault` [feature
+gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled by
+default. However, you still need to enable this defaulting for each node where
+you would like to use it.
+
+If you are running a Kubernetes {{< skew currentVersion >}} cluster and want to
+enable the feature, either run the kubelet with the `--seccomp-default` command
+line flag, or enable it through the [kubelet configuration
 file](/docs/tasks/administer-cluster/kubelet-config-file/). To enable the
 feature gate in [kind](https://kind.sigs.k8s.io), ensure that `kind` provides
 the minimum required Kubernetes version and enables the `SeccompDefault` feature