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

* 'master' of https://github.com/kubernetes/kubernetes.github.io: (87 commits)
  fix envFrom in configmap
  Add link to example for CRDs (#5641)
  Fixed links to architecture.md and principles.md
  Polish AppArmor tutorial
  Remove dangling files related to apparmor
  fix the typo of serviceaccount (#5533)
  Correct setup link (#5634)
  relink the  persistent volume of petset (#5582)
  Updates to case study landing page (#5629)
  translate doc resource-quotas into chinese
  minor encoding fix for CN page
  fix typo
  concepts-overview-components+abac-fix
  concepts-overview-components-fix
  Update links to avoid redirects. (#5627)
  Update links to avoid redirects. (#5625)
  Fix 404s. (#5624)
  Fix 404s. (#5623)
  Edits cpu-constraint-namespace.md
  Fix index redirects (#5502)
  ...

# Conflicts:
#	_redirects
#	docs/concepts/storage/volumes.md
#	docs/concepts/workloads/controllers/daemonset.md
#	docs/concepts/workloads/controllers/petset.md
#	docs/concepts/workloads/controllers/statefulset.md
#	docs/tasks/run-application/run-single-instance-stateful-application.md
#	docs/tutorials/stateful-application/zookeeper.md

docs/concepts/configuration/manage-compute-resources-container.md

@@ -26,7 +26,7 @@ CPU and memory are collectively referred to as *compute resources*, or just
 *resources*. Compute
 resources are measurable quantities that can be requested, allocated, and
 consumed. They are distinct from
-[API resources](/docs/api/). API resources, such as Pods and
+[API resources](/docs/concepts/overview/kubernetes-api/). API resources, such as Pods and
 [Services](/docs/user-guide/services) are objects that can be read and modified
 through the Kubernetes API server.
 

docs/concepts/configuration/organize-cluster-access-kubeconfig.md

@@ -37,16 +37,20 @@ in a variety of ways. For example:
 - Administrators might have sets of certificates that they provide to individual users.
 
 With kubeconfig files, you can organize your clusters, users, and namespaces.
-And you can define contexts that enable users to quickly and easily switch between
+You can also define contexts to quickly and easily switch between
 clusters and namespaces.
 
 ## Context
 
-A kubeconfig file can have *context* elements. Each context is a triple
-(cluster, namespace, user). You can use `kubectl config use-context` to set
-the current context. The `kubectl` command-line tool communicates with the
-cluster and namespace listed in the current context. And it uses the
-credentials of the user listed in the current context.
+A *context* element in a kubeconfig file is used to group access parameters
+under a convenient name. Each context has three parameters: cluster, namespace, and user.
+By default, the `kubectl` command-line tool uses parameters from
+the *current context* to communicate with the cluster. 
+
+To choose the current context:
+```
+kubectl config use-context
+```
 
 ## The KUBECONFIG environment variable
 

docs/concepts/configuration/overview.md

@@ -50,15 +50,15 @@ This is a living document. If you think of something that is not on this list bu
   If you only need access to the port for debugging purposes, you can use the [kubectl proxy and apiserver proxy](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) or [kubectl port-forward](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
   You can use a [Service](/docs/concepts/services-networking/service/) object for external service access.
 
-  If you explicitly need to expose a pod's port on the host machine, consider using a [NodePort](/docs/user-guide/services/#type-nodeport) service before resorting to `hostPort`.
+  If you explicitly need to expose a pod's port on the host machine, consider using a [NodePort](/docs/concepts/services-networking/service/#type-nodeport) service before resorting to `hostPort`.
 
 - Avoid using `hostNetwork`, for the same reasons as `hostPort`.
 
-- Use _headless services_ for easy service discovery when you don't need kube-proxy load balancing. See [headless services](/docs/user-guide/services/#headless-services).
+- Use _headless services_ for easy service discovery when you don't need kube-proxy load balancing. See [headless services](/docs/concepts/services-networking/service/#headless-services).
 
 ## Using Labels
 
-- Define and use [labels](/docs/user-guide/labels/) that identify __semantic attributes__ of your application or deployment. For example, instead of attaching a label to a set of pods to explicitly represent some service (For example, `service: myservice`), or explicitly representing the replication controller managing the pods  (for example, `controller: mycontroller`), attach labels that identify semantic attributes, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. This will let you select the object groups appropriate to the context— for example, a service for all "tier: frontend" pods, or all "test" phase components of app "myapp". See the [guestbook](https://github.com/kubernetes/examples/tree/{{page.githubbranch}}/guestbook/) app for an example of this approach.
+- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or deployment. For example, instead of attaching a label to a set of pods to explicitly represent some service (For example, `service: myservice`), or explicitly representing the replication controller managing the pods  (for example, `controller: mycontroller`), attach labels that identify semantic attributes, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. This will let you select the object groups appropriate to the context— for example, a service for all "tier: frontend" pods, or all "test" phase components of app "myapp". See the [guestbook](https://github.com/kubernetes/examples/tree/{{page.githubbranch}}/guestbook/) app for an example of this approach.
 
   A service can be made to span multiple deployments, such as is done across [rolling updates](/docs/tasks/run-application/rolling-update-replication-controller/), by simply omitting release-specific labels from its selector, rather than updating a service's selector to match the replication controller's selector fully.
 
@@ -84,7 +84,7 @@ This is a living document. If you think of something that is not on this list bu
 
 - Use `kubectl delete` rather than `stop`. `Delete` has a superset of the functionality of `stop`, and `stop` is deprecated.
 
-- Use kubectl bulk operations (via files and/or labels) for get and delete. See [label selectors](/docs/user-guide/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
+- Use kubectl bulk operations (via files and/or labels) for get and delete. See [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
 
 - Use `kubectl run` and `expose` to quickly create and expose single container Deployments. See the [quick start guide](/docs/user-guide/quick-start/) for an example.