Merge pull request #31225 from kubernetes/dev-1.24

Official 1.24 Release Docs

OWNERS_ALIASES

@@ -25,6 +25,7 @@ aliases:
     - jlbutler
     - kbhawkey
     - natalisucks
+    - nate-double-u # RT 1.24 Docs Lead
     - onlydole
     - pi-victor
     - reylejano

api-ref-assets/config/fields.yaml

@@ -405,6 +405,7 @@
   - fields:
     - jobTemplate
     - schedule
+    - timeZone
     - concurrencyPolicy
     - startingDeadlineSeconds
     - suspend

api-ref-assets/config/toc.yaml

@@ -124,7 +124,7 @@ parts:
     version: v1
   - name: CSIStorageCapacity
     group: storage.k8s.io
-    version: v1beta1
+    version: v1
 - name: Authentication Resources
   chapters:
   - name: ServiceAccount

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.23"
+latest = "v1.24"
 
-fullversion = "v1.23.0"
-version = "v1.23"
+fullversion = "v1.24.0"
+version = "v1.24"
 githubbranch = "main"
 docsbranch = "main"
 deprecated = false
@@ -179,44 +179,46 @@ js = [
 ]
 
 [[params.versions]]
-fullversion = "v1.23.0"
-version = "v1.23"
-githubbranch = "v1.23.0"
+fullversion = "v1.24.0"
+version = "v1.24"
+githubbranch = "v1.24.0"
 docsbranch = "main"
 url = "https://kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.22.4"
+fullversion = "v1.23.6"
+version = "v1.23"
+githubbranch = "v1.23.6"
+docsbranch = "release-1.23"
+url = "https://v1-23.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.22.9"
 version = "v1.22"
-githubbranch = "v1.22.4"
+githubbranch = "v1.22.9"
 docsbranch = "release-1.22"
 url = "https://v1-22.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.21.7"
+fullversion = "v1.21.12"
 version = "v1.21"
-githubbranch = "v1.21.7"
+githubbranch = "v1.21.12"
 docsbranch = "release-1.21"
 url = "https://v1-21.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.20.13"
+fullversion = "v1.20.15"
 version = "v1.20"
-githubbranch = "v1.20.13"
+githubbranch = "v1.20.15"
 docsbranch = "release-1.20"
 url = "https://v1-20.docs.kubernetes.io"
 
-[[params.versions]]
-fullversion = "v1.19.16"
-version = "v1.19"
-githubbranch = "v1.19.16"
-docsbranch = "release-1.19"
-url = "https://v1-19.docs.kubernetes.io"
-
 # User interface configuration
 [params.ui]
 # Enable to show the side bar menu in its compact state.
 sidebar_menu_compact = false
+# Show expand/collapse icon for sidebar sections.
+sidebar_menu_foldable = true
 # https://github.com/gohugoio/hugo/issues/8918#issuecomment-903314696
 sidebar_cache_limit = 1
 #  Set to true to disable breadcrumb navigation.

content/en/blog/_posts/2018-07-11-dynamic-kubelet-configuration.md

@@ -6,6 +6,8 @@ date: 2018-07-11
 
 **Author**: Michael Taufen (Google)
 
+**Editor’s note: The feature has been removed in the version 1.24 after deprecation in 1.22.**
+
 **Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement/) on what’s new in Kubernetes 1.11**
 
 ## Why Dynamic Kubelet Configuration?

content/en/blog/_posts/2020-12-02-dockershim-faq.md

@@ -14,7 +14,7 @@ on the deprecation of Docker as a container runtime for Kubernetes kubelets, and
 what that means, check out the blog post
 [Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/).
 
-Also, you can read [check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) to check whether it does.
+Also, you can read [check whether Dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) to check whether it does.
 
 ### Why is dockershim being deprecated?
 

content/en/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md

@@ -3,13 +3,17 @@ layout: blog
 title: "Don't Panic: Kubernetes and Docker"
 date: 2020-12-02
 slug: dont-panic-kubernetes-and-docker
+evergreen: true
+---
+
+**Update:** _Kubernetes support for Docker via `dockershim` is now removed.
+For more information, read the [removal FAQ](/dockershim).
+You can also discuss the deprecation via a dedicated [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)._
+
 ---
 
 **Authors:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
 
-_Update: Kubernetes support for Docker via `dockershim` is now deprecated.
-For more information, read the [deprecation notice](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation).
-You can also discuss the deprecation via a dedicated [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)._
 
 Kubernetes is [deprecating
 Docker](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)
@@ -28,7 +32,7 @@ shouldn’t, use Docker as a development tool anymore. Docker is still a useful
 tool for building containers, and the images that result from running `docker
 build` can still run in your Kubernetes cluster. 
 
-If you’re using a managed Kubernetes service like GKE, EKS, or AKS (which [defaults to containerd](https://github.com/Azure/AKS/releases/tag/2020-11-16)) you will need to
+If you’re using a managed Kubernetes service like AKS, EkS or GKE, you will need to
 make sure your worker nodes are using a supported container runtime before
 Docker support is removed in a future version of Kubernetes. If you have node
 customizations you may need to update them based on your environment and runtime
@@ -37,8 +41,8 @@ testing and planning.
 
 If you’re rolling your own clusters, you will also need to make changes to avoid
 your clusters breaking. At v1.20, you will get a deprecation warning for Docker.
-When Docker runtime support is removed in a future release (currently planned
-for the 1.22 release in late 2021) of Kubernetes it will no longer be supported
+When Docker runtime support is removed in a future release (<del>currently planned
+for the 1.22 release in late 2021</del>) of Kubernetes it will no longer be supported
 and you will need to switch to one of the other compliant container runtimes,
 like containerd or CRI-O. Just make sure that the runtime you choose supports
 the docker daemon configurations you currently use (e.g. logging).

content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md

@@ -12,7 +12,7 @@ to reaffirm our community values by supporting open source container runtimes,
 enabling a smaller kubelet, and increasing engineering velocity for teams using
 Kubernetes. If you [use Docker Engine as a container runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)
 for your Kubernetes cluster, get ready to migrate in 1.24! To check if you're
-affected, refer to [Check whether dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/).
+affected, refer to [Check whether dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/).
 
 ## Why we’re moving away from dockershim
 

content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md

@@ -7,31 +7,37 @@ slug: dockershim-faq
 aliases: [ '/dockershim' ]
 ---
 
-**This is an update to the original [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article,
-published in late 2020.**
+**This supersedes the original
+[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article,
+published in late 2020. The article includes updates from the v1.24
+release of Kubernetes.**
+
+---
 
 This document goes over some frequently asked questions regarding the
-deprecation and removal of _dockershim_, that was
+removal of _dockershim_ from Kubernetes. The removal was originally
 [announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/)
-as a part of the Kubernetes v1.20 release. For more detail
-on what that means, check out the blog post
+as a part of the Kubernetes v1.20 release. The Kubernetes
+[v1.24 release](/releases/#release-v1-24) actually removed the dockershim
+from Kubernetes.
+
+For more on what that means, check out the blog post
 [Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/).
 
-Also, you can read [check whether dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
-to determine how much impact the removal of dockershim would have for you
-or for your organization.
+To determine the impact that the removal of dockershim would have for you or your organization,
+you can read [Check whether dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/).
 
-As the Kubernetes 1.24 release has become imminent, we've been working hard to try to make this a smooth transition.
+In the months and days leading up to the Kubernetes 1.24 release, Kubernetes contributors worked hard to try to make this a smooth transition.
 
-- We've written a blog post detailing our [commitment and next steps](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/).
-- We believe there are no major blockers to migration to [other container runtimes](/docs/setup/production-environment/container-runtimes/#container-runtimes).
-- There is also a [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) guide available.
-- We've also created a page to list
+- A blog post detailing our [commitment and next steps](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/).
+- Checking if there were major blockers to migration to [other container runtimes](/docs/setup/production-environment/container-runtimes/#container-runtimes).
+- Adding a [migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) guide.
+- Creating a list of
   [articles on dockershim removal and on using CRI-compatible runtimes](/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/).
   That list includes some of the already mentioned docs, and also covers selected external sources
   (including vendor guides).
 
-### Why is the dockershim being removed from Kubernetes?
+### Why was the dockershim removed from Kubernetes?
 
 Early versions of Kubernetes only worked with a specific container runtime:
 Docker Engine. Later, Kubernetes added support for working with other container runtimes.
@@ -49,26 +55,52 @@ In fact, maintaining dockershim had become a heavy burden on the Kubernetes main
 
 Additionally, features that were largely incompatible with the dockershim, such
 as cgroups v2 and user namespaces are being implemented in these newer CRI
-runtimes. Removing support for the dockershim will allow further development in
-those areas.
+runtimes. Removing the dockershim from Kubernetes allows further development in those areas.
 
 [drkep]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim
 
+### Are Docker and containers the same thing?
+
+Docker popularized the Linux containers pattern and has been instrumental in
+developing the underlying technology, however containers in Linux have existed
+for a long time. The container ecosystem has grown to be much broader than just
+Docker. Standards like OCI and CRI have helped many tools grow and thrive in our
+ecosystem, some replacing aspects of Docker while others enhance existing
+functionality.
+
+### Will my existing container images still work?
+
+Yes, the images produced from `docker build` will work with all CRI implementations.
+All your existing images will still work exactly the same.
+
+#### What about private images?
+
+Yes. All CRI runtimes support the same pull secrets configuration used in
+Kubernetes, either via the PodSpec or ServiceAccount.
+
 ### Can I still use Docker Engine in Kubernetes 1.23?
 
 Yes, the only thing changed in 1.20 is a single warning log printed at [kubelet]
-startup if using Docker Engine as the runtime. You'll see this warning in all versions up to 1.23. The dockershim removal occurs in Kubernetes 1.24.
+startup if using Docker Engine as the runtime. You'll see this warning in all versions up to 1.23. The dockershim removal occurred
+in Kubernetes 1.24.
+
+If you're running Kubernetes v1.24 or later, see [Can I still use Docker Engine as my container runtime?](#can-i-still-use-docker-engine-as-my-container-runtime).
+(Remember, you can switch away from the dockershim if you're using any supported Kubernetes release; from release v1.24, you
+**must** switch as Kubernetes no longer incluides the dockershim).
 
 [kubelet]: /docs/reference/command-line-tools-reference/kubelet/
 
-### When will dockershim be removed?
+### Which CRI implementation should I use?
 
-Given the impact of this change, we are using an extended deprecation timeline.
-Removal of dockershim is scheduled for Kubernetes v1.24, see [Dockershim Removal Kubernetes Enhancement Proposal][drkep].
-The Kubernetes project will be working closely with vendors and other ecosystem groups to ensure
-a smooth transition and will evaluate things as the situation evolves.
+That’s a complex question and it depends on a lot of factors. If Docker Engine is
+working for you, moving to containerd should be a relatively easy swap and
+will have strictly better performance and less overhead. However, we encourage you
+to explore all the options from the [CNCF landscape] in case another would be an
+even better fit for your environment.
+
+[CNCF landscape]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category
 
-### Can I still use Docker Engine as my container runtime?
+#### Can I still use Docker Engine as my container runtime?
 
 First off, if you use Docker on your own PC to develop or test containers: nothing changes.
 You can still use Docker locally no matter what container runtime(s) you use for your
@@ -78,26 +110,9 @@ Mirantis and Docker have [committed][mirantis] to maintaining a replacement adap
 Docker Engine, and to maintain that adapter even after the in-tree dockershim is removed
 from Kubernetes. The replacement adapter is named [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd).
 
-[mirantis]: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/
-
-### Will my existing container images still work?
-
-Yes, the images produced from `docker build` will work with all CRI implementations.
-All your existing images will still work exactly the same.
-
-#### What about private images?
+You can install `cri-dockerd` and use it to connect the kubelet to Docker Engine. Read [Migrate Docker Engine nodes from dockershim to cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/) to learn more.
 
-Yes. All CRI runtimes support the same pull secrets configuration used in
-Kubernetes, either via the PodSpec or ServiceAccount.
-
-### Are Docker and containers the same thing?
-
-Docker popularized the Linux containers pattern and has been instrumental in
-developing the underlying technology, however containers in Linux have existed
-for a long time. The container ecosystem has grown to be much broader than just
-Docker. Standards like OCI and CRI have helped many tools grow and thrive in our
-ecosystem, some replacing aspects of Docker while others enhance existing
-functionality.
+[mirantis]: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/
 
 ### Are there examples of folks using other runtimes in production today?
 
@@ -135,16 +150,6 @@ provide an end-to-end standard for managing containers.
 [runc]: https://github.com/opencontainers/runc
 [containerd]: https://containerd.io/
 
-### Which CRI implementation should I use?
-
-That’s a complex question and it depends on a lot of factors. If Docker is
-working for you, moving to containerd should be a relatively easy swap and
-will have strictly better performance and less overhead. However, we encourage you
-to explore all the options from the [CNCF landscape] in case another would be an
-even better fit for your environment.
-
-[CNCF landscape]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category
-
 ### What should I look out for when changing CRI implementations?
 
 While the underlying containerization code is the same between Docker and most
@@ -153,24 +158,25 @@ common things to consider when migrating are:
 
 - Logging configuration
 - Runtime resource limitations
-- Node provisioning scripts that call docker or use docker via it's control socket
-- Kubectl plugins that require docker CLI or the control socket
+- Node provisioning scripts that call docker or use Docker Engine via its control socket
+- Plugins for `kubectl` that require the `docker` CLI or the Docker Engine control socket
 - Tools from the Kubernetes project that require direct access to Docker Engine
   (for example: the deprecated `kube-imagepuller` tool)
-- Configuration of functionality like `registry-mirrors` and insecure registries 
+- Configuration of functionality like `registry-mirrors` and insecure registries
 - Other support scripts or daemons that expect Docker Engine to be available and are run
   outside of Kubernetes (for example, monitoring or security agents)
 - GPUs or special hardware and how they integrate with your runtime and Kubernetes
 
 If you use Kubernetes resource requests/limits or file-based log collection
-DaemonSets then they will continue to work the same, but if you’ve customized
+DaemonSets then they will continue to work the same, but if you've customized
 your `dockerd` configuration, you’ll need to adapt that for your new container
 runtime where possible.
 
 Another thing to look out for is anything expecting to run for system maintenance
 or nested inside a container when building images will no longer work. For the
-former, you can use the [`crictl`][cr] tool as a drop-in replacement (see [mapping from docker cli to crictl](https://kubernetes.io/docs/tasks/debug/debug-cluster/crictl/#mapping-from-docker-cli-to-crictl)) and for the
-latter you can use newer container build options like [img], [buildah],
+former, you can use the [`crictl`][cr] tool as a drop-in replacement (see
+[mapping from docker cli to crictl](https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl))
+and for the latter you can use newer container build options like [img], [buildah],
 [kaniko], or [buildkit-cli-for-kubectl] that don’t require Docker.
 
 [cr]: https://github.com/kubernetes-sigs/cri-tools
@@ -204,7 +210,7 @@ discussion of the changes.
 
 [dep]: https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
 
-### Is there any tooling that can help me find dockershim in use
+### Is there any tooling that can help me find dockershim in use?
 
 Yes! The [Detector for Docker Socket (DDS)][dds] is a kubectl plugin that you can
 install and then use to check your cluster. DDS can detect if active Kubernetes workloads