Merge branch 'master' into patch-1

docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml

@@ -1,14 +1,13 @@
-apiVersion: extensions/v1beta1
+apiVersion: autoscaling/v1
 kind: HorizontalPodAutoscaler
 metadata:
   name: php-apache
   namespace: default
 spec:
-  scaleRef:
+  scaleTargetRef:
+    apiVersion: extensions/v1beta1
     kind: Deployment
     name: php-apache
-    subresource: scale
   minReplicas: 1
   maxReplicas: 10
-  cpuUtilization:
-    targetPercentage: 50
+  targetCPUUtilizationPercentage: 50

docs/user-guide/horizontal-pod-autoscaling/walkthrough.md

@@ -127,20 +127,19 @@ Here CPU utilization dropped to 0, and so HPA autoscaled the number of replicas
 Instead of using `kubectl autoscale` command we can use the [hpa-php-apache.yaml](/docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml) file, which looks like this:
 
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: autoscaling/v1
 kind: HorizontalPodAutoscaler
 metadata:
   name: php-apache
   namespace: default
 spec:
-  scaleRef:
+  scaleTargetRef:
+    apiVersion: extensions/v1beta1
     kind: Deployment
     name: php-apache
-    subresource: scale
   minReplicas: 1
   maxReplicas: 10
-  cpuUtilization:
-    targetPercentage: 50
+  targetCPUUtilizationPercentage: 50
 ```
 
 We will create the autoscaler by executing the following command:

docs/user-guide/jobs/work-queue-1/index.md

@@ -166,7 +166,7 @@ We will use the `amqp-consume` utility to read the message
 from the queue and run our actual program.  Here is a very simple
 example program:
 
-{% include code.html language="python" file="worker.py" ghlink="/docs/user-guide/job/work-queue-1/worker.py" %}
+{% include code.html language="python" file="worker.py" ghlink="/docs/user-guide/jobs/work-queue-1/worker.py" %}
 
 Now, build an image.  If you are working in the source
 tree, then change directory to `examples/job/work-queue-1`.
@@ -204,7 +204,7 @@ Here is a job definition.  You'll need to make a copy of the Job and edit the
 image to match the name you used, and call it `./job.yaml`.
 
 
-{% include code.html language="yaml" file="job.yaml" ghlink="/docs/user-guide/job/work-queue-1/job.yaml" %}
+{% include code.html language="yaml" file="job.yaml" ghlink="/docs/user-guide/jobs/work-queue-1/job.yaml" %}
 
 In this example, each pod works on one item from the queue and then exits.
 So, the completion count of the Job corresponds to the number of work items
@@ -258,12 +258,12 @@ want to consider one of the other [job patterns](/docs/user-guide/jobs/#job-patt
 
 This approach creates a pod for every work item.  If your work items only take a few seconds,
 though, creating a Pod for every work item may add a lot of overhead.  Consider another
-[example](/docs/user-guide/job/work-queue-2), that executes multiple work items per Pod.
+[example](/docs/user-guide/jobs/work-queue-2/), that executes multiple work items per Pod.
 
 In this example, we used use the `amqp-consume` utility to read the message
 from the queue and run our actual program.  This has the advantage that you
 do not need to modify your program to be aware of the queue.
-A [different example](/docs/user-guide/job/work-queue-2), shows how to
+A [different example](/docs/user-guide/jobs/work-queue-2/), shows how to
 communicate with the work queue using a client library.
 
 ## Caveats

docs/user-guide/jobs/work-queue-2/index.md

@@ -108,7 +108,7 @@ called rediswq.py ([Download](rediswq.py?raw=true)).
 The "worker" program in each Pod of the Job uses the work queue
 client library to get work.  Here it is:
 
-{% include code.html language="python" file="worker.py" ghlink="/docs/user-guide/job/work-queue-2/worker.py" %}
+{% include code.html language="python" file="worker.py" ghlink="/docs/user-guide/jobs/work-queue-2/worker.py" %}
 
 If you are working from the source tree,
 change directory to the `examples/job/work-queue-2` directory.
@@ -147,7 +147,7 @@ gcloud docker push gcr.io/<project>/job-wq-2
 
 Here is the job definition:
 
-{% include code.html language="yaml" file="job.yaml" ghlink="/docs/user-guide/job/work-queue-2/job.yaml" %}
+{% include code.html language="yaml" file="job.yaml" ghlink="/docs/user-guide/jobs/work-queue-2/job.yaml" %}
 
 Be sure to edit the job template to
 change `gcr.io/myproject` to your own path.

docs/user-guide/kubectl/kubectl_get.md

@@ -12,6 +12,7 @@ Display one or many resources
 Display one or many resources.
 
 Valid resource types include:
+
    * clusters (valid only for federation apiservers)
    * componentstatuses (aka 'cs')
    * configmaps (aka 'cm')
@@ -68,7 +69,9 @@ kubectl get -o json pod web-pod-13je7
 kubectl get -f pod.yaml -o json
 
 # Return only the phase value of the specified pod.
+{% raw %}
 kubectl get -o template pod/web-pod-13je7 --template={{.status.phase}}
+{% endraw %}
 
 # List all replication controllers and services together in ps output format.
 kubectl get rc,services

docs/user-guide/networkpolicies.md

@@ -44,9 +44,11 @@ metadata:
 
 To configure the annotation via `kubectl`:
 
-```shell{% raw %}
+```shell
+{% raw %}
 kubectl annotate ns <namespace> "net.beta.kubernetes.io/network-policy={\"ingress\": {\"isolation\": \"DefaultDeny\"}}"
-{% endraw %}```
+{% endraw %}
+```
 
 See the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) for an example.
 

docs/user-guide/petset.md

@@ -17,7 +17,7 @@ Throughout this doc you will see a few terms that are sometimes used interchange
 * Persistent Volume Claim (PVC): A request for storage, typically a [persistent volume](/docs/user-guide/persistent-volumes/walkthrough/).
 * Host name: The hostname attached to the UTS namespace of the pod, i.e the output of `hostname` in the pod.
 * DNS/Domain name: A *cluster local* domain name resolvable using standard methods (eg: [gethostbyname](http://linux.die.net/man/3/gethostbyname)).
-* Ordinality: the proprety of being "ordinal", or occupying a position in a sequence.
+* Ordinality: the property of being "ordinal", or occupying a position in a sequence.
 * Pet: a single member of a PetSet; more generally, a stateful application.
 * Peer: a process running a server, capable of communicating with other such processes.
 
@@ -29,7 +29,7 @@ This doc assumes familiarity with the following Kubernetes concepts:
 * [Cluster DNS](/docs/admin/dns/)
 * [Headless Services](/docs/user-guide/services/#headless-services)
 * [Persistent Volumes](/docs/user-guide/volumes/)
-* [Dynamic volume provisioning](http://releases.k8s.io/{{page.githubbranch}}/examples/experimental/persistent-volume-provisioning/README.md)
+* [Persistent Volume Provisioning](http://releases.k8s.io/{{page.githubbranch}}/examples/experimental/persistent-volume-provisioning/README.md)
 
 You need a working Kubernetes cluster at version >= 1.3, with a healthy DNS [cluster addon](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/README.md) at version >= 15. You cannot use PetSet on a hosted Kubernetes provider that has disabled `alpha` resources.
 
@@ -85,7 +85,7 @@ Before you start deploying applications as PetSets, there are a few limitations
 * PetSet is an *alpha* resource, not available in any Kubernetes release prior to 1.3.
 * As with all alpha/beta resources, it can be disabled through the `--runtime-config` option passed to the apiserver, and in fact most likely will be disabled on hosted offerings of Kubernetes.
 * The only updatable field on a PetSet is `replicas`
-* The storage for a given pet must either be provisioned by a [dynamic storage provisioner](http://releases.k8s.io/{{page.githubbranch}}/examples/experimental/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin. Note that dynamic volume provisioning is also currently in alpha.
+* The storage for a given pet must either be provisioned by a [persistent volume provisioner](http://releases.k8s.io/{{page.githubbranch}}/examples/experimental/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin. Note that persistent volume provisioning is also currently in alpha.
 * Deleting and/or scaling a PetSet down will *not* delete the volumes associated with the PetSet. This is done to ensure safety first, your data is more valuable than an auto purge of all related PetSet resources. **Deleting the Persistent Volume Claims will result in a deletion of the associated volumes**.
 * All PetSets currently require a "governing service", or a Service responsible for the network identity of the pets. The user is responsible for this Service.
 * Updating an existing PetSet is currently a manual process, meaning you either need to deploy a new PetSet with the new image version, or orphan Pets one by one, update their image, and join them back to the cluster.
@@ -392,7 +392,8 @@ $ grace=$(kubectl get po web-0 --template '{{.spec.terminationGracePeriodSeconds
 $ kubectl delete petset,po -l app=nginx
 $ sleep $grace
 $ kubectl delete pvc -l app=nginx
-{% endraw %}```
+{% endraw %}
+```
 
 ## Troubleshooting
 

docs/user-guide/production-pods.md

@@ -226,7 +226,8 @@ Here is a toy example:
 
 The message is recorded along with the other state of the last (i.e., most recent) termination:
 
-```shell{% raw %}
+```shell
+{% raw %}
 $ kubectl create -f ./pod-w-message.yaml
 pod "pod-w-message" created
 $ sleep 70
@@ -234,7 +235,8 @@ $ kubectl get pods/pod-w-message -o go-template="{{range .status.containerStatus
 Sleep expired
 $ kubectl get pods/pod-w-message -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.exitCode}}{{end}}"
 0
-{% endraw %}```
+{% endraw %}
+```
 
 ## What's next?
 

docs/user-guide/volumes.md

@@ -108,6 +108,25 @@ While tmpfs is very fast, be aware that unlike disks, tmpfs is cleared on
 machine reboot and any files you write will count against your container's
 memory limit.
 
+#### Example pod
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: test-pd
+spec:
+  containers:
+  - image: gcr.io/google_containers/test-webserver
+    name: test-container
+    volumeMounts:
+    - mountPath: /cache
+      name: cache-volume
+  volumes:
+  - name: cache-volume
+    emptyDir: {}
+```
+
 ### hostPath
 
 A `hostPath` volume mounts a file or directory from the host node's filesystem

docs/user-guide/walkthrough/index.md

@@ -59,12 +59,14 @@ On most providers, the pod IPs are not externally accessible. The easiest way to
 
 Provided the pod IP is accessible, you should be able to access its http endpoint with wget on port 80:
 
-```shell{% raw %}
+```shell
+{% raw %}
 $ kubectl run busybox --image=busybox --restart=Never --tty -i --generator=run-pod/v1 --env "POD_IP=$(kubectl get pod nginx -o go-template='{{.status.podIP}}')"
 u@busybox$ wget -qO- http://$POD_IP # Run in the busybox container
 u@busybox$ exit # Exit the busybox container
 $ kubectl delete pod busybox # Clean up the pod we created with "kubectl run"
-{% endraw %}```
+{% endraw %}
+```
 
 Delete the pod by name:
 

docs/user-guide/walkthrough/k8s201.md

@@ -136,7 +136,8 @@ On most providers, the service IPs are not externally accessible. The easiest wa
 
 Provided the service IP is accessible, you should be able to access its http endpoint with wget on the exposed port:
 
-```shell{% raw %}
+```shell
+{% raw %}
 $ export SERVICE_IP=$(kubectl get service nginx-service -o go-template='{{.spec.clusterIP}}')
 $ export SERVICE_PORT=$(kubectl get service nginx-service -o go-template='{{(index .spec.ports 0).port}}')
 $ echo "$SERVICE_IP:$SERVICE_PORT"
@@ -144,7 +145,8 @@ $ kubectl run busybox  --generator=run-pod/v1 --image=busybox --restart=Never --
 u@busybox$ wget -qO- http://$SERVICE_IP:$SERVICE_PORT # Run in the busybox container
 u@busybox$ exit # Exit the busybox container
 $ kubectl delete pod busybox # Clean up the pod we created with "kubectl run"
-{% endraw %}```
+{% endraw %}
+```
 
 To delete the service by name: