Update cloud controller manager docs to beta 1.11 (#8756)

* Update cloud controller manager docs to beta 1.11

* Use Hugo shortcode for feature state

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

@@ -9,6 +9,11 @@ content_template: templates/concept
 
 {{% capture overview %}}
 
+{{< feature-state for_k8s_version="v1.11" state="beta" >}}
+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" >}}
 
 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/kubernetes/blob/master/pkg/cloudprovider/cloud.go#L29-L50) is satisfied.

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

@@ -9,7 +9,7 @@ content_template: templates/concept
 
 {{% capture overview %}}
 
-{{< feature-state state="alpha" >}}
+{{< feature-state state="beta" >}}
 
 Kubernetes v1.6 introduced a new binary called `cloud-controller-manager`. `cloud-controller-manager` is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the `kube-controller-manager`. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud vendors to evolve independently from the core Kubernetes code.