diff --git a/docs/tutorials/services/source-ip.md b/docs/tutorials/services/source-ip.md
index 4f5f7d884a..0df6c11f58 100644
--- a/docs/tutorials/services/source-ip.md
+++ b/docs/tutorials/services/source-ip.md
@@ -174,7 +174,7 @@ service "nodeport" annotated
Now, re-run the test:
```console
-$ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; do
+$ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done
client_address=104.132.1.79
```
diff --git a/docs/tutorials/stateless-application/expose-external-ip-address-service.md b/docs/tutorials/stateless-application/expose-external-ip-address-service.md
index f4a63b1e31..8564ed7d72 100644
--- a/docs/tutorials/stateless-application/expose-external-ip-address-service.md
+++ b/docs/tutorials/stateless-application/expose-external-ip-address-service.md
@@ -1,5 +1,8 @@
---
title: Using a Service to Access an Application in a Cluster
+redirect_from:
+- "/docs/user-guide/quick-start/"
+- "/docs/user-guide/quick-start.html"
---
{% capture overview %}
diff --git a/docs/tutorials/stateless-application/run-stateless-application-deployment.md b/docs/tutorials/stateless-application/run-stateless-application-deployment.md
index 2b9793bfa4..831ed6bb45 100644
--- a/docs/tutorials/stateless-application/run-stateless-application-deployment.md
+++ b/docs/tutorials/stateless-application/run-stateless-application-deployment.md
@@ -3,6 +3,10 @@ title: Running a Stateless Application Using a Deployment
redirect_from:
- "/docs/user-guide/simple-nginx/"
- "/docs/user-guide/simple-nginx.html"
+- "/docs/user-guide/pods/single-container/"
+- "/docs/user-guide/pods/single-container.html"
+- "/docs/user-guide/deploying-applications/"
+- "/docs/user-guide/deploying-applications.html"
---
{% capture overview %}
diff --git a/docs/user-guide/configuring-containers.md b/docs/user-guide/configuring-containers.md
deleted file mode 100644
index 8e09d7aaa4..0000000000
--- a/docs/user-guide/configuring-containers.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Configuring Containers
----
-
-{% include user-guide-content-moved.md %}
-
-[Tasks](/docs/tasks/)
diff --git a/docs/user-guide/containers.md b/docs/user-guide/containers.md
deleted file mode 100644
index dfe48ade49..0000000000
--- a/docs/user-guide/containers.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-assignees:
-- mikedanese
-title: Commands and Capabilities
----
-
-{% include user-guide-content-moved.md %}
-
-* [Container Command and Arguments](/docs/concepts/configuration/container-command-args/)
-* [Container Capabilities](/docs/concepts/policy/container-capabilities/)
diff --git a/docs/user-guide/cron-jobs.md b/docs/user-guide/cron-jobs.md
index b49f34179c..914d98b1fa 100644
--- a/docs/user-guide/cron-jobs.md
+++ b/docs/user-guide/cron-jobs.md
@@ -32,7 +32,7 @@ A typical use case is:
### Prerequisites
-You need a working Kubernetes cluster at version >= 1.4 (for ScheduledJob), >= 1.5 (for CronJobs),
+You need a working Kubernetes cluster at version >= 1.4 (for ScheduledJob), >= 1.5 (for CronJob),
with batch/v2alpha1 API turned on by passing `--runtime-config=batch/v2alpha1` while bringing up
the API server (see [Turn on or off an API version for your cluster](/docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster)
for more). You cannot use Cron Jobs on a hosted Kubernetes provider that has disabled alpha resources.
diff --git a/docs/user-guide/deploying-applications.md b/docs/user-guide/deploying-applications.md
deleted file mode 100644
index a1c04e1003..0000000000
--- a/docs/user-guide/deploying-applications.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-assignees:
-- bgrant0607
-- caesarxuchao
-- thockin
-title: Deploying Applications
----
-
-{% include user-guide-content-moved.md %}
-
-[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/)
diff --git a/docs/user-guide/deployments.md b/docs/user-guide/deployments.md
index 6028e11337..cb5c6abbdf 100644
--- a/docs/user-guide/deployments.md
+++ b/docs/user-guide/deployments.md
@@ -622,7 +622,7 @@ See the [Kubernetes API conventions](https://github.com/kubernetes/community/blo
Note that in version 1.5, Kubernetes will take no action on a stalled Deployment other than to report a status condition with
`Reason=ProgressDeadlineExceeded`.
-**Note:** If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can safely pause a Deployment in the middle of a rollout and resume without triggering a the condition for exceeding the deadline.
+**Note:** If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can safely pause a Deployment in the middle of a rollout and resume without triggering the condition for exceeding the deadline.
You may experience transient errors with your Deployments, either due to a low timeout that you have set or due to any other kind
of error that can be treated as transient. For example, let's suppose you have insufficient quota. If you describe the Deployment
diff --git a/docs/user-guide/index.md b/docs/user-guide/index.md
index 0d4e77a97d..1f045cb7e0 100644
--- a/docs/user-guide/index.md
+++ b/docs/user-guide/index.md
@@ -8,7 +8,7 @@ The Kubernetes **Guides** can help you work with various aspects of the Kubernet
* The Kubernetes [User Guide](#user-guide-internal) can help you run programs and services on an existing Kubernetes cluster.
* The [Cluster Admin Guide](/docs/admin/) can help you set up and administrate your own Kubernetes cluster.
-* The [Developer Guide](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel) can help you either write code to directly access the Kubernetes API, or to contribute directly to the Kubernetes project.
+* The [Developer Guide] can help you either write code to directly access the Kubernetes API, or to contribute directly to the Kubernetes project.
##
Kubernetes User Guide
@@ -86,3 +86,5 @@ Pods and containers
* [Configuration Best Practices and Tips](/docs/user-guide/config-best-practices/)
* [Assign pods to selected nodes](/docs/user-guide/node-selection/)
* [Perform a rolling update on a running group of pods](/docs/user-guide/update-demo/)
+
+[Developer Guide]: https://github.com/kubernetes/community/blob/master/contributors/devel/README.md
diff --git a/docs/user-guide/jobs/expansions/index.md b/docs/user-guide/jobs/expansions/index.md
index f401574519..8d5cb87bd4 100644
--- a/docs/user-guide/jobs/expansions/index.md
+++ b/docs/user-guide/jobs/expansions/index.md
@@ -71,7 +71,7 @@ job "process-item-cherry" created
Now, check on the jobs:
```shell
-$ kubectl get jobs -l app=jobexample
+$ kubectl get jobs -l jobgroup=jobexample
JOB CONTAINER(S) IMAGE(S) SELECTOR SUCCESSFUL
process-item-apple c busybox app in (jobexample),item in (apple) 1
process-item-banana c busybox app in (jobexample),item in (banana) 1
@@ -85,7 +85,7 @@ do not care to see.)
We can check on the pods as well using the same label selector:
```shell
-$ kubectl get pods -l app=jobexample
+$ kubectl get pods -l jobgroup=jobexample --show-all
NAME READY STATUS RESTARTS AGE
process-item-apple-kixwv 0/1 Completed 0 4m
process-item-banana-wrsf7 0/1 Completed 0 4m
@@ -96,7 +96,7 @@ There is not a single command to check on the output of all jobs at once,
but looping over all the pods is pretty easy:
```shell
-$ for p in $(kubectl get pods -l app=jobexample -o name)
+$ for p in $(kubectl get pods -l jobgroup=jobexample -o name)
do
kubectl logs $p
done
diff --git a/docs/user-guide/kubectl/kubectl_proxy.md b/docs/user-guide/kubectl/kubectl_proxy.md
index 9616d6add6..f2e4b9f58a 100644
--- a/docs/user-guide/kubectl/kubectl_proxy.md
+++ b/docs/user-guide/kubectl/kubectl_proxy.md
@@ -11,19 +11,26 @@ Run a proxy to the Kubernetes API server
To proxy all of the Kubernetes api and nothing else, use:
+```
$ kubectl proxy --api-prefix=/
+```
To proxy only part of the Kubernetes api and also some static files:
+```
$ kubectl proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/
+```
The above lets you 'curl localhost:8001/api/v1/pods'.
To proxy the entire Kubernetes api at a different root, use:
+```
$ kubectl proxy --api-prefix=/custom/
+```
+
+The above lets you `curl localhost:8001/custom/api/v1/pods`
-The above lets you 'curl localhost:8001/custom/api/v1/pods'
```
kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix]
diff --git a/docs/user-guide/logging/elasticsearch.md b/docs/user-guide/logging/elasticsearch.md
index c61cfd7cd1..e55de7f30f 100644
--- a/docs/user-guide/logging/elasticsearch.md
+++ b/docs/user-guide/logging/elasticsearch.md
@@ -5,99 +5,6 @@ assignees:
title: Logging with Elasticsearch and Kibana
---
-On the Google Compute Engine (GCE) platform, the default logging support targets
-[Stackdriver Logging](https://cloud.google.com/logging/), which is described in detail
-in the [Logging With Stackdriver Logging](/docs/user-guide/logging/stackdriver).
+{% include user-guide-content-moved.md %}
-This article describes how to set up a cluster to ingest logs into
-[Elasticsearch](https://www.elastic.co/products/elasticsearch), and view
-them using [Kibana](https://www.elastic.co/products/kibana), as an alternative to
-Stackdriver Logging when running on GCE. Note that Elasticsearch and Kibana do not work with Kubernetes clusters hosted on Google Container Engine.
-
-To use Elasticsearch and Kibana for cluster logging, you should set the
-following environment variable as shown below when creating your cluster with
-kube-up.sh:
-
-```shell
-KUBE_LOGGING_DESTINATION=elasticsearch
-```
-
-You should also ensure that `KUBE_ENABLE_NODE_LOGGING=true` (which is the default for the GCE platform).
-
-Now, when you create a cluster, a message will indicate that the Fluentd log
-collection daemons that run on each node will target Elasticsearch:
-
-```shell
-$ cluster/kube-up.sh
-...
-Project: kubernetes-satnam
-Zone: us-central1-b
-... calling kube-up
-Project: kubernetes-satnam
-Zone: us-central1-b
-+++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel
-+++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d)
-+++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0)
-Looking for already existing resources
-Starting master and configuring firewalls
-Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd].
-NAME ZONE SIZE_GB TYPE STATUS
-kubernetes-master-pd us-central1-b 20 pd-ssd READY
-Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip].
-+++ Logging using Fluentd to elasticsearch
-```
-
-The per-node Fluentd pods, the Elasticsearch pods, and the Kibana pods should
-all be running in the kube-system namespace soon after the cluster comes to
-life.
-
-```shell
-$ kubectl get pods --namespace=kube-system
-NAME READY REASON RESTARTS AGE
-elasticsearch-logging-v1-78nog 1/1 Running 0 2h
-elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h
-fluentd-elasticsearch-kubernetes-node-5oq0 1/1 Running 0 2h
-fluentd-elasticsearch-kubernetes-node-6896 1/1 Running 0 2h
-fluentd-elasticsearch-kubernetes-node-l1ds 1/1 Running 0 2h
-fluentd-elasticsearch-kubernetes-node-lz9j 1/1 Running 0 2h
-kibana-logging-v1-bhpo8 1/1 Running 0 2h
-kube-dns-v3-7r1l9 3/3 Running 0 2h
-monitoring-heapster-v4-yl332 1/1 Running 1 2h
-monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h
-```
-
-The `fluentd-elasticsearch` pods gather logs from each node and send them to
-the `elasticsearch-logging` pods, which are part of a
-[service](/docs/user-guide/services/) named `elasticsearch-logging`. These
-Elasticsearch pods store the logs and expose them via a REST API.
-The `kibana-logging` pod provides a web UI for reading the logs stored in
-Elasticsearch, and is part of a service named `kibana-logging`.
-
-The Elasticsearch and Kibana services are both in the `kube-system` namespace
-and are not directly exposed via a publicly reachable IP address. To reach them,
-follow the instructions for [Accessing services running in a cluster](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster).
-
-If you try accessing the `elasticsearch-logging` service in your browser, you'll
-see a status page that looks something like this:
-
-
-
-You can now type Elasticsearch queries directly into the browser, if you'd
-like. See [Elasticsearch's documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)
-for more details on how to do so.
-
-Alternatively, you can view your cluster's logs using Kibana (again using the
-[instructions for accessing a service running in the cluster](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster)).
-The first time you visit the Kibana URL you will be presented with a page that
-asks you to configure your view of the ingested logs. Select the option for
-timeseries values and select `@timestamp`. On the following page select the
-`Discover` tab and then you should be able to see the ingested logs.
-You can set the refresh interval to 5 seconds to have the logs
-regularly refreshed.
-
-Here is a typical view of ingested logs from the Kibana viewer:
-
-
-
-Kibana opens up all sorts of powerful options for exploring your logs! For some
-ideas on how to dig into it, check out [Kibana's documentation](https://www.elastic.co/guide/en/kibana/current/discover.html).
+[Logging Using ElasticSearch and Kibana](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)
diff --git a/docs/user-guide/logging/overview.md b/docs/user-guide/logging/overview.md
index 42b9087172..e5d2e24ae4 100644
--- a/docs/user-guide/logging/overview.md
+++ b/docs/user-guide/logging/overview.md
@@ -5,219 +5,6 @@ assignees:
title: Logging Overview
---
-Application and systems logs can help you understand what is happening inside your cluster. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism; as such, most container engines are likewise designed to support some kind of logging. The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams.
+{% include user-guide-content-moved.md %}
-However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution. For example, if a container crashes, a pod is evicted, or a node dies, you'll usually still want to access your application's logs. As such, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level-logging_. Cluster-level logging requires a separate backend to store, analyze, and query logs. Kubernetes provides no native storage solution for log data, but you can integrate many existing logging solutions into your Kubernetes cluster.
-
-This document includes:
-
-* A basic demonstration of logging in Kubernetes using the standard output stream
-* A detailed description of the node logging architecture in Kubernetes
-* Guidance for implementing cluster-level logging in Kubernetes
-
-The guidance for cluster-level logging assumes that a logging backend is present inside or outside of your cluster. If you're not interested in having cluster-level logging, you might still find the description of how logs are stored and handled on the node to be useful.
-
-## Basic logging in Kubernetes
-
-In this section, you can see an example of basic logging in Kubernetes that
-outputs data to the standard output stream. This demonstration uses
-a [pod specification](/docs/user-guide/logging/examples/counter-pod.yaml) with
-a container that writes some text to standard output once per second.
-
-{% include code.html language="yaml" file="examples/counter-pod.yaml" ghlink="/docs/user-guide/logging/examples/counter-pod.yaml" %}
-
-To run this pod, use the following command:
-
-```shell
-$ kubectl create -f http://k8s.io/docs/user-guide/logging/examples/counter-pod.yaml
-pod "counter" created
-```
-
-To fetch the logs, use the `kubectl logs` command, as follows
-
-```shell
-$ kubectl logs counter
-0: Mon Jan 1 00:00:00 UTC 2001
-1: Mon Jan 1 00:00:01 UTC 2001
-2: Mon Jan 1 00:00:02 UTC 2001
-...
-```
-
-You can use `kubectl logs` to retrieve logs from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/user-guide/kubectl/kubectl_logs/) for more details.
-
-## Logging at the node level
-
-
-
-Everything a containerized application writes to `stdout` and `stderr` is handled and redirected somewhere by a container engine. For example, the Docker container engine redirects those two streams to [a logging driver](https://docs.docker.com/engine/admin/logging/overview), which is configured in Kubernetes to write to a file in json format.
-
-**Note:** The Docker json logging driver treats each line as a separate message. When using the Docker logging driver, there is no direct support for multi-line messages. You need to handle multi-line messages at the logging agent level or higher.
-
-By default, if a container restarts, the kubelet keeps one terminated container with its logs. If a pod is evicted from the node, all corresponding containers are also evicted, along with their logs.
-
-An important consideration in node-level logging is implementing log rotation, so that logs don't consume all available storage on the node. Kubernetes uses the [`logrotate`](http://www.linuxcommand.org/man_pages/logrotate8.html) tool to implement log rotation.
-
-Kubernetes performs log rotation daily, or if the log file grows beyond 10MB in size. Each rotation belongs to a single container; if the container repeatedly fails or the pod is evicted, all previous rotations for the container are lost. By default, Kubernetes keeps up to five logging rotations per container.
-
-The Kubernetes logging configuration differs depending on the node type. For example, you can find detailed information for GCI in the corresponding [configure helper](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/cluster/gce/gci/configure-helper.sh#L96).
-
-When you run [`kubectl logs`](/docs/user-guide/kubectl/kubectl_logs), as in the basic logging example, the kubelet on the node handles the request and reads directly from the log file, returning the contents in the response. Note that `kubectl logs` **only returns the last rotation**; you must manually extract prior rotations, if desired and cluster-level logging is not enabled.
-
-### System component logs
-
-There are two types of system components: those that run in a container and those
-that do not run in a container. For example:
-
-* The Kubernetes scheduler and kube-proxy run in a container.
-* The kubelet and container runtime, for example Docker, do not run in containers.
-
-On machines with systemd, the kubelet and container runtime write to journald. If
-systemd is not present, they write to `.log` files in the `/var/log` directory.
-System components inside containers always write to the `/var/log` directory,
-bypassing the default logging mechanism. They use the [glog](https://godoc.org/github.com/golang/glog)
-logging library. You can find the conventions for logging severity for those
-components in the [development docs on logging](https://github.com/kubernetes/community/blob/master/contributors/devel/logging.md).
-
-Similarly to the container logs, system component logs in the `/var/log`
-directory are rotated daily and based on the log size. However,
-system component logs have a higher size retention: by default,
-they can store up to 100MB.
-
-## Cluster-level logging architectures
-
-While Kubernetes does not provide a native solution for cluster-level logging, there are several common approaches you can consider. Here are some options:
-
-* Use a node-level logging agent that runs on every node.
-* Include a dedicated sidecar container for logging in an application pod.
-* Push logs directly to a backend from within an application.
-
-### Using a node logging agent
-
-
-
-You can implement cluster-level logging by including a _node-level logging agent_ on each node. The logging agent is a dedicated tool that exposes logs or pushes logs to a backend. Commonly, the logging agent is a container that has access to a directory with log files from all of the application containers on that node.
-
-Because the logging agent must run on every node, it's common to implement it as either a DaemonSet replica, a manifest pod, or a dedicated native process on the node. However the latter two approaches are deprecated and highly discouraged.
-
-Using a node-level logging agent is the most common and encouraged approach for a Kubernetes cluster, because it creates only one agent per node, and it doesn't require any changes to the applications running on the node. However, node-level logging _only works for applications' standard output and standard error_.
-
-Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) for use with Google Cloud Platform, and [Elasticsearch](/docs/user-guide/logging/elasticsearch). You can find more information and instructions in the dedicated documents. Both use [fluentd](http://www.fluentd.org/) with custom configuration as an agent on the node.
-
-### Using a sidecar container with the logging agent
-
-You can use a sidecar container in one of the following ways:
-
-* The sidecar container streams application logs to its own `stdout`.
-* The sidecar container runs a logging agent, which is configured to pick up logs from an application container.
-
-#### Streaming sidecar container
-
-
-
-By having your sidecar containers stream to their own `stdout` and `stderr`
-streams, you can take advantage of the kubelet and the logging agent that
-already run on each node. The sidecar containers read logs from a file, a socket,
-or the journald. Each individual sidecar container prints log to its own `stdout`
-or `stderr` stream.
-
-This approach allows you to separate several log streams from different
-parts of your application, some of which can lack support
-for writing to `stdout` or `stderr`. The logic behind redirecting logs
-is minimal, so it's hardly a significant overhead. Additionally, because
-`stdout` and `stderr` are handled by the kubelet, you can use built-in tools
-like `kubectl logs`.
-
-Consider the following example. A pod runs a single container, and the container
-writes to two different log files, using two different formats. Here's a
-configuration file for the Pod:
-
-{% include code.html language="yaml" file="examples/two-files-counter-pod.yaml" ghlink="/docs/user-guide/logging/examples/two-files-counter-pod.yaml" %}
-
-It would be a mess to have log entries of different formats in the same log
-stream, even if you managed to redirect both components to the `stdout` stream of
-the container. Instead, you could introduce two sidecar containers. Each sidecar
-container could tail a particular log file from a shared volume and then redirect
-the logs to its own `stdout` stream.
-
-Here's a configuration file for a pod that has two sidecar containers:
-
-{% include code.html language="yaml" file="examples/two-files-counter-pod-streaming-sidecar.yaml" ghlink="/docs/user-guide/logging/examples/two-files-counter-pod-streaming-sidecar.yaml" %}
-
-Now when you run this pod, you can access each log stream separately by
-running the following commands:
-
-```shell
-$ kubectl logs counter count-log-1
-0: Mon Jan 1 00:00:00 UTC 2001
-1: Mon Jan 1 00:00:01 UTC 2001
-2: Mon Jan 1 00:00:02 UTC 2001
-...
-```
-
-```shell
-$ kubectl logs counter count-log-2
-Mon Jan 1 00:00:00 UTC 2001 INFO 0
-Mon Jan 1 00:00:01 UTC 2001 INFO 1
-Mon Jan 1 00:00:02 UTC 2001 INFO 2
-...
-```
-
-The node-level agent installed in your cluster picks up those log streams
-automatically without any further configuration. If you like, you can configure
-the agent to parse log lines depending on the source container.
-
-Note, that despite low CPU and memory usage (order of couple of millicores
-for cpu and order of several megabytes for memory), writing logs to a file and
-then streaming them to `stdout` can double disk usage. If you have
-an application that writes to a single file, it's generally better to set
-`/dev/stdout` as destination rather than implementing the streaming sidecar
-container approach.
-
-Sidecar containers can also be used to rotate log files that cannot be
-rotated by the application itself. [An example](https://github.com/samsung-cnct/logrotate)
-of this approach is a small container running logrotate periodically.
-However, it's recommended to use `stdout` and `stderr` directly and leave rotation
-and retention policies to the kubelet.
-
-#### Sidecar container with a logging agent
-
-
-
-If the node-level logging agent is not flexible enough for your situation, you
-can create a sidecar container with a separate logging agent that you have
-configured specifically to run with your application.
-
-**Note**: Using a logging agent in a sidecar container can lead
-to significant resource consumption. Moreover, you won't be able to access
-those logs using `kubectl logs` command, because they are not controlled
-by the kubelet.
-
-As an example, you could use [Stackdriver](/docs/user-guide/logging/stackdriver/),
-which uses fluentd as a logging agent. Here are two configuration files that
-you can use to implement this approach. The first file contains
-a [ConfigMap](/docs/user-guide/configmap/) to configure fluentd.
-
-{% include code.html language="yaml" file="examples/fluentd-sidecar-config.yaml" ghlink="/docs/user-guide/logging/examples/fluentd-sidecar-config.yaml" %}
-
-**Note**: The configuration of fluentd is beyond the scope of this article. For
-information about configuring fluentd, see the
-[official fluentd documentation](http://docs.fluentd.org/).
-
-The second file describes a pod that has a sidecar container running fluentd.
-The pod mounts a volume where fluentd can pick up its configuration data.
-
-{% include code.html language="yaml" file="examples/two-files-counter-pod-agent-sidecar.yaml" ghlink="/docs/user-guide/logging/examples/two-files-counter-pod-agent-sidecar.yaml" %}
-
-After some time you can find log messages in the Stackdriver interface.
-
-Remember, that this is just an example and you can actually replace fluentd
-with any logging agent, reading from any source inside an application
-container.
-
-### Exposing logs directly from the application
-
-
-
-You can implement cluster-level logging by exposing or pushing logs directly from
-every application; however, the implementation for such a logging mechanism
-is outside the scope of Kubernetes.
+[Logging and Monitoring Cluster Activity](/docs/concepts/clusters/logging/)
diff --git a/docs/user-guide/logging/stackdriver.md b/docs/user-guide/logging/stackdriver.md
index b71947ee1f..5664357ee5 100644
--- a/docs/user-guide/logging/stackdriver.md
+++ b/docs/user-guide/logging/stackdriver.md
@@ -5,144 +5,6 @@ assignees:
title: Logging with Stackdriver Logging
---
-Before reading this page, it's highly recommended to familiarize yourself with the [overview of logging in Kubernetes](/docs/user-guide/logging/overview).
+{% include user-guide-content-moved.md %}
-This article assumes that you have created a Kubernetes cluster with cluster-level logging support for sending logs to Stackdriver Logging. You can do this either by selecting the **Enable Stackdriver Logging** checkbox in the create cluster dialogue in [GKE](https://cloud.google.com/container-engine/), or by setting the `KUBE_LOGGING_DESTINATION` flag to `gcp` when manually starting a cluster using `kube-up.sh`.
-
-The following guide describes gathering a container's standard output and standard error. To gather logs written by an application to a file, you can use [a sidecar approach](https://github.com/kubernetes/contrib/blob/master/logging/fluentd-sidecar-gcp/README.md).
-
-## Overview
-
-After creation, you can discover logging agent pods in the `kube-system` namespace,
-one per node, by running the following command:
-
-```shell
-$ kubectl get pods --namespace=kube-system
-NAME READY STATUS RESTARTS AGE
-...
-fluentd-gcp-v1.30-50gnc 1/1 Running 0 5d
-fluentd-gcp-v1.30-v255c 1/1 Running 0 5d
-fluentd-gcp-v1.30-f02l5 1/1 Running 0 5d
-...
-```
-
-To understand how logging with Stackdriver works, consider the following
-synthetic log generator pod specification [counter-pod.yaml](/docs/user-guide/logging/examples/counter-pod.yaml):
-
-{% include code.html language="yaml" file="examples/counter-pod.yaml" ghlink="/docs/user-guide/logging/examples/counter-pod.yaml" %}
-
-This pod specification has one container that runs a bash script
-that writes out the value of a counter and the date once per
-second, and runs indefinitely. Let's create this pod in the default namespace.
-
-```shell
-$ kubectl create -f http://k8s.io/docs/user-guide/logging/examples/counter-pod.yaml
-pod "counter" created
-```
-
-You can observe the running pod:
-
-```shell
-$ kubectl get pods
-NAME READY STATUS RESTARTS AGE
-counter 1/1 Running 0 5m
-```
-
-For a short period of time you can observe the 'Pending' pod status, because the kubelet
-has to download the container image first. When the pod status changes to `Running`
-you can use the `kubectl logs` command to view the output of this counter pod.
-
-```shell
-$ kubectl logs counter
-0: Mon Jan 1 00:00:00 UTC 2001
-1: Mon Jan 1 00:00:01 UTC 2001
-2: Mon Jan 1 00:00:02 UTC 2001
-...
-```
-
-As described in the logging overview, this command fetches log entries
-from the container log file. If the container is killed and then restarted by
-Kubernetes, you can still access logs from the previous container. However,
-if the pod is evicted from the node, log files are lost. Let's demonstrate this
-by deleting the currently running counter container:
-
-```shell
-$ kubectl delete pod counter
-pod "counter" deleted
-```
-
-and then recreating it:
-
-```shell
-$ kubectl create -f http://k8s.io/docs/user-guide/logging/examples/counter-pod.yaml
-pod "counter" created
-```
-
-After some time, you can access logs from the counter pod again:
-
-```shell
-$ kubectl logs counter
-0: Mon Jan 1 00:01:00 UTC 2001
-1: Mon Jan 1 00:01:01 UTC 2001
-2: Mon Jan 1 00:01:02 UTC 2001
-...
-```
-
-As expected, only recent log lines are present. However, for a real-world
-application you will likely want to be able to access logs from all containers,
-especially for the debug purposes. This is exactly when the previously enabled
-Stackdriver Logging can help.
-
-## Viewing logs
-
-Stackdriver Logging agent attaches metadata to each log entry, for you to use later
-in queries to select only the messages you're interested in: for example,
-the messages from a particular pod.
-
-The most important pieces of metadata are the resource type and log name.
-The resource type of a container log is `container`, which is named
-`GKE Containers` in the UI (even if the Kubernetes cluster is not on GKE).
-The log name is the name of the container, so that if you have a pod with
-two containers, named `container_1` and `container_2` in the spec, their logs
-will have log names `container_1` and `container_2` respectively.
-
-System components have resource type `compute`, which is named
-`GCE VM Instance` in the interface. Log names for system components are fixed.
-For a GKE node, every log entry from a system component has one the following
-log names:
-
-* docker
-* kubelet
-* kube-proxy
-
-You can learn more about viewing logs on [the dedicated Stackdriver page](https://cloud.google.com/logging/docs/view/logs_viewer).
-
-One of the possible ways to view logs is using the
-[`gcloud logging`](https://cloud.google.com/logging/docs/api/gcloud-logging)
-command line interface from the [Google Cloud SDK](https://cloud.google.com/sdk/).
-It uses Stackdriver Logging [filtering syntax](https://cloud.google.com/logging/docs/view/advanced_filters)
-to query specific logs. For example, you can run the following command:
-
-```shell
-$ gcloud beta logging read 'logName="projects/$YOUR_PROJECT_ID/logs/count"' --format json | jq '.[].textPayload'
-...
-"2: Mon Jan 1 00:01:02 UTC 2001\n"
-"1: Mon Jan 1 00:01:01 UTC 2001\n"
-"0: Mon Jan 1 00:01:00 UTC 2001\n"
-...
-"2: Mon Jan 1 00:00:02 UTC 2001\n"
-"1: Mon Jan 1 00:00:01 UTC 2001\n"
-"0: Mon Jan 1 00:00:00 UTC 2001\n"
-```
-
-As you can see, it outputs messages for the count container from both
-the first and second runs, despite the fact that the kubelet already deleted
-the logs for the first container.
-
-### Exporting logs
-
-You can export logs to [Google Cloud Storage](https://cloud.google.com/storage/)
-or to [BigQuery](https://cloud.google.com/bigquery/) to run further
-analysis. Stackdriver Logging offers the concept of sinks, where you can
-specify the destination of log entries. More information is available on
-the Stackdriver [Exporting Logs page](https://cloud.google.com/logging/docs/export/configure_export_v2).
+[Logging Using Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)
diff --git a/docs/user-guide/persistent-volumes/walkthrough.md b/docs/user-guide/persistent-volumes/walkthrough.md
deleted file mode 100644
index 2feee3f7d9..0000000000
--- a/docs/user-guide/persistent-volumes/walkthrough.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-assignees:
-- jsafrane
-- saad-ali
-title: Persistent Volumes Walkthrough
----
-
-{% include user-guide-content-moved.md %}
-
-[Configuring a Pod to Use a Persistent Volume for Storage](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)
diff --git a/docs/user-guide/pods/single-container.md b/docs/user-guide/pods/single-container.md
deleted file mode 100644
index fd7a44ba66..0000000000
--- a/docs/user-guide/pods/single-container.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Creating Single-Container Pods
----
-
-{% include user-guide-content-moved.md %}
-
-[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/)
diff --git a/docs/user-guide/production-pods.md b/docs/user-guide/production-pods.md
deleted file mode 100644
index 5ea3a0edd5..0000000000
--- a/docs/user-guide/production-pods.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: Working with Containers in Production
----
-
-{% include user-guide-content-moved.md %}
-
-* [Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/)
-
-* [Distributing Credentials Securely](/docs/tasks/configure-pod-container/distribute-credentials-secure/)
-
-* [Pulling an Image from a Private Registry](/docs/tasks/configure-pod-container/pull-image-private-registry/)
-
-* [Communicating Between Containers Running in the Same Pod](/docs/tasks/configure-pod-container/communicate-containers-same-pod/)
-
-* [Assigning CPU and RAM Resources to a Container](/docs/tasks/configure-pod-container/assign-cpu-ram-container/)
-
-* [Configuring Liveness and Readiness Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)
-
-* [Configuring Pod Initialization](/docs/tasks/configure-pod-container/configure-pod-initialization/)
-
-* [Attaching Handlers to Container Lifecycle Events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
-
-* [Determining the Reason for Pod Failure](/docs/tasks/debug-application-cluster/determine-reason-pod-failure/)
diff --git a/docs/user-guide/quick-start.md b/docs/user-guide/quick-start.md
deleted file mode 100644
index 67dfb1dc77..0000000000
--- a/docs/user-guide/quick-start.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-assignees:
-- bgrant0607
-- janetkuo
-title: Launching, Exposing, and Killing Applications
----
-
-{% include user-guide-content-moved.md %}
-
-[Using a Service to Access an Application in a Cluster](https://kubernetes.io/docs/tutorials/stateless-application/expose-external-ip-address-service/)
diff --git a/docs/user-guide/replicasets.md b/docs/user-guide/replicasets.md
index ea3e7bde14..2b6a767be2 100644
--- a/docs/user-guide/replicasets.md
+++ b/docs/user-guide/replicasets.md
@@ -94,7 +94,7 @@ of the replicated pods.
kubectl create -f hpa-rs.yaml
```
-Alternatively, you can just use the `kubectl autoscale` command to acomplish the same
+Alternatively, you can just use the `kubectl autoscale` command to accomplish the same
(and it's easier!)
```shell
diff --git a/docs/user-guide/secrets/walkthrough.md b/docs/user-guide/secrets/walkthrough.md
deleted file mode 100644
index a58364859f..0000000000
--- a/docs/user-guide/secrets/walkthrough.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Secrets Walkthrough
----
-
-{% include user-guide-content-moved.md %}
-
-[Distributing Credentials Securely](/docs/tasks/configure-pod-container/distribute-credentials-secure/)
diff --git a/docs/admin/ha-master-gce.png b/images/docs/ha-master-gce.png
similarity index 100%
rename from docs/admin/ha-master-gce.png
rename to images/docs/ha-master-gce.png
diff --git a/images/square-logos/asm.png b/images/square-logos/asm.png
new file mode 100644
index 0000000000..6e383ccb99
Binary files /dev/null and b/images/square-logos/asm.png differ
diff --git a/images/square-logos/avinetworks.png b/images/square-logos/avinetworks.png
new file mode 100644
index 0000000000..0910e54ab5
Binary files /dev/null and b/images/square-logos/avinetworks.png differ
diff --git a/images/square-logos/ca.png b/images/square-logos/ca.png
new file mode 100644
index 0000000000..96089e040b
Binary files /dev/null and b/images/square-logos/ca.png differ
diff --git a/images/square-logos/cloudplex.png b/images/square-logos/cloudplex.png
new file mode 100644
index 0000000000..1943b433e8
Binary files /dev/null and b/images/square-logos/cloudplex.png differ
diff --git a/images/square-logos/coscale.png b/images/square-logos/coscale.png
new file mode 100644
index 0000000000..de68cb49f3
Binary files /dev/null and b/images/square-logos/coscale.png differ
diff --git a/images/square-logos/eta.png b/images/square-logos/eta.png
new file mode 100644
index 0000000000..ec9ab9d5cb
Binary files /dev/null and b/images/square-logos/eta.png differ
diff --git a/images/square-logos/infracloud.png b/images/square-logos/infracloud.png
new file mode 100644
index 0000000000..849772332d
Binary files /dev/null and b/images/square-logos/infracloud.png differ
diff --git a/images/square-logos/inwinstack.png b/images/square-logos/inwinstack.png
new file mode 100644
index 0000000000..5a849db4da
Binary files /dev/null and b/images/square-logos/inwinstack.png differ
diff --git a/images/square-logos/kumina.png b/images/square-logos/kumina.png
new file mode 100644
index 0000000000..75f31ca8ef
Binary files /dev/null and b/images/square-logos/kumina.png differ
diff --git a/images/square-logos/nats.png b/images/square-logos/nats.png
new file mode 100644
index 0000000000..4dcb111683
Binary files /dev/null and b/images/square-logos/nats.png differ
diff --git a/images/square-logos/puppet.png b/images/square-logos/puppet.png
index b07f038315..48f1870545 100644
Binary files a/images/square-logos/puppet.png and b/images/square-logos/puppet.png differ
diff --git a/images/square-logos/rxm.png b/images/square-logos/rxm.png
new file mode 100644
index 0000000000..3b48b41071
Binary files /dev/null and b/images/square-logos/rxm.png differ
diff --git a/images/square-logos/semantix.png b/images/square-logos/semantix.png
new file mode 100644
index 0000000000..0915a8040a
Binary files /dev/null and b/images/square-logos/semantix.png differ
diff --git a/images/square-logos/signalfx.png b/images/square-logos/signalfx.png
new file mode 100644
index 0000000000..590a59904f
Binary files /dev/null and b/images/square-logos/signalfx.png differ
diff --git a/images/square-logos/spotinst.png b/images/square-logos/spotinst.png
new file mode 100644
index 0000000000..645abbed45
Binary files /dev/null and b/images/square-logos/spotinst.png differ
diff --git a/images/square-logos/supergiant.png b/images/square-logos/supergiant.png
new file mode 100644
index 0000000000..0ead81d2c6
Binary files /dev/null and b/images/square-logos/supergiant.png differ
diff --git a/robots.txt b/robots.txt
index 10fff656d2..3fbd70eb24 100644
--- a/robots.txt
+++ b/robots.txt
@@ -5,6 +5,25 @@ Disallow: /v1.0/
Disallow: /v1.1/
Disallow: /404/
Disallow: 404.html
-Disallow: /docs/user-guide/docs/user-guide/simple-nginx/
+
+Disallow: /docs/user-guide/configuring-containers
+Disallow: /docs/user-guide/containers
+Disallow: /docs/user-guide/deploying-applications
+Disallow: /docs/user-guide/liveness/index
+Disallow: /docs/user-guide/simple-nginx
+Disallow: /docs/user-guide/production-pods
+Disallow: /docs/user-guide/quick-start
+
+Disallow: /docs/user-guide/persistent-volumes/walkthrough
+Disallow: /docs/user-guide/pods/single-container
+
+Disallow: /docs/user-guide/secrets/walkthrough
SITEMAP: http://kubernetes.io/sitemap.xml
+
+
+
+
+
+
+