Merge pull request #31490 from nate-double-u/merged-main-dev-1.24

Merged main into dev 1.24

Makefile

@@ -28,28 +28,30 @@ module-init:
 
 all: build ## Build site with production settings and put deliverables in ./public
 
-build: module-check ## Build site with production settings and put deliverables in ./public
-	hugo --minify
+build: module-check ## Build site with non-production settings and put deliverables in ./public
+	hugo --minify --environment development
 
 build-preview: module-check ## Build site with drafts and future posts enabled
-	hugo --buildDrafts --buildFuture
+	hugo --buildDrafts --buildFuture --environment preview
 
 deploy-preview: ## Deploy preview site via netlify
-	hugo --enableGitInfo --buildFuture -b $(DEPLOY_PRIME_URL)
+	hugo --enableGitInfo --buildFuture --environment preview -b $(DEPLOY_PRIME_URL)
 
 functions-build:
 	$(NETLIFY_FUNC) build functions-src
 
 check-headers-file:
 	scripts/check-headers-file.sh
 
-production-build: build check-headers-file ## Build the production site and ensure that noindex headers aren't added
+production-build: module-check ## Build the production site and ensure that noindex headers aren't added
+	hugo --minify --environment production
+	HUGO_ENV=production $(MAKE) check-headers-file
 
-non-production-build: ## Build the non-production site, which adds noindex headers to prevent indexing
-	hugo --enableGitInfo
+non-production-build: module-check ## Build the non-production site, which adds noindex headers to prevent indexing
+	hugo --enableGitInfo --environment nonprod
 
 serve: module-check ## Boot the development server.
-	hugo server --buildFuture
+	hugo server --buildFuture --environment development
 
 docker-image:
 	@echo -e "$(CCRED)**** The use of docker-image is deprecated. Use container-image instead. ****$(CCEND)"
@@ -70,10 +72,10 @@ container-image: ## Build a container image for the preview of the website
 		--build-arg HUGO_VERSION=$(HUGO_VERSION)
 
 container-build: module-check
-	$(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify"
+	$(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify --environment development"
 
 container-serve: module-check ## Boot the development server using container. Run `make container-image` before this.
-	$(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir
+	$(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir
 
 test-examples:
 	scripts/test_examples.sh install
@@ -88,7 +90,7 @@ docker-internal-linkcheck:
 	$(MAKE) container-internal-linkcheck
 
 container-internal-linkcheck: link-checker-image-pull
-	$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture
+	$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture --environment test
 	$(CONTAINER_ENGINE) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest
 
 clean-api-reference: ## Clean all directories in API reference directory, preserve _index.md

assets/scss/_custom.scss

@@ -215,15 +215,25 @@ body.td-404 main .error-details {
   }
 }
 
+body > footer {
+  width: 100vw;
+}
+
 /* FOOTER */
 footer {
   background-color: #303030;
   background-image: url("/images/texture.png");
   padding: 1rem !important;
   min-height: initial !important;
 
-  .footer__links {
-    width: 100%;
+  > div, > p {
+    max-width: 95%;
+    @media only screen and (min-width: 768px) {
+      max-width: calc(min(80rem,90vw)); // avoid spreading too wide
+    }
+  }
+
+  > .footer__links {
     margin: auto;
     padding-bottom: 1rem;
 
@@ -233,6 +243,8 @@ footer {
     }
 
     @media only screen and (min-width: 768px) {
+      max-width: calc(min(60rem,90vw)); // avoid spreading too wide
+
       nav {
         display: flex;
         flex-direction: row;

content/en/docs/concepts/architecture/cloud-controller.md

@@ -78,7 +78,7 @@ when you declare a Service resource that requires them.
 
 ## Authorization
 
-This section breaks down the access that the cloud controller managers requires
+This section breaks down the access that the cloud controller manager requires
 on various API objects, in order to perform its operations.
 
 ### Node controller {#authorization-node-controller}

content/en/docs/concepts/cluster-administration/networking.md

@@ -67,7 +67,7 @@ Azure CNI is available natively in the [Azure Kubernetes Service (AKS)](https://
 
 ### Calico
 
-[Calico](https://docs.projectcalico.org/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement.
+[Calico](https://projectcalico.docs.tigera.io/about/about-calico/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://projectcalico.docs.tigera.io/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement.
 
 ### Cilium
 
@@ -79,9 +79,9 @@ addressing, and it can be used in combination with other CNI plugins.
 
 ### CNI-Genie from Huawei
 
-[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](https://docs.projectcalico.org/), [Weave-net](https://www.weave.works/products/weave-net/).
+[CNI-Genie](https://github.com/cni-genie/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/flannel-io/flannel#flannel), [Calico](https://projectcalico.docs.tigera.io/about/about-calico/), [Weave-net](https://www.weave.works/oss/net/).
 
-CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.
+CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.
 
 ### cni-ipvlan-vpc-k8s
 [cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) contains a set
@@ -104,6 +104,11 @@ network complexity required to deploy Kubernetes at scale within AWS.
 [Coil](https://github.com/cybozu-go/coil) is a CNI plugin designed for ease of integration, providing flexible egress networking.
 Coil operates with a low overhead compared to bare metal, and allows you to define arbitrary egress NAT gateways for external networks.
 
+### Contiv-VPP
+
+[Contiv-VPP](https://contivpp.io/) is a user-space, performance-oriented network plugin for
+Kubernetes, using the [fd.io](https://fd.io/) data plane.
+
 ### Contrail / Tungsten Fabric
 
 [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads.
@@ -122,7 +127,7 @@ With this toolset DANM is able to provide multiple separated network interfaces,
 
 ### Flannel
 
-[Flannel](https://github.com/coreos/flannel#flannel) is a very simple overlay
+[Flannel](https://github.com/flannel-io/flannel#flannel) is a very simple overlay
 network that satisfies the Kubernetes requirements. Many
 people have reported success with Flannel and Kubernetes.
 
@@ -188,7 +193,7 @@ at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
 
 ### Weave Net from Weaveworks
 
-[Weave Net](https://www.weave.works/products/weave-net/) is a
+[Weave Net](https://www.weave.works/oss/net/) is a
 resilient and simple to use network for Kubernetes and its hosted applications.
 Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/)
 or stand-alone.  In either version, it doesn't require any configuration or extra code

content/en/docs/concepts/cluster-administration/system-logs.md

@@ -182,7 +182,8 @@ There are two types of system components: those that run in a container and thos
 that do not run in a container. For example:
 
 * The Kubernetes scheduler and kube-proxy run in a container.
-* The kubelet and container runtime, for example Docker, do not run in containers.
+* The kubelet and {{<glossary_tooltip term_id="container-runtime" text="container runtime">}}
+  do not run in containers.
 
 On machines with systemd, the kubelet and container runtime write to journald.
 Otherwise, they write to `.log` files in the `/var/log` directory.

content/en/docs/concepts/storage/volumes.md

@@ -858,7 +858,7 @@ operations from the existing in-tree plugin to the `rbd.csi.ceph.com` {{<
 glossary_tooltip text="CSI" term_id="csi" >}} driver. In order to use this
 feature, the
 [Ceph CSI driver](https://github.com/ceph/ceph-csi)
-must be installed on the cluster and the `CSIMigration` and `CSIMigrationRBD`
+must be installed on the cluster and the `CSIMigration` and `csiMigrationRBD`
 [feature gates](/docs/reference/command-line-tools-reference/feature-gates/)
 must be enabled.
 
@@ -1133,6 +1133,7 @@ spec:
     volumeMounts:
     - name: workdir1
       mountPath: /logs
+      # The variable expansion uses round brackets (not curly brackets).
       subPathExpr: $(POD_NAME)
   restartPolicy: Never
   volumes:

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

@@ -88,7 +88,7 @@ different Kubernetes components.
 | `CSIMigrationOpenStack` | `true` | Beta | 1.18 | |
 | `CSIMigrationvSphere` | `false` | Beta | 1.19 | |
 | `CSIMigrationPortworx` | `false` | Alpha | 1.23 | |
-| `CSIMigrationRBD` | `false` | Alpha | 1.23 | |
+| `csiMigrationRBD` | `false` | Alpha | 1.23 | |
 | `CSIStorageCapacity` | `false` | Alpha | 1.19 | 1.20 |
 | `CSIStorageCapacity` | `true` | Beta | 1.21 | |
 | `CSIVolumeHealth` | `false` | Alpha | 1.21 | |
@@ -653,9 +653,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
   operations from the GCE-PD in-tree plugin to PD CSI plugin. Supports falling
   back to in-tree GCE plugin if a node does not have PD CSI plugin installed and
   configured. Requires CSIMigration feature flag enabled.
-- `CSIMigrationRBD`: Enables shims and translation logic to route volume
+- `csiMigrationRBD`: Enables shims and translation logic to route volume
   operations from the RBD in-tree plugin to Ceph RBD CSI plugin. Requires
-  CSIMigration and CSIMigrationRBD feature flags enabled and Ceph CSI plugin
+  CSIMigration and csiMigrationRBD feature flags enabled and Ceph CSI plugin
   installed and configured in the cluster. This flag has been deprecated in
   favor of the
   `InTreePluginRBDUnregister` feature flag which prevents the registration of
@@ -731,6 +731,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
   on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
 - `DaemonSetUpdateSurge`: Enables the DaemonSet workloads to maintain
   availability during update per node.
+  See [Perform a Rolling Update on a DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/).
 - `DefaultPodTopologySpread`: Enables the use of `PodTopologySpread` scheduling plugin to do
   [default spreading](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints).
 - `DelegateFSGroupToCSIDriver`: If supported by the CSI driver, delegates the

content/en/docs/reference/glossary/container-runtime.md

@@ -15,7 +15,7 @@ tags:
 
 <!--more-->
 
-Kubernetes supports several container runtimes: {{< glossary_tooltip term_id="docker">}},
+Kubernetes supports container runtimes such as
 {{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}},
-and any implementation of the [Kubernetes CRI (Container Runtime
+and any other implementation of the [Kubernetes CRI (Container Runtime
 Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).

content/en/docs/reference/kubectl/conventions.md

@@ -31,29 +31,6 @@ For `kubectl run` to satisfy infrastructure as code:
 
 You can use the `--dry-run=client` flag to preview the object that would be sent to your cluster, without really submitting it.
 
-{{< note >}}
-All `kubectl run` generators are deprecated. See the Kubernetes v1.17 documentation for a [list](https://v1-17.docs.kubernetes.io/docs/reference/kubectl/conventions/#generators) of generators and how they were used.
-{{< /note >}}
-
-#### Generators
-You can generate the following resources with a kubectl command, `kubectl create --dry-run=client -o yaml`:
-
-* `clusterrole`: Create a ClusterRole.
-* `clusterrolebinding`: Create a ClusterRoleBinding for a particular ClusterRole.
-* `configmap`: Create a ConfigMap from a local file, directory or literal value.
-* `cronjob`: Create a CronJob with the specified name.
-* `deployment`: Create a Deployment with the specified name.
-* `job`: Create a Job with the specified name.
-* `namespace`: Create a Namespace with the specified name.
-* `poddisruptionbudget`: Create a PodDisruptionBudget with the specified name.
-* `priorityclass`: Create a PriorityClass with the specified name.
-* `quota`: Create a Quota with the specified name.
-* `role`: Create a Role with single rule.
-* `rolebinding`: Create a RoleBinding for a particular Role or ClusterRole.
-* `secret`: Create a Secret using specified subcommand.
-* `service`: Create a Service using specified subcommand.
-* `serviceaccount`: Create a ServiceAccount with the specified name.
-
 ### `kubectl apply`
 
 * You can use `kubectl apply` to create or update resources. For more information about using kubectl apply to update resources, see [Kubectl Book](https://kubectl.docs.kubernetes.io).

content/en/docs/setup/best-practices/enforcing-pod-security-standards.md

@@ -15,7 +15,7 @@ This page provides an overview of best practices when it comes to enforcing
 
 ## Using the built-in Pod Security Admission Controller
 
-{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
 
 The [Pod Security Admission Controller](/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
 intends to replace the deprecated PodSecurityPolicies. 

content/en/docs/setup/production-environment/container-runtimes.md

@@ -15,12 +15,19 @@ what is involved and describes related tasks for setting up nodes.
 
 <!-- body -->
 
+Kubernetes {{< skew currentVersion >}} requires that you use a runtime that
+conforms with the 
+{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI).
+
+See [CRI version support](#cri-versions) for more information.
+
 This page lists details for using several common container runtimes with
 Kubernetes, on Linux:
 
 - [containerd](#containerd)
 - [CRI-O](#cri-o)
-- [Docker](#docker)
+- [Docker Engine](#docker)
+- [Mirantis Container Runtime](#mcr)
 
 {{< note >}}
 For other operating systems, look for documentation specific to your platform.
@@ -94,10 +101,19 @@ In order to use it, cgroup v2 must be supported by the CRI runtime as well.
 Follow this [Migration guide](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)
 if you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters.
 
+## CRI version support {#cri-versions}
+
+Your container runtime must support at least v1alpha2 of the container runtime interface.
+
+Kubernetes {{< skew currentVersion >}}  defaults to using v1 of the CRI API.
+If a container runtime does not support the v1 API, the kubelet falls back to
+using the (deprecated) v1alpha2 API instead.
+
 ## Container runtimes
 
 {{% thirdparty-content %}}
 
+
 ### containerd
 
 This section contains the necessary steps to use containerd as CRI runtime.
@@ -394,44 +410,28 @@ Please also note the changed `conmon_cgroup`, which has to be set to the value
 cgroup driver configuration of the kubelet (usually done via kubeadm) and CRI-O
 in sync.
 
-### Docker
+### Docker Engine {#docker}
 
-1. On each of your nodes, install the Docker for your Linux distribution as per 
-[Install Docker Engine](https://docs.docker.com/engine/install/#server). 
-You can find the latest validated version of Docker in this 
-[dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file.
+Docker Engine is the container runtime that started it all. Formerly known just as Docker,
+this container runtime is available in various forms.
+[Install Docker Engine](https://docs.docker.com/engine/install/) explains your options
+for installing this runtime.
 
-2. Configure the Docker daemon, in particular to use systemd for the management of the container’s cgroups.
+Docker Engine is directly compatible with Kubernetes {{< skew currentVersion >}}, using the deprecated `dockershim` component. For more information
+and context, see the [Dockershim deprecation FAQ](/dockershim).
 
-   ```shell
-   sudo mkdir /etc/docker
-   cat <<EOF | sudo tee /etc/docker/daemon.json
-   {
-     "exec-opts": ["native.cgroupdriver=systemd"],
-     "log-driver": "json-file",
-     "log-opts": {
-       "max-size": "100m"
-     },
-     "storage-driver": "overlay2"
-   }
-   EOF
-   ```
+You can also find third-party adapters that let you use Docker Engine with Kubernetes
+through the supported {{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}}
+(CRI).
 
-   {{< note >}}
-   `overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, 
-   or RHEL or CentOS using version 3.10.0-514 and above.
-   {{< /note >}}
+The following CRI adaptors are designed to work with Docker Engine:
 
-3. Restart Docker and enable on boot:
+- [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) from Mirantis
 
-   ```shell
-   sudo systemctl enable docker
-   sudo systemctl daemon-reload
-   sudo systemctl restart docker
-   ```
+### Mirantis Container Runtime {#mcr}
 
-{{< note >}}
-For more information refer to
-  - [Configure the Docker daemon](https://docs.docker.com/config/daemon/)
-  - [Control Docker with systemd](https://docs.docker.com/config/daemon/systemd/)
-{{< /note >}}
+[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (MCR) is a commercially
+available container runtime that was formerly known as Docker Enterprise Edition.
+
+You can use Mirantis Container Runtime with Kubernetes using the open source
+[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) component, included with MCR.