Merge pull request #34349 from jihoon-seo/220617_Fix_incorrectly_displayed_minor_versions_in_1.22

Fix incorrectly displayed K8s minor versions for `release-1.22` branch

Makefile

@@ -28,14 +28,14 @@ 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
@@ -43,13 +43,15 @@ functions-build:
 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

config.toml

@@ -139,11 +139,11 @@ 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.22.4"
+fullversion = "v1.22.9"
 version = "v1.22"
-githubbranch = "v1.22.4"
+githubbranch = "v1.22.9"
 docsbranch = "release-1.22"
 deprecated = true
 currentUrl = "https://kubernetes.io/docs/home/"
@@ -179,40 +179,40 @@ 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.

content/en/docs/concepts/security/pod-security-admission.md

@@ -79,7 +79,7 @@ For each mode, there are two labels that determine the policy used:
 pod-security.kubernetes.io/<MODE>: <LEVEL>
 
 # Optional: per-mode version label that can be used to pin the policy to the
-# version that shipped with a given Kubernetes minor version (for example v{{< skew latestVersion >}}).
+# version that shipped with a given Kubernetes minor version (for example v{{< skew currentVersion >}}).
 #
 # MODE must be one of `enforce`, `audit`, or `warn`.
 # VERSION must be a valid Kubernetes minor version, or `latest`.

content/en/docs/concepts/services-networking/network-policies.md

@@ -287,7 +287,7 @@ standardized label to target a specific namespace.
 
 ## What you can't do with network policies (at least, not yet)
 
-As of Kubernetes {{< skew latestVersion >}}, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers.  In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API.
+As of Kubernetes {{< skew currentVersion >}}, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers.  In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API.
 
 - Forcing internal cluster traffic to go through a common gateway (this might be best served with a service mesh or other proxy).
 - Anything TLS related (use a service mesh or ingress controller for this).

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

@@ -368,7 +368,7 @@ for more information.
 
 ## pod-security.kubernetes.io/enforce-version
 
-Example: `pod-security.kubernetes.io/enforce-version: {{< skew latestVersion >}}`
+Example: `pod-security.kubernetes.io/enforce-version: {{< skew currentVersion >}}`
 
 Used on: Namespace
 
@@ -395,7 +395,7 @@ for more information.
 
 ## pod-security.kubernetes.io/audit-version
 
-Example: `pod-security.kubernetes.io/audit-version: {{< skew latestVersion >}}`
+Example: `pod-security.kubernetes.io/audit-version: {{< skew currentVersion >}}`
 
 Used on: Namespace
 
@@ -424,7 +424,7 @@ for more information.
 
 ## pod-security.kubernetes.io/warn-version
 
-Example: `pod-security.kubernetes.io/warn-version: {{< skew latestVersion >}}`
+Example: `pod-security.kubernetes.io/warn-version: {{< skew currentVersion >}}`
 
 Used on: Namespace
 

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

@@ -514,10 +514,10 @@ options.
 
 ## Version skew policy {#version-skew-policy}
 
-The `kubeadm` tool of version v{{< skew latestVersion >}} may deploy clusters with a control plane of version v{{< skew latestVersion >}} or v{{< skew prevMinorVersion >}}.
-`kubeadm` v{{< skew latestVersion >}} can also upgrade an existing kubeadm-created cluster of version v{{< skew prevMinorVersion >}}.
+The `kubeadm` tool of version v{{< skew currentVersion >}} may deploy clusters with a control plane of version v{{< skew currentVersion >}} or v{{< skew currentVersionAddMinor -1 >}}.
+`kubeadm` v{{< skew currentVersion >}} can also upgrade an existing kubeadm-created cluster of version v{{< skew currentVersionAddMinor -1 >}}.
 
-Due to that we can't see into the future, kubeadm CLI v{{< skew latestVersion >}} may or may not be able to deploy v{{< skew nextMinorVersion >}} clusters.
+Due to that we can't see into the future, kubeadm CLI v{{< skew currentVersion >}} may or may not be able to deploy v{{< skew currentVersionAddMinor 1 >}} clusters.
 
 These resources provide more information on supported version skew between kubelets and the control plane, and other Kubernetes components:
 

content/en/docs/tasks/administer-cluster/cluster-upgrade.md

@@ -21,8 +21,8 @@ At a high level, the steps you perform are:
 ## {{% heading "prerequisites" %}}
 
 You must have an existing cluster. This page is about upgrading from Kubernetes
-{{< skew prevMinorVersion >}} to Kubernetes {{< skew latestVersion >}}. If your cluster
-is not currently running Kubernetes {{< skew prevMinorVersion >}} then please check
+{{< skew currentVersionAddMinor -1 >}} to Kubernetes {{< skew currentVersion >}}. If your cluster
+is not currently running Kubernetes {{< skew currentVersionAddMinor -1 >}} then please check
 the documentation for the version of Kubernetes that you plan to upgrade to.
 
 ## Upgrade approaches
@@ -55,7 +55,7 @@ At this point you should
 [install the latest version of `kubectl`](/docs/tasks/tools/).
 
 For each node in your cluster, [drain](/docs/tasks/administer-cluster/safely-drain-node/)
-that node and then either replace it with a new node that uses the {{< skew latestVersion >}}
+that node and then either replace it with a new node that uses the {{< skew currentVersion >}}
 kubelet, or upgrade the kubelet on that node and bring the node back into service.
 
 ### Other deployments {#upgrade-other}

content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md

@@ -242,7 +242,7 @@ serverTLSBootstrap: true
 ```
 
 If you have already created the cluster you must adapt it by doing the following:
- - Find and edit the `kubelet-config-{{< skew latestVersion >}}` ConfigMap in the `kube-system` namespace.
+ - Find and edit the `kubelet-config-{{< skew currentVersion >}}` ConfigMap in the `kube-system` namespace.
 In that ConfigMap, the `kubelet` key has a
 [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
 document as its value. Edit the KubeletConfiguration document to set `serverTLSBootstrap: true`.

content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

@@ -386,8 +386,8 @@ to 127.0.0.1. If your pod relies on virtual hosts, which is probably the more co
 case, you should not use `host`, but rather set the `Host` header in `httpHeaders`.
 
 For an HTTP probe, the kubelet sends two request headers in addition to the mandatory `Host` header:
-`User-Agent`, and `Accept`. The default values for these headers are `kube-probe/{{< skew latestVersion >}}`
-(where `{{< skew latestVersion >}}` is the version of the kubelet ), and `*/*` respectively.
+`User-Agent`, and `Accept`. The default values for these headers are `kube-probe/{{< skew currentVersion >}}`
+(where `{{< skew currentVersion >}}` is the version of the kubelet ), and `*/*` respectively.
 
 You can override the default headers by defining `.httpHeaders` for the probe; for example
 

content/en/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md

@@ -36,7 +36,7 @@ plugins:
     #
     # Version label values must be one of:
     # - "latest" (default) 
-    # - specific version like "v{{< skew latestVersion >}}"
+    # - specific version like "v{{< skew currentVersion >}}"
     defaults:
       enforce: "privileged"
       enforce-version: "latest"

content/en/docs/tasks/configure-pod-container/enforce-standards-namespace-labels.md

@@ -22,7 +22,7 @@ This manifest defines a Namespace `my-baseline-namespace` that:
 - _Blocks_ any pods that don't satisfy the `baseline` policy requirements.
 - Generates a user-facing warning and adds an audit annotation to any created pod that does not
   meet the `restricted` policy requirements.
-- Pins the versions of the `baseline` and `restricted` policies to v{{< skew latestVersion >}}.
+- Pins the versions of the `baseline` and `restricted` policies to v{{< skew currentVersion >}}.
 
 ```yaml
 apiVersion: v1
@@ -31,13 +31,13 @@ metadata:
   name: my-baseline-namespace
   labels:
     pod-security.kubernetes.io/enforce: baseline
-    pod-security.kubernetes.io/enforce-version: v{{< skew latestVersion >}}
+    pod-security.kubernetes.io/enforce-version: v{{< skew currentVersion >}}
 
     # We are setting these to our _desired_ `enforce` level.
     pod-security.kubernetes.io/audit: restricted
-    pod-security.kubernetes.io/audit-version: v{{< skew latestVersion >}}
+    pod-security.kubernetes.io/audit-version: v{{< skew currentVersion >}}
     pod-security.kubernetes.io/warn: restricted
-    pod-security.kubernetes.io/warn-version: v{{< skew latestVersion >}}
+    pod-security.kubernetes.io/warn-version: v{{< skew currentVersion >}}
 ```
 
 ## Add labels to existing namespaces with `kubectl label`
@@ -78,10 +78,10 @@ kubectl get namespaces --selector='!pod-security.kubernetes.io/enforce'
 ### Applying to a single namespace
 
 You can update a specific namespace as well. This command adds the `enforce=restricted`
-policy to `my-existing-namespace`, pinning the restricted policy version to v{{< skew latestVersion >}}.
+policy to `my-existing-namespace`, pinning the restricted policy version to v{{< skew currentVersion >}}.
 
 ```shell
 kubectl label --overwrite ns my-existing-namespace \
   pod-security.kubernetes.io/enforce=restricted \
-  pod-security.kubernetes.io/enforce-version=v{{< skew latestVersion >}}
+  pod-security.kubernetes.io/enforce-version=v{{< skew currentVersion >}}
 ```

content/en/releases/version-skew-policy.md

@@ -40,8 +40,8 @@ In [highly-available (HA) clusters](/docs/setup/production-environment/tools/kub
 
 Example:
 
-* newest `kube-apiserver` is at **{{< skew latestVersion >}}**
-* other `kube-apiserver` instances are supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
+* newest `kube-apiserver` is at **{{< skew currentVersion >}}**
+* other `kube-apiserver` instances are supported at **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}**
 
 ### kubelet
 
@@ -49,8 +49,8 @@ Example:
 
 Example:
 
-* `kube-apiserver` is at **{{< skew latestVersion >}}**
-* `kubelet` is supported at **{{< skew latestVersion >}}**, **{{< skew prevMinorVersion >}}**, and **{{< skew oldestMinorVersion >}}**
+* `kube-apiserver` is at **{{< skew currentVersion >}}**
+* `kubelet` is supported at **{{< skew currentVersion >}}**, **{{< skew currentVersionAddMinor -1 >}}**, and **{{< skew currentVersionAddMinor -2 >}}**
 
 {{< note >}}
 If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kubelet` versions.
@@ -58,8 +58,8 @@ If version skew exists between `kube-apiserver` instances in an HA cluster, this
 
 Example:
 
-* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
-* `kubelet` is supported at **{{< skew prevMinorVersion >}}**, and **{{< skew oldestMinorVersion >}}** (**{{< skew latestVersion >}}** is not supported because that would be newer than the `kube-apiserver` instance at version **{{< skew prevMinorVersion >}}**)
+* `kube-apiserver` instances are at **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}**
+* `kubelet` is supported at **{{< skew currentVersionAddMinor -1 >}}**, and **{{< skew currentVersionAddMinor -2 >}}** (**{{< 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
 
@@ -67,8 +67,8 @@ Example:
 
 Example:
 
-* `kube-apiserver` is at **{{< skew latestVersion >}}**
-* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
+* `kube-apiserver` is at **{{< skew currentVersion >}}**
+* `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.
@@ -76,9 +76,9 @@ If version skew exists between `kube-apiserver` instances in an HA cluster, and
 
 Example:
 
-* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
+* `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 prevMinorVersion >}}** (**{{< skew latestVersion >}}** is not supported because that would be newer than the `kube-apiserver` instance at version **{{< skew prevMinorVersion >}}**)
+* `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
 
@@ -86,8 +86,8 @@ Example:
 
 Example:
 
-* `kube-apiserver` is at **{{< skew latestVersion >}}**
-* `kubectl` is supported at **{{< skew nextMinorVersion >}}**, **{{< skew latestVersion >}}**, and **{{< skew prevMinorVersion >}}**
+* `kube-apiserver` is at **{{< skew currentVersion >}}**
+* `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.
@@ -95,27 +95,27 @@ If version skew exists between `kube-apiserver` instances in an HA cluster, this
 
 Example:
 
-* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
-* `kubectl` is supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}** (other versions would be more than one minor version skewed from one of the `kube-apiserver` components)
+* `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)
 
 ## 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 prevMinorVersion >}}** to version **{{< skew latestVersion >}}**.
+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 >}}**.
 
 ### kube-apiserver
 
 Pre-requisites:
 
-* In a single-instance cluster, the existing `kube-apiserver` instance is **{{< skew prevMinorVersion >}}**
-* In an HA cluster, all `kube-apiserver` instances are at **{{< skew prevMinorVersion >}}** or **{{< skew latestVersion >}}** (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 prevMinorVersion >}}** (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 prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}** (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 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)
 * 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 latestVersion >}}** (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 latestVersion >}}**
+  * `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 latestVersion >}}**
+Upgrade `kube-apiserver` to **{{< skew currentVersion >}}**
 
 {{< note >}}
 Project policies for [API deprecation](/docs/reference/using-api/deprecation-policy/) and
@@ -127,17 +127,17 @@ 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 latestVersion >}}** (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 latestVersion >}}**
+Upgrade `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` to **{{< skew currentVersion >}}**
 
 ### kubelet
 
 Pre-requisites:
 
-* The `kube-apiserver` instances the `kubelet` communicates with are at **{{< skew latestVersion >}}**
+* The `kube-apiserver` instances the `kubelet` communicates with are at **{{< skew currentVersion >}}**
 
-Optionally upgrade `kubelet` instances to **{{< skew latestVersion >}}** (or they can be left at **{{< skew prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}**)
+Optionally upgrade `kubelet` instances to **{{< skew currentVersion >}}** (or they can be left at **{{< skew currentVersionAddMinor -1 >}}** or **{{< skew currentVersionAddMinor -2 >}}**)
 
 {{< note >}}
 Before performing a minor version `kubelet` upgrade, [drain](/docs/tasks/administer-cluster/safely-drain-node/) pods from that node.
@@ -159,7 +159,7 @@ Running a cluster with `kubelet` instances that are persistently two minor versi
 
 Example:
 
-If `kube-proxy` version is **{{< skew oldestMinorVersion >}}**:
+If `kube-proxy` version is **{{< skew currentVersionAddMinor -2 >}}**:
 
-* `kubelet` version must be at the same minor version as **{{< skew oldestMinorVersion >}}**.
-* `kube-apiserver` version must be between **{{< skew oldestMinorVersion >}}** and **{{< skew latestVersion >}}**, inclusive.
+* `kubelet` version must be at the same minor version as **{{< skew currentVersionAddMinor -2 >}}**.
+* `kube-apiserver` version must be between **{{< skew currentVersionAddMinor -2 >}}** and **{{< skew currentVersion >}}**, inclusive.

layouts/_default/baseof.html

@@ -1,6 +1,9 @@
 <!doctype html>
 <html lang="{{ .Site.Language.Lang }}" class="{{.Params.class}} no-js">
-  <head>
+{{- if eq hugo.Environment "preview" -}}
+  <!-- deploy preview -->
+{{- end -}}
+  <head {{- if hugo.IsProduction -}}class="live-site"{{- end -}}>
     {{ partial "head.html" . }}
   </head>
   <body class="td-{{ .Kind }}{{- if ne (lower .Params.cid) "" -}}{{- printf " cid-%s" (lower .Params.cid) -}}{{- end -}}">

layouts/index.headers

@@ -1,4 +1,4 @@
-{{- if eq (getenv "HUGO_ENV") "production" }}
+{{- if eq hugo.Environment "production" }}
 {{- $cssFilesFromConfig := site.Params.pushAssets.css -}}
 {{- $jsFilesFromConfig := site.Params.pushAssets.js -}}
 {{- $pages := site.RegularPages -}}

layouts/partials/head.html

@@ -1,5 +1,11 @@
 {{- $isBlogPost := eq .Section "blog" }}
 {{- $ogType := cond (.IsHome) "website" "article" }}
+<!-- per-page robot indexing controls -->
+{{- if hugo.IsProduction -}}
+<meta name="ROBOTS" content="INDEX, FOLLOW">
+{{- else -}}
+<meta name="ROBOTS" content="NOINDEX, NOFOLLOW">
+{{- end -}}
 <!-- Global site tag (gtag.js) - Google Analytics -->
 <script async src="https://www.googletagmanager.com/gtag/js?id=UA-36037335-10"></script>
 <script>
@@ -19,11 +25,6 @@
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
 {{ hugo.Generator }}
-{{ if eq (getenv "HUGO_ENV") "production" }}
-<META NAME="ROBOTS" CONTENT="INDEX, FOLLOW">
-{{ else }}
-<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
-{{ end }}
 {{ range .AlternativeOutputFormats -}}
 <link rel="{{ .Rel }}" type="{{ .MediaType.Type }}" href="{{ .Permalink | safeURL }}">
 {{ end -}}
@@ -33,7 +34,7 @@
 {{- template "_internal/google_news.html" . -}}
 {{- template "_internal/schema.html" . -}}
 {{- template "_internal/twitter_cards.html" . -}}
-{{ if eq (getenv "HUGO_ENV") "production" }}
+{{- if hugo.IsProduction -}}
 {{ template "_internal/google_analytics_async.html" . }}
 {{ end }}
 {{ partialCached "head-css.html" . "asdf" }}

layouts/shortcodes/api-reference.html

@@ -2,6 +2,8 @@
 {{ $pageArg := .Get "page" }}
 {{ $anchorArg := .Get "anchor" }}
 {{ $textArg := .Get "text" }}
-{{ $page := site.GetPage "page" (printf "%s/%s" $base $pageArg) }}
+{{ $pagePath := path.Join $base $pageArg }}
+{{ $page := site.GetPage "page" $pagePath }}
+{{ with $page }}{{else}}{{ range where site.Home.AllTranslations "Language.Lang" "en" }}{{ $page = .Site.GetPage "page" $pagePath }}{{ end }}{{ end }}
 {{ $metadata := $page.Params.api_metadata }}
 <a href="{{ $page.URL }}{{if $anchorArg}}#{{ $anchorArg }}{{end}}">{{if $textArg}}{{ $textArg }}{{else if $anchorArg}}{{ $anchorArg }}{{else}}{{ $metadata.kind }}{{end}}</a>

netlify.toml

@@ -20,17 +20,10 @@ HUGO_ENABLEGITINFO = "true"
 command = "git submodule update --init --recursive --depth 1 && make deploy-preview"
 
 [context.branch-deploy]
-command = "git submodule update --init --recursive --depth 1 && make deploy-preview"
+command = "git submodule update --init --recursive --depth 1 && make non-production-build"
 
-[context.master]
-# This context is triggered by the `master` branch and allows search indexing
+[context.main]
+# This context is triggered by the `main` branch and allows search indexing
 # DO NOT REMOVE THIS (contact @kubernetes/sig-docs-leads)
 publish = "public"
 command = "git submodule update --init --recursive --depth 1 && make production-build"
-
-# adding in headers to prevent clickjacking
-[[headers]]
-  for = "/*"
-  [headers.values]
-    X-Frame-Options = "DENY"
-    X-XSS-Protection = "1; mode=block"