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

* 'master' of https://github.com/kubernetes/kubernetes.github.io:
  ZTE-SH-CN-debug-pod-replication-controller-2017-09-14-14
  ZTE-SH-CN-define-command-argument-container (#5381)
  Update index.md
  Update Kompose docs
  Improve host aliases page (#5443)
  Add link to AlwaysPullImages admission controller
  Revert "create homepage for user journeys"
  create homepage for user journeys
  fix the command output
  ZTE-SH-CN-run-application-run-single-instance-stateful-application-pr-2017-… (#5363)
  Add a note to static pod manifest scanning
  revert WordPress and MySQL PV doc changes to use apps/v1beta2 APIs (#5461)
  Fix pod probes yaml file
  Redirect v1 docs. (#5460)
  Fix error link (#5459)
  Fix typo in deployment documentation

# Conflicts:
#	docs/tutorials/stateful-application/basic-stateful-set.md

docs/concepts/containers/images.md

@@ -19,10 +19,13 @@ The `image` property of a container supports the same syntax as the `docker` com
 
 ## Updating Images
 
-The default pull policy is `IfNotPresent` which causes the Kubelet to not
-pull an image if it already exists. If you would like to always force a pull
-you must set a pull image policy of `Always` or specify a `:latest` tag on
-your image.
+The default pull policy is `IfNotPresent` which causes the Kubelet to skip
+pulling an image if it already exists. If you would like to always force a pull,
+you can do one of the following:
+
+- set the `imagePullPolicy` of the container to `Always`;
+- use `:latest` as the tag for the image to use;
+- enable the [AllwaysPullImages](/docs/admin/admission-controllers/#alwayspullimages) admission controller.
 
 If you did not specify tag of your image, it will be assumed as `:latest`, with
 pull image policy of `Always` correspondingly.

docs/concepts/overview/components.md

@@ -27,7 +27,7 @@ Kubernetes control plane. It is designed to scale horizontally -- that is, it sc
 
 ### etcd
 
-[etcd](/docs/admin/etcd) is used as Kubernetes' backing store. All cluster data is stored here. Always have a backup plan for etcd's data for your Kubernetes cluster.
+[etcd](/docs/tasks/administer-cluster/configure-upgrade-etcd) is used as Kubernetes' backing store. All cluster data is stored here. Always have a backup plan for etcd's data for your Kubernetes cluster.
 
 ### kube-controller-manager
 
@@ -84,12 +84,12 @@ Containers started by Kubernetes automatically include this DNS server in their
 
 #### Container Resource Monitoring
 
-[Container Resource Monitoring](/docs/user-guide/monitoring) records generic time-series metrics
+[Container Resource Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring) records generic time-series metrics
 about containers in a central database, and provides a UI for browsing that data.
 
 #### Cluster-level Logging
 
-A [Cluster-level logging](/docs/user-guide/logging/overview) mechanism is responsible for
+A [Cluster-level logging](/docs/concepts/cluster-administration/logging) mechanism is responsible for
 saving container logs to a central log store with search/browsing interface.
 
 ## Node components

docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md

@@ -15,14 +15,19 @@ Modification not using HostAliases is not suggested because the file is managed
 ## Default Hosts File Content
 
 Lets start an Nginx Pod which is assigned an Pod IP:
-```
+
+```shell
+$ kubectl run nginx --image nginx --generator=run-pod/v1
+pod "nginx" created
+
 $ kubectl get pods --output=wide
 NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
 nginx    1/1       Running   0          13s    10.200.0.4   worker0
 ```
 
 The hosts file content would look like this:
-```
+
+```shell
 $ kubectl exec nginx -- cat /etc/hosts
 # Kubernetes-managed hosts file.
 127.0.0.1	localhost
@@ -42,8 +47,20 @@ In addition to the default boilerplate, we can add additional entries to the hos
 
 {% include code.html language="yaml" file="hostaliases-pod.yaml" ghlink="/docs/concepts/services-networking/hostaliases-pod.yaml" %}
 
-The hosts file content would look like this:
+This Pod can be started with the following commands:
+
+```shell
+$ kubectl apply -f hostaliases-pod.yaml
+pod "hostaliases-pod" created
+
+$ kubectl get pod -a -o=wide
+NAME                           READY     STATUS      RESTARTS   AGE       IP              NODE
+hostaliases-pod                0/1       Completed   0          6s        10.244.135.10   node3
 ```
+
+The hosts file content would look like this:
+
+```shell
 $ kubectl logs hostaliases-pod
 # Kubernetes-managed hosts file.
 127.0.0.1	localhost
@@ -52,7 +69,7 @@ fe00::0	ip6-localnet
 fe00::0	ip6-mcastprefix
 fe00::1	ip6-allnodes
 fe00::2	ip6-allrouters
-10.200.0.4	hostaliases-pod
+10.244.135.10	hostaliases-pod
 127.0.0.1	foo.local
 127.0.0.1	bar.local
 10.1.2.3	foo.remote

docs/concepts/services-networking/hostaliases-pod.yaml

@@ -3,6 +3,7 @@ kind: Pod
 metadata:
   name: hostaliases-pod
 spec:
+  restartPolicy: Never
   hostAliases:
   - ip: "127.0.0.1"
     hostnames:

docs/concepts/workloads/controllers/deployment.md

@@ -115,7 +115,7 @@ NAME                          DESIRED   CURRENT   READY   AGE
 nginx-deployment-2035384211   3         3         3       18s
 ```
 
-Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[POD-TEMPLATE-HASH-VALUE]`. The hash value is automatically generated when the Deployemnt is created.
+Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[POD-TEMPLATE-HASH-VALUE]`. The hash value is automatically generated when the Deployment is created.
 
 To see the labels automatically generated for each pod, run `kubectl get pods --show-labels`. The following output is returned: