diff --git a/_includes/code.html b/_includes/code.html
index 59a27ebf1a..d59db08ff7 100644
--- a/_includes/code.html
+++ b/_includes/code.html
@@ -14,7 +14,7 @@
                 {% if ghlink %}<a href="{{ghlink}}" download="{{include.file}}">{% endif %}
                     <code>{{include.file}}</code>
                 {% if ghlink %}</a>{% endif %}
-                <img src="/images/copycode.svg" style="max-height:24px" onClick="copyCode('{{include.file | handleize}}')" title="Copy {{include.file}} to clipboard">
+                <img src="/images/copycode.svg" style="max-height:24px" onclick="copyCode('{{include.file | handleize}}')" title="Copy {{include.file}} to clipboard">
             </th>
         </tr>
     </thead>
diff --git a/_layouts/docwithnav.html b/_layouts/docwithnav.html
index 3d12017366..fc5fb3350e 100755
--- a/_layouts/docwithnav.html
+++ b/_layouts/docwithnav.html
@@ -57,7 +57,7 @@
 
         {{ content }}
 
-        <p><a href=""><img src="https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/{{ page.path }}?pixel" alt="Analytics" /></a>
+        <p><a href=""><img src="https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/{{ page.path }}?pixel" alt="Analytics" /></a></p>
         {% if page.url != "/404.html" and page.url != "/docs/search/" %}
 		<script type="text/javascript">
 	        PDRTJS_settings_8345992 = {
diff --git a/docs/admin/authentication.md b/docs/admin/authentication.md
index aefbbe73b2..b6a4b17193 100644
--- a/docs/admin/authentication.md
+++ b/docs/admin/authentication.md
@@ -287,10 +287,20 @@ To enable the plugin, configure the following flags on the API server:
 | --------- | ----------- | ------- | ------- |
 | `--oidc-issuer-url` | URL of the provider which allows the API server to discover public signing keys. Only URLs which use the `https://` scheme are accepted.  This is typically the provider's discovery URL without a path, for example "https://accounts.google.com" or "https://login.salesforce.com".  This URL should point to the level below .well-known/openid-configuration | If the discovery URL is https://accounts.google.com/.well-known/openid-configuration the value should be https://accounts.google.com | Yes |
 | `--oidc-client-id` |  A client id that all tokens must be issued for. | kubernetes | Yes |
-| `--oidc-username-claim` | JWT claim to use as the user name. By default `sub`, which is expected to be a unique identifier of the end user. Admins can choose other claims, such as `email`, depending on their provider. | sub | No |
+| `--oidc-username-claim` | JWT claim to use as the user name. By default `sub`, which is expected to be a unique identifier of the end user. Admins can choose other claims, such as `email` or `name`, depending on their provider. However, claims other than `email` will be prefixed with the issuer URL to prevent naming clashes with other plugins. | sub | No |
 | `--oidc-groups-claim` | JWT claim to use as the user's group. If the claim is present it must be an array of strings. | groups | No |
 | `--oidc-ca-file` | The path to the certificate for the CA that signed your identity provider's web certificate.  Defaults to the host's root CAs. | `/etc/kubernetes/ssl/kc-ca.pem` | No |
 
+If a claim other than `email` is chosen for `--oidc-username-claim`, the value
+will be prefixed with the `--oidc-issuer-url` to prevent clashes with existing
+Kubernetes names (such as the `system:` users). For example, if the provider
+URL is `https://accounts.google.com` and the username claim maps to `jane`, the
+plugin will authenticate the user as:
+
+```
+https://accounts.google.com#jane
+```
+
 Importantly, the API server is not an OAuth2 client, rather it can only be
 configured to trust a single issuer. This allows the use of public providers,
 such as Google, without trusting credentials issued to third parties. Admins who
diff --git a/docs/concepts/configuration/manage-compute-resources-container.md b/docs/concepts/configuration/manage-compute-resources-container.md
index ad83ae955d..a7da824638 100644
--- a/docs/concepts/configuration/manage-compute-resources-container.md
+++ b/docs/concepts/configuration/manage-compute-resources-container.md
@@ -138,7 +138,7 @@ When using Docker:
 - The `spec.containers[].resources.limits.cpu` is converted to its millicore value,
   multiplied by 100000, and then divided by 1000. This number is used as the value
   of the [`--cpu-quota`](https://docs.docker.com/engine/reference/run/#/cpu-quota-constraint)
-  flag in the `docker run` command.  he [`--cpu-period`] flag is set to 100000,
+  flag in the `docker run` command.  The [`--cpu-period`] flag is set to 100000,
    which represents the default 100ms period for measuring quota usage. The
    kubelet enforces cpu limits if it is started with the
   [`--cpu-cfs-quota`] flag set to true. As of Kubernetes version 1.2, this flag
diff --git a/docs/concepts/workloads/pods/init-containers.md b/docs/concepts/workloads/pods/init-containers.md
index d3dc7beb88..c0487653e5 100644
--- a/docs/concepts/workloads/pods/init-containers.md
+++ b/docs/concepts/workloads/pods/init-containers.md
@@ -35,14 +35,10 @@ Init Containers are exactly like regular Containers, except:
 If an Init Container fails for a Pod, Kubernetes restarts the Pod repeatedly until the Init
 Container succeeds. However, if the Pod has a `restartPolicy` of Never, it is not restarted.
 
-To specify a Container as an Init Container, add the `annotations` key
-`pod.beta.kubernetes.io/init-containers`.  Its value should be a
-JSON array of objects of type
-[Container](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_container).
-
-The status of an Init Container is returned as another annotation,
-`pod.beta.kubernetes.io/init-container-statuses`, which is an array of
-container statuses similar to the `status.containerStatuses` field.
+To specify a Container as an Init Container, add the `initContainers` field on the PodSpec as a JSON array of objects of type [v1.Container](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_container) alongside the app `containers` array.
+The status of the init containers is returned in `status.initContainerStatuses`
+field as an array of the container statuses (similar to the `status.containerStatuses`
+field).
 
 ### Differences from regular Containers
 
@@ -262,9 +258,12 @@ reasons:
 
 ## Support and compatibility
 
-A cluster with Kubelet and Apiserver version 1.4.0 or greater supports Init
-Containers with the beta annotations. Support varies for other combinations of
-Kubelet and Apiserver versions; see the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md) for details.
+A cluster with Apiserver version 1.6.0 or greater supports Init Containers
+using the `spec.initContainers` field. Previous versions support Init Containers
+using the alpha or beta annotations. The `spec.initContainers` field is also mirrored
+into alpha and beta annotations so that Kubelets version 1.3.0 or greater can execute
+Init Containers, and so that a version 1.6 apiserver can safely be rolled back to version
+1.5.x without losing Init Container functionality for existing created pods.
 
 {% endcapture %}
 
diff --git a/docs/getting-started-guides/kargo.md b/docs/getting-started-guides/kargo.md
index 0a2e1d1c44..f314870a78 100644
--- a/docs/getting-started-guides/kargo.md
+++ b/docs/getting-started-guides/kargo.md
@@ -2,10 +2,6 @@
 title: Installing Kubernetes On-premise/Cloud Providers with Kargo
 ---
 
-<style>
-li>.highlighter-rouge {position:relative; top:3px;}
-</style>
-
 ## Overview
 
 This quickstart helps to install a Kubernetes cluster hosted
@@ -47,7 +43,7 @@ to [kubeadm](../kubeadm) and [kops](../kops).
 * Customize your deployment by usual Ansible meanings, which is
   [generating inventory](https://github.com/kubernetes-incubator/kargo/blob/master/docs/getting-started.md#building-your-own-inventory)
   and overriding default data [variables](https://github.com/kubernetes-incubator/kargo/blob/master/docs/vars.md).
-  Or just stick with default values (Kargo will choose Flannel networking plugin for you
+  Or just stick with default values (Kargo will choose Calico networking plugin for you
   then). This includes steps like deciding on the:
   * DNS [configuration options](https://github.com/kubernetes-incubator/kargo/blob/master/docs/dns-stack.md)
   * [Networking plugin](https://github.com/kubernetes-incubator/kargo#network-plugins) to use
diff --git a/docs/getting-started-guides/kops.md b/docs/getting-started-guides/kops.md
index 0b2381dd18..e2e5a952ac 100644
--- a/docs/getting-started-guides/kops.md
+++ b/docs/getting-started-guides/kops.md
@@ -2,10 +2,6 @@
 title: Installing Kubernetes on AWS with kops
 ---
 
-<style>
-li>.highlighter-rouge {position:relative; top:3px;}
-</style>
-
 ## Overview
 
 This quickstart shows you how to easily install a Kubernetes cluster on AWS.
diff --git a/docs/getting-started-guides/kubeadm.md b/docs/getting-started-guides/kubeadm.md
index 47c997e151..6c7d7eb643 100644
--- a/docs/getting-started-guides/kubeadm.md
+++ b/docs/getting-started-guides/kubeadm.md
@@ -7,10 +7,6 @@ assignees:
 title: Installing Kubernetes on Linux with kubeadm
 ---
 
-<style>
-li>.highlighter-rouge {position:relative; top:3px;}
-</style>
-
 ## Overview
 
 This quickstart shows you how to easily install a Kubernetes cluster on machines
diff --git a/docs/getting-started-guides/rkt/notes.md b/docs/getting-started-guides/rkt/notes.md
index 2654ed22f7..222a652f16 100644
--- a/docs/getting-started-guides/rkt/notes.md
+++ b/docs/getting-started-guides/rkt/notes.md
@@ -51,15 +51,15 @@ Because of this, some flags in `kubectl run` are not supported, including:
 
 ## Volume relabeling
 
-Currently rkt supports only *per-pod* volume relabeling. After relabeling, the mounted volume is shared by all containers in the pod. There is not yet a way to make the relabeled volume accessible to only one, or some subset, of containers in the pod. [Kubernetes issue # 28187](https://github.com/kubernetes/kubernetes/issues/28187) has the details.
+Currently rkt supports only *per-pod* volume relabeling. After relabeling, the mounted volume is shared by all Containers in the pod. There is not yet a way to make the relabeled volume accessible to only one, or some subset, of Containers in the pod. [Kubernetes issue # 28187](https://github.com/kubernetes/kubernetes/issues/28187) has the details.
 
 ## kubectl get logs
 
 Under rktnetes, `kubectl get logs` currently cannot get logs from applications that write them to directly to `/dev/stdout`. Currently such log messages are printed on the node's console.
 
-## Init containers
+## Init Containers
 
-The beta [init container](/docs/user-guide/pods/init-containers.md) feature is currently not supported.
+[Init Container](/docs/user-guide/pods/init-containers.md) feature is currently not supported.
 
 ## Container restart back-off
 
@@ -71,7 +71,7 @@ The `--experimental-nvidia-gpus` flag, and related [GPU features](https://github
 
 ## QoS Classes
 
-Under rkt, QoS classes do not adjust the `OOM Score` of containers as occurs under Docker.
+Under rkt, QoS classes do not adjust the `OOM Score` of Containers as occurs under Docker.
 
 ## HostPID and HostIPC namespaces
 
diff --git a/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
index 08a18f8f08..9961273df2 100644
--- a/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
+++ b/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
@@ -23,7 +23,7 @@ the default reclaim policy is "Delete". This means that a dynamically provisione
 volume is automatically deleted when a user deletes the corresponding
 `PeristentVolumeClaim`. This automatic behavior might be inappropriate if the volume
 contains precious data. In that case, it is more appropriate to use the "Retain"
-policy. With the "Retain" policy, if a user deletes a `PeristentVolumeClaim`,
+policy. With the "Retain" policy, if a user deletes a `PersistentVolumeClaim`,
 the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to the
 `Released` phase, where all of its data can be manually recovered.
 
diff --git a/docs/tasks/configure-pod-container/configure-pod-initialization.md b/docs/tasks/configure-pod-container/configure-pod-initialization.md
index 0c72d7ab84..e657323003 100644
--- a/docs/tasks/configure-pod-container/configure-pod-initialization.md
+++ b/docs/tasks/configure-pod-container/configure-pod-initialization.md
@@ -3,7 +3,7 @@ title: Configuring Pod Initialization
 ---
 
 {% capture overview %}
-This page shows how to use an init Container to initialize a Pod before the
+This page shows how to use an Init Container to initialize a Pod before an
 application Container runs.
 
 {% endcapture %}
@@ -16,10 +16,10 @@ application Container runs.
 
 {% capture steps %}
 
-## Creating a Pod that has an init Container
+## Creating a Pod that has an Init Container
 
 In this exercise you create a Pod that has one application Container and one
-init Container. The init Container runs to completion before the application
+Init Container. The init container runs to completion before the application
 container starts.
 
 Here is the configuration file for the Pod:
@@ -27,33 +27,32 @@ Here is the configuration file for the Pod:
 {% include code.html language="yaml" file="init-containers.yaml" ghlink="/docs/tasks/configure-pod-container/init-containers.yaml" %}
 
 In the configuration file, you can see that the Pod has a Volume that the init
-Container and the application Container share. Notice that the init Container
-is a beta feature and is specified as an annotation.
+container and the application container share.
 
-The init Container mounts the
-shared Volume at `/work-dir`, and the application Container mounts the shared
-Volume at `/usr/share/nginx/html`. The init Container runs the following command
+The init container mounts the
+shared Volume at `/work-dir`, and the application container mounts the shared
+Volume at `/usr/share/nginx/html`. The init container runs the following command
 and then terminates:
 
      wget -O /work-dir/index.html http://kubernetes.io
 
-Notice that the init Container writes the `index.html` file in the root directory
+Notice that the init container writes the `index.html` file in the root directory
 of the nginx server.
 
 Create the Pod:
 
     kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/init-containers.yaml
 
-Verify that the nginx Container is running:
+Verify that the nginx container is running:
 
     kubectl get pod init-demo
 
-The output shows that the nginx Container is running:
+The output shows that the nginx container is running:
 
     NAME      READY     STATUS    RESTARTS   AGE
     nginx     1/1       Running   0          43m
 
-Get a shell into nginx the Container running in the init-demo Pod:
+Get a shell into the nginx container running in the init-demo Pod:
 
     kubectl exec -it init-demo -- /bin/bash
 
@@ -83,7 +82,7 @@ The output shows that nginx is serving the web page that was written by the init
 
 * Learn more about
 [communicating between Containers running in the same Pod](/docs/tasks/configure-pod-container/communicate-containers-same-pod/).
-* Learn more about [init Containers](/docs/user-guide/pods/init-container/).
+* Learn more about [Init Containers](/docs/concepts/workloads/pods/init-containers/).
 * Learn more about [Volumes](/docs/concepts/storage/volumes/).
 
 {% endcapture %}
diff --git a/docs/tasks/configure-pod-container/init-containers.yaml b/docs/tasks/configure-pod-container/init-containers.yaml
index 80e135b459..35c393d7c7 100644
--- a/docs/tasks/configure-pod-container/init-containers.yaml
+++ b/docs/tasks/configure-pod-container/init-containers.yaml
@@ -2,20 +2,6 @@ apiVersion: v1
 kind: Pod
 metadata:
   name: init-demo
-  annotations:
-    pod.beta.kubernetes.io/init-containers: '[
-        {
-            "name": "install",
-            "image": "busybox",
-            "command": ["wget", "-O", "/work-dir/index.html", "http://kubernetes.io"],
-            "volumeMounts": [
-                {
-                    "name": "workdir",
-                    "mountPath": "/work-dir"
-                }
-            ]
-        }
-    ]'
 spec:
   containers:
   - name: nginx
@@ -25,6 +11,18 @@ spec:
     volumeMounts:
     - name: workdir
       mountPath: /usr/share/nginx/html
+  # These containers are run during pod initialization
+  initContainers:
+  - name: install
+    image: busybox
+    command:
+    - wget
+    - "-O"
+    - "/work-dir/index.html"
+    - http://kubernetes.io
+    volumeMounts:
+    - name: workdir
+      mountPath: "/work-dir"
   dnsPolicy: Default
   volumes:
   - name: workdir
diff --git a/docs/tasks/debug-application-cluster/debug-init-containers.md b/docs/tasks/debug-application-cluster/debug-init-containers.md
index 77abef0a84..d971c12c68 100644
--- a/docs/tasks/debug-application-cluster/debug-init-containers.md
+++ b/docs/tasks/debug-application-cluster/debug-init-containers.md
@@ -91,11 +91,11 @@ Init Containers:
 ```
 
 You can also access the Init Container statuses programmatically by reading the
-`pod.beta.kubernetes.io/init-container-status` annotation on the Pod:
+`status.initContainerStatuses` field on the Pod Spec:
 
 {% raw %}
 ```shell
-kubectl get pod <pod-name> --template '{{index .metadata.annotations "pod.beta.kubernetes.io/init-container-statuses"}}'
+kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
 ```
 {% endraw %}
 
diff --git a/docs/tasks/debug-application-cluster/monitor-node-health.md b/docs/tasks/debug-application-cluster/monitor-node-health.md
index 08ca3208dd..693e0b45c1 100644
--- a/docs/tasks/debug-application-cluster/monitor-node-health.md
+++ b/docs/tasks/debug-application-cluster/monitor-node-health.md
@@ -36,7 +36,7 @@ it to [support other log format](/docs/admin/node-problem/#support-other-log-for
 
 ## Enable/Disable in GCE cluster
 
-Node problem detector is [running as a cluster addon](cluster-large.md/#addon-resources) enabled by default in the
+Node problem detector is [running as a cluster addon](/docs/admin/cluster-large/#addon-resources) enabled by default in the
 gce cluster.
 
 You can enable/disable it by setting the environment variable
@@ -194,8 +194,8 @@ and detects known kernel issues following predefined rules.
 
 The Kernel Monitor matches kernel issues according to a set of predefined rule list in
 [`config/kernel-monitor.json`](https://github.com/kubernetes/node-problem-detector/blob/v0.1/config/kernel-monitor.json).
-The rule list is extensible, and you can always extend it by [overwriting the
-configuration](/docs/admin/node-problem/#overwrite-the-configuration).
+The rule list is extensible, and you can always extend it by overwriting the
+configuration.
 
 ### Add New NodeConditions
 
diff --git a/docs/tasks/index.md b/docs/tasks/index.md
index 030fec7939..9b3abe09de 100644
--- a/docs/tasks/index.md
+++ b/docs/tasks/index.md
@@ -13,7 +13,7 @@ single thing, typically by giving a short sequence of steps.
 
 #### Using the kubectl Command Line
 
-* [Listing Alll Container Images Running in a Cluster](/docs/tasks/kubectl/list-all-running-container-images/)
+* [Listing All Container Images Running in a Cluster](/docs/tasks/kubectl/list-all-running-container-images/)
 * [Getting a Shell to a Running Container](/docs/tasks/kubectl/get-shell-running-container/)
 
 #### Configuring Pods and Containers
diff --git a/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md b/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md
index f0e1fea561..02ab4e485b 100644
--- a/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md
+++ b/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md
@@ -383,7 +383,7 @@ The `kubectl apply` command writes the contents of the configuration file to the
 `kubectl.kubernetes.io/last-applied-configuration` annotation. This
 is used to identify fields that have been removed from the configuration
 file and need to be cleared from the live configuration. Here are the steps used
-to caluculate which fields should be deleted or set:
+to calculate which fields should be deleted or set:
 
 1. Calculate the fields to delete. These are the fields present in `last-applied-configuration` and missing from the configuration file.
 2. Calculate the fields to add or set. These are the fields present in the configuration file whose values don't match the live configuration.
diff --git a/docs/tutorials/object-management-kubectl/imperative-object-management-configuration.md b/docs/tutorials/object-management-kubectl/imperative-object-management-configuration.md
index 196d26fa8a..72196b9fd9 100644
--- a/docs/tutorials/object-management-kubectl/imperative-object-management-configuration.md
+++ b/docs/tutorials/object-management-kubectl/imperative-object-management-configuration.md
@@ -62,7 +62,7 @@ The `create`, `replace`, and `delete` commands work well when each object's
 configuration is fully defined and recorded in its configuration
 file. However when a live object is updated, and the updates are not merged
 into its configuration file, the updates will be lost the next time a `replace`
-is executed. This is can happen if a controller, such as
+is executed. This can happen if a controller, such as
 a HorizontalPodAutoscaler, makes updates directly to a live object. Here's 
 an example:
 
diff --git a/docs/tutorials/stateful-application/run-replicated-stateful-application.md b/docs/tutorials/stateful-application/run-replicated-stateful-application.md
index cdc373b00d..042b694255 100644
--- a/docs/tutorials/stateful-application/run-replicated-stateful-application.md
+++ b/docs/tutorials/stateful-application/run-replicated-stateful-application.md
@@ -151,8 +151,6 @@ properties to perform orderly startup of MySQL replication.
 Before starting any of the containers in the Pod spec, the Pod first runs any
 [Init Containers](/docs/user-guide/production-pods/#handling-initialization)
 in the order defined.
-In the StatefulSet manifest, you can find these defined within the
-`pod.beta.kubernetes.io/init-containers` annotation.
 
 The first Init Container, named `init-mysql`, generates special MySQL config
 files based on the ordinal index.
diff --git a/docs/tutorials/stateless-application/run-stateless-application-deployment.md b/docs/tutorials/stateless-application/run-stateless-application-deployment.md
index 831ed6bb45..012d217f84 100644
--- a/docs/tutorials/stateless-application/run-stateless-application-deployment.md
+++ b/docs/tutorials/stateless-application/run-stateless-application-deployment.md
@@ -61,6 +61,10 @@ a Deployment that runs the nginx:1.7.9 Docker image:
         StrategyType:   RollingUpdate
         MinReadySeconds:  0
         RollingUpdateStrategy:  1 max unavailable, 1 max surge
+        Conditions:
+          Type          Status  Reason
+          ----          ------  ------
+          Available     True    MinimumReplicasAvailable
         OldReplicaSets:   <none>
         NewReplicaSet:    nginx-deployment-1771418926 (2/2 replicas created)
         No events.
diff --git a/docs/user-guide/configmap/index.md b/docs/user-guide/configmap/index.md
index ae5880c162..f24866f10b 100644
--- a/docs/user-guide/configmap/index.md
+++ b/docs/user-guide/configmap/index.md
@@ -46,7 +46,7 @@ of configuration files.
 
 Configuration data can be consumed in pods in a variety of ways.  ConfigMaps can be used to:
 
-1.  Populate the value of environment variables
+1.  Populate the values of environment variables
 2.  Set command-line arguments in a container
 3.  Populate config files in a volume
 
diff --git a/docs/user-guide/kubectl/kubectl_completion.md b/docs/user-guide/kubectl/kubectl_completion.md
index f870bbd482..6ceabb2cb5 100644
--- a/docs/user-guide/kubectl/kubectl_completion.md
+++ b/docs/user-guide/kubectl/kubectl_completion.md
@@ -9,7 +9,7 @@ Output shell completion code for the given shell (bash or zsh)
 
 Output shell completion code for the given shell (bash or zsh).
 
-This command prints shell code which must be evaluation to provide interactive completion of kubectl commands.
+This command prints shell code which must be evaluated to provide interactive completion of kubectl commands.
 
   `$ source <(kubectl completion bash)`
 
diff --git a/docs/user-guide/namespaces.md b/docs/user-guide/namespaces.md
index d162139358..1ce6861760 100644
--- a/docs/user-guide/namespaces.md
+++ b/docs/user-guide/namespaces.md
@@ -64,16 +64,8 @@ $ kubectl --namespace=<insert-namespace-name-here> get pods
 You can permanently save the namespace for all subsequent kubectl commands in that
 context.
 
-First get your current context:
-
 ```shell
-$ export CONTEXT=$(kubectl config view | awk '/current-context/ {print $2}')
-```
-
-Then update the default namespace:
-
-```shell
-$ kubectl config set-context $CONTEXT --namespace=<insert-namespace-name-here>
+$ kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here>
 # Validate it
 $ kubectl config view | grep namespace:
 ```
diff --git a/docs/user-guide/nginx-init-containers.yaml b/docs/user-guide/nginx-init-containers.yaml
index 24124c7459..fdfde0619a 100644
--- a/docs/user-guide/nginx-init-containers.yaml
+++ b/docs/user-guide/nginx-init-containers.yaml
@@ -2,20 +2,6 @@ apiVersion: v1
 kind: Pod
 metadata:
   name: nginx
-  annotations:
-    pod.beta.kubernetes.io/init-containers: '[
-        {
-            "name": "install",
-            "image": "busybox",
-            "command": ["wget", "-O", "/work-dir/index.html", "http://kubernetes.io/index.html"],
-            "volumeMounts": [
-                {
-                    "name": "workdir",
-                    "mountPath": "/work-dir"
-                }
-            ]
-        }
-    ]'
 spec:
   containers:
   - name: nginx
@@ -25,6 +11,18 @@ spec:
     volumeMounts:
     - name: workdir
       mountPath: /usr/share/nginx/html
+  # These containers are run during pod initialization
+  initContainers:
+  - name: install
+    image: busybox
+    command:
+    - wget
+    - "-O"
+    - "/work-dir/index.html"
+    - http://kubernetes.io/index.html
+    volumeMounts:
+    - name: workdir
+      mountPath: "/work-dir"
   dnsPolicy: Default
   volumes:
   - name: workdir
diff --git a/docs/user-guide/pod-security-policy/index.md b/docs/user-guide/pod-security-policy/index.md
index 2138e1b446..6806a103fa 100644
--- a/docs/user-guide/pod-security-policy/index.md
+++ b/docs/user-guide/pod-security-policy/index.md
@@ -112,6 +112,9 @@ to the volume sources that are defined when creating a volume:
 The recommended minimum set of allowed volumes for new PSPs are 
 configMap, downwardAPI, emptyDir, persistentVolumeClaim, and secret.
 
+### Host Network
+ - *HostPorts*, default `empty`. List of `HostPortRange`, defined by `min`(inclusive) and `max`(inclusive), which define the allowed host ports.
+ 
 ## Admission
 
 _Admission control_ with `PodSecurityPolicy` allows for control over the creation of resources
diff --git a/docs/user-guide/pod-security-policy/psp.yaml b/docs/user-guide/pod-security-policy/psp.yaml
index a16c1f350d..b2cdded9e4 100644
--- a/docs/user-guide/pod-security-policy/psp.yaml
+++ b/docs/user-guide/pod-security-policy/psp.yaml
@@ -17,6 +17,12 @@
       "fsGroup": {
           "rule": "RunAsAny"
       },
+      "HostPorts": [
+          {
+          "min": 8000,
+          "max": 8080
+          }
+      ],
       "volumes": ["*"]
   }
 }