Make feature-state tag usage consistent

liggitt · liggitt · commit ace502b542fa · 2020-04-09T13:19:41.000-04:00
diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md
@@ -9,7 +9,7 @@ weight: 70
 
 {{% capture overview %}}
 
-{{< feature-state for_k8s_version="1.14" state="stable" >}}
+{{< feature-state for_k8s_version="v1.14" state="stable" >}}
 
 [Pods](/docs/user-guide/pods) can have _priority_. Priority indicates the
 importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the
@@ -145,7 +145,7 @@ description: "This priority class should be used for XYZ service pods only."
 
 ## Non-preempting PriorityClass {#non-preempting-priority-class}
 
-{{< feature-state for_k8s_version="1.15" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
 
 Pods with `PreemptionPolicy: Never` will be placed in the scheduling queue
 ahead of lower-priority pods,
diff --git a/content/en/docs/concepts/configuration/resource-bin-packing.md b/content/en/docs/concepts/configuration/resource-bin-packing.md
@@ -10,7 +10,7 @@ weight: 10
 
 {{% capture overview %}}
 
-{{< feature-state for_k8s_version="1.16" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
 
 The kube-scheduler can be configured to enable bin packing of resources along with extended resources using `RequestedToCapacityRatioResourceAllocation` priority function. Priority functions can be used to fine-tune the kube-scheduler as per custom needs. 
 
diff --git a/content/en/docs/concepts/configuration/taint-and-toleration.md b/content/en/docs/concepts/configuration/taint-and-toleration.md
@@ -202,7 +202,7 @@ when there are node problems, which is described in the next section.
 
 ## Taint based Evictions
 
-{{< feature-state for_k8s_version="1.18" state="stable" >}}
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
 
 Earlier we mentioned the `NoExecute` taint effect, which affects pods that are already
 running on the node as follows
diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md
@@ -197,7 +197,7 @@ The `Terminating`, `NotTerminating`, and `NotBestEffort` scopes restrict a quota
 
 ### Resource Quota Per PriorityClass
 
-{{< feature-state for_k8s_version="1.12" state="beta" >}}
+{{< feature-state for_k8s_version="v1.12" state="beta" >}}
 
 Pods can be created at a specific [priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority).
 You can control a pod's consumption of system resources based on a pod's priority, by using the `scopeSelector`
diff --git a/content/en/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/en/docs/concepts/scheduling/scheduler-perf-tuning.md
@@ -8,7 +8,7 @@ weight: 70
 
 {{% capture overview %}}
 
-{{< feature-state for_k8s_version="1.14" state="beta" >}}
+{{< feature-state for_k8s_version="v1.14" state="beta" >}}
 
 [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)
 is the Kubernetes default scheduler. It is responsible for placement of Pods
diff --git a/content/en/docs/concepts/scheduling/scheduling-framework.md b/content/en/docs/concepts/scheduling/scheduling-framework.md
@@ -8,7 +8,7 @@ weight: 60
 
 {{% capture overview %}}
 
-{{< feature-state for_k8s_version="1.15" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
 
 The scheduling framework is a pluggable architecture for Kubernetes Scheduler
 that makes scheduler customizations easy. It adds a new set of "plugin" APIs to
diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md
@@ -185,7 +185,7 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent
 * All of the above
 * [Local](#local)
 
-{{< feature-state state="stable" for_k8s_version="1.17" >}}
+{{< feature-state state="stable" for_k8s_version="v1.17" >}}
 [CSI volumes](/docs/concepts/storage/volumes/#csi) are also supported with dynamic provisioning
 and pre-created PVs, but you'll need to look at the documentation for a specific CSI driver
 to see its supported topology keys and examples.
@@ -410,7 +410,7 @@ parameters:
   round-robin-ed across all active zones where Kubernetes cluster has a node.
 
 {{< note >}}
-{{< feature-state state="deprecated" for_k8s_version="1.11" >}}
+{{< feature-state state="deprecated" for_k8s_version="v1.11" >}}
 This internal provisioner of OpenStack is deprecated. Please use [the external cloud provider for OpenStack](https://github.com/kubernetes/cloud-provider-openstack).
 {{< /note >}}
 
diff --git a/content/en/docs/concepts/storage/volume-snapshots.md b/content/en/docs/concepts/storage/volume-snapshots.md
@@ -13,7 +13,7 @@ weight: 20
 
 {{% capture overview %}}
 
-{{< feature-state for_k8s_version="1.17" state="beta" >}}
+{{< feature-state for_k8s_version="v1.17" state="beta" >}}
 In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
 
 {{% /capture %}}
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
@@ -8,7 +8,7 @@ weight: 40
 
 {{% capture overview %}}
 
-{{< feature-state for_k8s_version="1.12" state="stable" >}}
+{{< feature-state for_k8s_version="v1.12" state="stable" >}}
 
 The kubeadm `ClusterConfiguration` object exposes the field `extraArgs` that can override the default flags passed to control plane
 components such as the APIServer, ControllerManager and Scheduler. The components are defined using the following fields:
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
@@ -8,7 +8,7 @@ weight: 80
 
 {{% capture overview %}}
 
-{{< feature-state for_k8s_version="1.11" state="stable" >}}
+{{< feature-state for_k8s_version="v1.11" state="stable" >}}
 
 The lifecycle of the kubeadm CLI tool is decoupled from the
 [kubelet](/docs/reference/command-line-tools-reference/kubelet), which is a daemon that runs
diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md b/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
diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md b/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.
 
diff --git a/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/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.
 
diff --git a/content/en/docs/tasks/administer-cluster/highly-available-master.md b/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.
diff --git a/content/en/docs/tasks/manage-gpus/scheduling-gpus.md b/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.
diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/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 >}}
 
