Make feature-state tag usage consistent

content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md

@@ -275,7 +275,7 @@ the version.
 
 ## Webhook conversion
 
-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
+{{< feature-state state="stable" for_k8s_version="v1.16" >}}
 
 {{< note >}}
 Webhook conversion is available as beta since 1.15, and as alpha since Kubernetes 1.13. The

content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md

@@ -243,7 +243,7 @@ If you later recreate the same CustomResourceDefinition, it will start out empty
 
 ## Specifying a structural schema
 
-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
+{{< feature-state state="stable" for_k8s_version="v1.16" >}}
 
 CustomResources traditionally store arbitrary JSON (next to `apiVersion`, `kind` and `metadata`, which is validated by the API server implicitly). With [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) a schema can be specified, which is validated during creation and updates, compare below for details and limits of such a schema.
 
@@ -364,7 +364,7 @@ Structural schemas are a requirement for `apiextensions.k8s.io/v1`, and disables
 
 ### Pruning versus preserving unknown fields
 
-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
+{{< feature-state state="stable" for_k8s_version="v1.16" >}}
 
 CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources such as a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields.
 
@@ -604,7 +604,7 @@ meaning all finalizers have been executed.
 
 ### Validation
 
-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
+{{< feature-state state="stable" for_k8s_version="v1.16" >}}
 
 Validation of custom objects is possible via
 [OpenAPI v3 schemas](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject) or [validatingadmissionwebhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook). In `apiextensions.k8s.io/v1` schemas are required, in `apiextensions.k8s.io/v1beta1` they are optional.
@@ -781,7 +781,7 @@ crontab "my-new-cron-object" created
 
 ### Defaulting
 
-{{< feature-state state="stable" for_kubernetes_version="1.17" >}}
+{{< feature-state state="stable" for_k8s_version="v1.17" >}}
 
 {{< note >}}
 To use defaulting, your CustomResourceDefinition must use API version `apiextensions.k8s.io/v1`.
@@ -866,7 +866,7 @@ Default values for `metadata` fields of `x-kubernetes-embedded-resources: true`
 
 ### Publish Validation Schema in OpenAPI v2
 
-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
+{{< feature-state state="stable" for_k8s_version="v1.16" >}}
 
 {{< note >}}
 OpenAPI v2 Publishing is available as beta since 1.15, and as alpha since 1.14. The
@@ -1051,7 +1051,7 @@ The column's `format` controls the style used when `kubectl` prints the value.
 
 ### Subresources
 
-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
+{{< feature-state state="stable" for_k8s_version="v1.16" >}}
 
 Custom resources support `/status` and `/scale` subresources.
 

content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md

@@ -14,7 +14,7 @@ In upcoming releases, Cloud Controller Manager will
 be the preferred way to integrate Kubernetes with any cloud. This will ensure cloud providers
 can develop their features independently from the core Kubernetes release cycles.
 
-{{< feature-state for_k8s_version="1.8" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.8" state="alpha" >}}
 
 Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62) is satisfied.
 

content/en/docs/tasks/administer-cluster/highly-available-master.md

@@ -7,7 +7,7 @@ content_template: templates/task
 
 {{% capture overview %}}
 
-{{< feature-state for_k8s_version="1.5" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
 
 You can replicate Kubernetes masters in `kube-up` or `kube-down` scripts for Google Compute Engine.
 This document describes how to use kube-up/down scripts to manage highly available (HA) masters and how HA masters are implemented for use with GCE.

content/en/docs/tasks/manage-gpus/scheduling-gpus.md

@@ -7,7 +7,7 @@ title: Schedule GPUs
 
 {{% capture overview %}}
 
-{{< feature-state state="beta" for_k8s_version="1.10" >}}
+{{< feature-state state="beta" for_k8s_version="v1.10" >}}
 
 Kubernetes includes **experimental** support for managing AMD and NVIDIA GPUs
 (graphical processing units) across several nodes.

content/en/docs/tasks/run-application/horizontal-pod-autoscale.md

@@ -75,7 +75,7 @@ metrics-server, which needs to be launched separately. See
 for instructions. The HorizontalPodAutoscaler can also fetch metrics directly from Heapster.
 
 {{< note >}}
-{{< feature-state state="deprecated" for_k8s_version="1.11" >}}
+{{< feature-state state="deprecated" for_k8s_version="v1.11" >}}
 Fetching metrics from Heapster is deprecated as of Kubernetes 1.11.
 {{< /note >}}