Merge branch 'master' into deprecation

docs/admin/authentication.md

@@ -35,8 +35,8 @@ or be treated as an anonymous user.
 ## Authentication strategies
 
 Kubernetes uses client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth to
-authenticate API requests through authentication plugins. As HTTP request are
-made to the API server plugins attempts to associate the following attributes
+authenticate API requests through authentication plugins. As HTTP requests are
+made to the API server, plugins attempt to associate the following attributes
 with the request:
 
 * Username: a string which identifies the end user. Common values might be `kube-admin` or `[email protected]`.

docs/hellonode.md

@@ -340,7 +340,7 @@ We can now build and publish a new container image to the registry with an incre
 
 ```shell
 docker build -t gcr.io/$PROJECT_ID/hello-node:v2 .
-gcloud docker push gcr.io/$PROJECT_ID/hello-node:v2
+gcloud docker -- push gcr.io/$PROJECT_ID/hello-node:v2
 ```
 
 Building and pushing this updated image should be much quicker as we take full advantage of the Docker cache.

docs/tutorials/kubernetes-basics/deploy-intro.html

@@ -70,7 +70,7 @@ <h2 style="color: #3771e3;">Deploying your first app on Kubernetes</h2>
 
                 <p>You can create and manage a Deployment by using the Kubernetes command line interface, <b>Kubectl</b>. Kubectl uses the Kubernetes API to interact with the cluster. In this module, you'll learn the most common Kubectl commands needed to create Deployments that run your applications on a Kubernetes cluster.</p>
 
-				<p>When you create a Deployment, you'll need to specify the container image for your application and the number of replicas that you want to run. You can change that information later by updating your Deployment; Modules <a href="5-0.html">5</a> and <a href="5-0.html">6</a> of the bootcamp discuss how you can update your Deployments.</p>
+				<p>When you create a Deployment, you'll need to specify the container image for your application and the number of replicas that you want to run. You can change that information later by updating your Deployment; Modules <a href="/docs/tutorials/kubernetes-basics/scale-intro/">5</a> and <a href="/docs/tutorials/kubernetes-basics/update-intro/">6</a> of the bootcamp discuss how you can scale and update your Deployments.</p>
 
 
 
@@ -85,7 +85,7 @@ <h2 style="color: #3771e3;">Deploying your first app on Kubernetes</h2>
 
 		<div class="row">
 			<div class="col-md-8">
-				<p>For our first Deployment, we’ll use a <a href="https://nodejs.org">NodeJS</a> application packaged in a Docker container. The source code and the Dockerfile are available in the <a href="https://github.com/kubernetes/kubernetes-bootcamp">GitHub repository</a> for the Kubernetes Bootcamp.</p>
+				<p>For our first Deployment, we’ll use a <a href="https://nodejs.org">Node.js</a> application packaged in a Docker container. The source code and the Dockerfile are available in the <a href="https://github.com/kubernetes/kubernetes-bootcamp">GitHub repository</a> for the Kubernetes Bootcamp.</p>
 
 				<p>Now that you know what Deployments are, let’s go to the online tutorial and deploy our first app!</p>
 

docs/tutorials/kubernetes-basics/expose-intro.html

@@ -71,7 +71,7 @@ <h2 style="color: #3771e3;">Services overview</h2>
 
 				<p>A Service provides load balancing of traffic across the contained set of Pods. This is useful when a service is created to group all Pods from a specific Deployment (our application will make use of this in the next module, when we’ll have multiple instances running).</p>
 
-				<p>Services are also responsible for service-discovery within the cluster (covered in Module 6). This will for example allow a frontend service (like a web server) to receive traffic from a backend service (like a database) without worrying about Pods.</p>
+				<p>Services are also responsible for service-discovery within the cluster (covered in <a href="/docs/user-guide/connecting-applications/#accessing-the-service">Accessing the Service</a>). This will for example allow a frontend service (like a web server) to receive traffic from a backend service (like a database) without worrying about Pods.</p>
 
 				<p>Services match a set of Pods using Label Selectors, a grouping primitive that allows logical operation on Labels.</p>
 
@@ -119,7 +119,7 @@ <h2 style="color: #3771e3;">Labels</h2>
 				<p>Labels can be attached to objects at the creation time or later and can be modified at any time.
 				The kubectl run command sets some default Labels/Label Selectors on the new Pods/ Deployment. The link between Labels and Label Selectors defines the relationship between the Deployment and the Pods it creates.</p>
 
-				<p>Let’s expose now our application with the help of a Service, and apply some new Labels.</p>
+				<p>Now let’s expose our application with the help of a Service, and apply some new Labels.</p>
 			</div>
 		</div>
 		<br>

docs/tutorials/stateless-application/expose-external-ip-address-service.md

@@ -103,7 +103,7 @@ provides load balancing for an application that has two running instances.
 
         curl http://<public-node-ip>:<node-port>
 
-    where `<public-node-ip>` us the public IP address of your node,
+    where `<public-node-ip>` is the public IP address of your node,
     and `<node-port>` is the NodePort value for your service.
 
     The response to a successful request is a hello message:

docs/tutorials/stateless-application/expose-external-ip-address.md

@@ -64,7 +64,7 @@ external IP address.
         NAME         CLUSTER-IP     EXTERNAL-IP      PORT(S)    AGE
         my-service   10.3.245.137   104.198.205.71   8080/TCP   54s
 
-    Note: If the external IP address is shown as <pending>, wait for a minute
+    Note: If the external IP address is shown as \<pending\>, wait for a minute
     and enter the same command again.
 
 1. Display detailed information about the Service:
@@ -110,7 +110,7 @@ external IP address.
 
         curl http://<external-ip>:<port>
 
-    where `<external-ip>` us the external IP address of your Service,
+    where `<external-ip>` is the external IP address of your Service,
     and `<port>` is the value of `Port` in your Service description.
 
     The response to a successful request is a hello message:

docs/user-guide/config-best-practices.md

@@ -21,7 +21,7 @@ This document is meant to highlight and consolidate in one place configuration b
 - Don't specify default values unnecessarily, in order to simplify and minimize configs, and to
   reduce error. For example, omit the selector and labels in a `ReplicationController` if you want
   them to be the same as the labels in its `podTemplate`, since those fields are populated from the
-  `podTemplate` labels by default. See the [guestbook app's](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/) .yaml files for some [examples](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/frontend-controller.yaml) of this.
+  `podTemplate` labels by default. See the [guestbook app's](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/) .yaml files for some [examples](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/frontend-deployment.yaml) of this.
 
 - Put an object description in an annotation to allow better introspection.
 

docs/user-guide/labels.md

@@ -99,10 +99,10 @@ _Set-based_ requirements can be mixed with _equality-based_ requirements. For ex
 
 ### LIST and WATCH filtering
 
-LIST and WATCH operations may specify label selectors to filter the sets of objects returned using a query parameter. Both requirements are permitted:
+LIST and WATCH operations may specify label selectors to filter the sets of objects returned using a query parameter. Both requirements are permitted (presented here as they would appear in a URL query string):
 
-    * _equality-based_ requirements: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
-    * _set-based_ requirements: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
+  * _equality-based_ requirements: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
+  * _set-based_ requirements: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
 
 Both label selector styles can be used to list or watch resources via a REST client. For example, targeting `apiserver` with `kubectl` and using _equality-based_ one may write:
 

docs/user-guide/production-pods.md

@@ -204,7 +204,7 @@ The status of the init containers is returned as another annotation - `pod.beta.
 
 Init containers support all of the same features as normal containers, including resource limits, volumes, and security settings. The resource requests and limits for an init container are handled slightly different than normal containers since init containers are run one at a time instead of all at once - any limits or quotas will be applied based on the largest init container resource quantity, rather than as the sum of quantities. Init containers do not support readiness probes since they will run to completion before the pod can be ready.
 
-[Complete Init Container Documentation](/docs/user-guide/pods/init-containers.md)
+[Complete Init Container Documentation](/docs/user-guide/pods/init-container/)
 
 
 ## Lifecycle hooks and termination notice