Fix incorrectly displayed K8s minor versions

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

@@ -244,7 +244,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

@@ -438,8 +438,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

@@ -38,7 +38,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"
@@ -78,7 +78,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 >}}
 ```