Merge branch 'master' into foxish-fix-annotation

docs/getting-started-guides/kubeadm.md

@@ -254,3 +254,9 @@ Please note: `kubeadm` is a work in progress and these limitations will be addre
 1. There is not yet an easy way to generate a `kubeconfig` file which can be used to authenticate to the cluster remotely with `kubectl` on, for example, your workstation.
 
    Workaround: copy the kubelet's `kubeconfig` from the master: use `scp root@<master>:/etc/kubernetes/admin.conf .` and then e.g. `kubectl --kubeconfig ./admin.conf get nodes` from your workstation.
+
+1. If you are using VirtualBox (directly or via Vagrant), you will need to ensure that `hostname -i` returns a routable IP address (i.e. one on the second network interface, not the first one).
+   By default, it doesn't do this and kubelet ends-up using first non-loopback network interface, which is usually NATed.
+   Workaround: Modify `/etc/hosts`, take a look at this [`Vagrantfile`][ubuntu-vagrantfile] for how you this can be achieved.
+
+[ubuntu-vagrantfile]: https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11),

docs/tutorials/stateless-application/deployment-scale.yaml

@@ -0,0 +1,16 @@
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+spec:
+  replicas: 4
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.8 # Update the version of nginx from 1.7.9 to 1.8
+        ports:
+        - containerPort: 80

docs/tutorials/stateless-application/run-stateless-application-deployment.md

@@ -94,6 +94,30 @@ specifies that the deployment should be updated to use nginx 1.8.
 
         kubectl get pods -l app=nginx
 
+### Scaling the application by increasing the replica count
+
+You can increase the number of pods in your Deployment by applying a new YAML
+file. This YAML file sets `replicas` to 4, which specifies that the Deployment
+should have four pods:
+
+{% include code.html language="yaml" file="deployment-scale.yaml" ghlink="/docs/tutorials/stateless-application/deployment-scale.yaml" %}
+
+1. Apply the new YAML file:
+
+        kubectl apply -f $REPO/docs/tutorials/stateless-application/deployment-scale.yaml
+
+1. Verify that the Deployment has four pods:
+
+        kubectl get pods
+
+    The output is similar to this:
+
+        NAME                               READY     STATUS    RESTARTS   AGE
+        nginx-deployment-148880595-4zdqq   1/1       Running   0          25s
+        nginx-deployment-148880595-6zgi1   1/1       Running   0          25s
+        nginx-deployment-148880595-fxcez   1/1       Running   0          2m
+        nginx-deployment-148880595-rwovn   1/1       Running   0          2m
+
 ### Deleting a deployment
 
 Delete the deployment by name:

docs/user-guide/petset/bootstrapping/index.md

@@ -8,7 +8,7 @@
 
 This purpose of this guide is to help you become familiar with the runtime initialization of [Pet Sets](/docs/user-guide/petset). This guide assumes the same prerequisites, and uses the same terminology as the [Pet Set user document](/docs/user-guide/petset).
 
-The most common way to initialize the runtime in a containerized environment, is through a custom [entrypoint](https://docs.docker.com/engine/reference/builder/#entrypoint). While this is not necessarily bad, making your application pid 1, and treating containers as processes in general is good for a few reasons outside the scope of this document. Doing so allows you to run docker images from third-party vendors without modification. We will not be writing custom entrypoints for this example, but using a feature called [init containers](http://releases.k8s.io/{{page.githubbranch}}/docs/proposals/container-init.md), to explain 2 common patterns that come up deploying Pet Sets.
+The most common way to initialize the runtime in a containerized environment, is through a custom [entrypoint](https://docs.docker.com/engine/reference/builder/#entrypoint). While this is not necessarily bad, making your application pid 1, and treating containers as processes in general is good for a few reasons outside the scope of this document. Doing so allows you to run docker images from third-party vendors without modification. We will not be writing custom entrypoints for this example, but using a feature called [init containers](http://kubernetes.io/docs/user-guide/production-pods/#handling-initialization), to explain 2 common patterns that come up deploying Pet Sets.
 
 1. Transferring state across Pet restart, so that a future Pet is initialized with the computations of its past incarnation
 2. Initializing the runtime environment of a Pet based on existing conditions, like a list of currently healthy peers