Fix incorrectly displayed K8s minor versions

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

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

@@ -258,7 +258,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/_index.md

@@ -517,7 +517,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
 
@@ -544,7 +544,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
 
@@ -573,7 +573,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

@@ -541,8 +541,8 @@ field when using `--config`. This option will control the versions
 of kube-apiserver, kube-controller-manager, kube-scheduler and kube-proxy.
 
 Example:
-* kubeadm is at {{< skew latestVersion >}}
-* `kubernetesVersion` must be at {{< skew latestVersion >}} or {{< skew prevMinorVersion >}}
+* kubeadm is at {{< skew currentVersion >}}
+* `kubernetesVersion` must be at {{< skew currentVersion >}} or {{< skew currentVersionAddMinor -1 >}}
 
 ### kubeadm's skew against the kubelet
 
@@ -550,8 +550,8 @@ Similarly to the Kubernetes version, kubeadm can be used with a kubelet version
 version as kubeadm or one version older.
 
 Example:
-* kubeadm is at {{< skew latestVersion >}}
-* kubelet on the host must be at {{< skew latestVersion >}} or {{< skew prevMinorVersion >}}
+* kubeadm is at {{< skew currentVersion >}}
+* kubelet on the host must be at {{< skew currentVersion >}} or {{< skew currentVersionAddMinor -1 >}}
 
 ### kubeadm's skew against kubeadm
 
@@ -564,17 +564,17 @@ the same node with `kubeadm upgrade`. Similar rules apply to the rest of the kub
 with the exception of `kubeadm upgrade`.
 
 Example for `kubeadm join`:
-* kubeadm version {{< skew latestVersion >}} was used to create a cluster with `kubeadm init`
-* Joining nodes must use a kubeadm binary that is at version {{< skew latestVersion >}}
+* kubeadm version {{< skew currentVersion >}} was used to create a cluster with `kubeadm init`
+* Joining nodes must use a kubeadm binary that is at version {{< skew currentVersion >}}
 
 Nodes that are being upgraded must use a version of kubeadm that is the same MINOR
 version or one MINOR version newer than the version of kubeadm used for managing the
 node.
 
 Example for `kubeadm upgrade`:
-* kubeadm version {{< skew prevMinorVersion >}} was used to create or upgrade the node
-* The version of kubeadm used for upgrading the node must be at {{< skew prevMinorVersion >}}
-or {{< skew latestVersion >}}
+* kubeadm version {{< skew currentVersionAddMinor -1 >}} was used to create or upgrade the node
+* The version of kubeadm used for upgrading the node must be at {{< skew currentVersionAddMinor -1 >}}
+or {{< skew currentVersion >}}
 
 To learn more about the version skew between the different Kubernetes component see
 the [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/).

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 >}}
 ```