Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.7

* 'master' of https://github.com/kubernetes/kubernetes.github.io:
  Fix sentence
  Minor grammatical correction
  Remove beta as K8s support on Bluemix Container Service is live
  Fix some output
  replace REASON with STATUS
  column IP is missed
  replace kubectl.sh with kubectl
  replace KUBECTL with kubectl
  fix the command output
  fix the command output
  fix the command output
  Correcting the typo in init-container's name
  fix typo
  fix typo
  fix typo
  fix typo
  fix typo
  Update pod-overview.md (#3881)
  apps/v1beta1 is not valid (#3814)
  Get access to search console. (#3901)

docs/concepts/workloads/controllers/deployment.md

@@ -526,7 +526,7 @@ Eventually, resume the Deployment and observe a new ReplicaSet coming up with al
 ```shell
 $ kubectl rollout resume deploy nginx
 deployment "nginx" resumed
-$ KUBECTL get rs -w
+$ kubectl get rs -w
 NAME               DESIRED   CURRENT   READY     AGE
 nginx-2142116321   2         2         2         2m
 nginx-3926361531   2         2         0         6s
@@ -543,7 +543,7 @@ nginx-2142116321   0         1         1         2m
 nginx-2142116321   0         0         0         2m
 nginx-3926361531   3         3         3         20s
 ^C
-$ KUBECTL get rs
+$ kubectl get rs
 NAME               DESIRED   CURRENT   READY     AGE
 nginx-2142116321   0         0         0         2m
 nginx-3926361531   3         3         3         28s

docs/concepts/workloads/controllers/jobs-run-to-completion.md

@@ -308,7 +308,7 @@ to keep running, but you want the rest of the pods it creates
 to use a different pod template and for the job to have a new name.
 You cannot update the job because these fields are not updatable.
 Therefore, you delete job `old` but leave its pods
-running, using `kubectl delete jobs/old-one --cascade=false`.
+running, using `kubectl delete jobs/old --cascade=false`.
 Before deleting it, you make a note of what selector it uses:
 
 ```

docs/concepts/workloads/controllers/nginx-deployment.yaml

@@ -1,4 +1,4 @@
-apiVersion: apps/v1beta1
+apiVersion: apps/v1beta1 # for versions before 1.6.0 use extensions/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment

docs/concepts/workloads/controllers/petset.md

@@ -118,7 +118,7 @@ Saving this config into `petset.yaml` and submitting it to a Kubernetes cluster
 ```shell
 $ kubectl create -f petset.yaml
 service "nginx" created
-petset "nginx" created
+petset "web" created
 ```
 
 ## Pet Identity

docs/concepts/workloads/pods/init-containers.md

@@ -218,7 +218,7 @@ Events:
   13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Created        Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
   13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started        Started container with docker id 5ced34a04634
 $ kubectl logs myapp-pod -c init-myservice # Inspect the first init container
-$ kubectl logs myapp-pod -c init-mydd      # Inspect the second init container
+$ kubectl logs myapp-pod -c init-mydb      # Inspect the second init container
 ```
 
 Once we start the `mydb` and `myservice` services, we can see the Init Containers

docs/concepts/workloads/pods/pod-overview.md

@@ -27,7 +27,7 @@ A Pod encapsulates an application container (or, in some cases, multiple contain
 Pods are employed a number of ways in a Kubernetes cluster, including:
 
 * **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
-* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single managable entity.
+* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.
 
 The [Kubernetes Blog](http://blog.kubernetes.io) has some additional information on Pod use cases. For more information, see: