First draft of deployment-oriented sections of the user guide.

Author: bgrant0607

docs/user-guide/configuring-containers.md

@@ -0,0 +1,135 @@
+# Kubernetes User Guide: Managing Applications: Configuring and launching containers
+
+## Configuration in Kubernetes
+
+In addition to the imperative-style commands, such as `kubectl run` and `kubectl expose`, described [elsewhere](quick-start.md), Kubernetes supports declarative configuration. Often times, configuration files are preferable to imperative commands, since they can be checked into version control and changes to the files can be code reviewed, which is especially important for more complex configurations, producing a more robust, reliable and archival system.
+
+In the declarative style, all configuration is stored in YAML or JSON configuration files, using Kubernetes's API resource schemas as the configuration schemas. `kubectl` can create, update, delete, and get API resources. The `apiVersion` (currently “v1”), resource `kind`, and resource `name` are used by `kubectl` to construct the appropriate API path to invoke for the specified operation. 
+
+## Launching a container using a configuration file
+
+Kubernetes executes containers in [*Pods*](../../docs/pods.md). A pod containing a simple Hello World container can be specified in YAML as follows:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: hello-world
+spec:  # specification of the pod’s contents
+  restartPolicy: Never
+  containers:
+  - name: hello
+    image: "ubuntu:14.04"
+    command: ["/bin/echo","hello”,”world"]
+```
+The value of `metadata.name`, `hello-world`, will be the name of the pod resource created, and must be unique within the cluster, whereas `containers[0].name` is just a nickname for the container within that pod. `image` is the name of the Docker image, which Kubernetes expects to be able to pull from a registry, the [Docker Hub](https://registry.hub.docker.com/) by default.
+
+`restartPolicy: Never` indicates that we just want to run the container once and then terminate the pod. 
+
+The [`command`](../../docs/containers.md#containers-and-commands) overrides the Docker container’s `Entrypoint`. Command arguments (corresponding to Docker’s `Cmd`) may be specified using `args`, as follows:
+
+```yaml
+    command: ["/bin/echo"]
+    args: ["hello","world"]
+```
+
+This pod can be created using the `create` command:
+```bash
+$ kubectl create -f hello-world.yaml
+pods/hello-world
+```
+`kubectl` prints the resource type and name of the resource created when successful.
+
+## Validating configuration
+
+If you’re not sure you specified the resource correctly, you can ask `kubectl` to validate it for you:
+```bash
+$ kubectl create -f hello-world.yaml --validate
+```
+
+Let’s say you specified `entrypoint` instead of `command`. You’d see output as follows:
+```
+I0709 06:33:05.600829   14160 schema.go:126] unknown field: entrypoint
+I0709 06:33:05.600988   14160 schema.go:129] this may be a false alarm, see https://github.com/GoogleCloudPlatform/kubernetes/issues/6842
+pods/hello-world
+```
+`kubectl create --validate` currently warns about problems it detects, but creates the resource anyway, unless a required field is absent or a field value is invalid. Unknown API fields are ignored, so be careful. This pod was created, but with no `command`, which is an optional field, since the image may specify an `Entrypoint`.
+
+## Environment variables and variable expansion
+
+Kubernetes [does not automatically run commands in a shell](https://github.com/GoogleCloudPlatform/kubernetes/wiki/User-FAQ#use-of-environment-variables-on-the-command-line) (not all images contain shells). If you would like to run your command in a shell, such as to expand environment variables (specified using `env`), you could do the following:
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: hello-world
+spec:  # specification of the pod’s contents
+  restartPolicy: Never
+  containers:
+  - name: hello
+    image: "ubuntu:14.04"
+    env:
+    - name: MESSAGE
+      value: "hello world"
+    command: ["/bin/sh","-c"]
+    args: ["/bin/echo \"${MESSAGE}\""]
+```
+
+However, a shell isn’t necessary just to expand environment variables. Kubernetes will do it for you if you use [`$(ENVVAR)` syntax](../../docs/design/expansion.md):
+```yaml
+    command: ["/bin/echo"]
+    args: ["$(MESSAGE)"]
+```
+## Viewing pod status
+
+You can see the pod you created (actually all of your cluster's pods) using the `get` command. 
+
+If you’re quick, it will look as follows:
+```bash
+$ kubectl get pods
+NAME          READY     STATUS    RESTARTS   AGE
+hello-world   0/1       Pending   0          0s
+```
+Initially, a newly created pod is unscheduled -- no node has been selected to run it. Scheduling happens after creation, but is fast, so you normally shouldn’t see pods in an unscheduled state unless there’s a problem.
+
+After the pod has been scheduled, the image may need to be pulled to the node on which it was scheduled, if it hadn’t be pulled already. After a few seconds, you should see the container running:
+```bash
+$ kubectl get pods
+NAME          READY     STATUS    RESTARTS   AGE
+hello-world   1/1       Running   0          5s
+```
+The `READY` column shows how many containers in the pod are running.
+
+Almost immediately after it starts running, this command will terminate. `kubectl` shows that the container is no longer running and displays the exit status:
+```bash
+$ kubectl get pods
+NAME          READY     STATUS       RESTARTS   AGE
+hello-world   0/1       ExitCode:0   0          15s
+```
+## Viewing pod output
+
+You probably want to see the output of the command you ran. As with [`docker logs`](https://docs.docker.com/userguide/usingdocker/), `kubectl logs` will show you the output:
+```bash
+$ kubectl logs hello-world
+hello world
+```
+## Deleting pods
+When you’re done looking at the output, you should delete the pod:
+```bash
+$ kubectl delete pod hello-world
+pods/hello-world
+```
+As with `create`, `kubectl` prints the resource type and name of the resource deleted when successful.
+
+You can also use the resource/name format to specify the pod:
+```bash
+$ kubectl delete pods/hello-world
+pods/hello-world
+```
+
+Terminated pods aren’t currently automatically deleted, so that you can observe their final status, so be sure to clean up your dead pods. 
+
+On the other hand, containers and their logs are eventually deleted automatically in order to free up disk space on the nodes.
+
+
+[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/user-guide/configuring-containers.md?pixel)]()

docs/user-guide/deploying-applications.md

@@ -0,0 +1,95 @@
+# Kubernetes User Guide: Managing Applications: Deploying continuously running applications
+
+You previously read about how to quickly deploy a simple replicated application using [`kubectl run`](quick-start.md) and how to configure and launch single-run containers using pods (configuring-containers.md). Here, you’ll use the configuration-based approach to deploy a continuously running, replicated application.
+
+## Launching a set of replicas using a configuration file
+
+Kubernetes creates and manages sets of replicated containers (actually, replicated [Pods](../../docs/pods.md)) using [*Replication Controllers*](../../docs/replication-controller.md). 
+
+A replication controller simply ensures that a specified number of pod "replicas" are running at any one time. If there are too many, it will kill some. If there are too few, it will start more. It’s analogous to Google Compute Engine’s [Instance Group Manager](https://cloud.google.com/compute/docs/instance-groups/manager/) or AWS’s [Auto-scaling Group](http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/AutoScalingGroup.html) (with no scaling policies).
+
+The replication controller created to run nginx by `kubctl run` in the [Quick start](quick-start.md) could be specified using YAML as follows:
+```yaml
+apiVersion: v1
+kind: ReplicationController
+metadata:
+  name: my-nginx
+spec:
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx
+        ports:
+        - containerPort: 80
+```
+Some differences compared to specifying just a pod are that the `kind` is `ReplicationController`, the number of `replicas` desired is specified, and the pod specification is under the `template` field. The names of the pods don’t need to be specified explicitly because they are generated from the name of the replication controller.
+
+This replication controller can be created using `create`, just as with pods:
+```bash
+$ kubectl create -f nginx-rc.yaml
+replicationcontrollers/my-nginx
+```
+
+Unlike in the case where you directly create pods, a replication controller replaces pods that are deleted or terminated for any reason, such as in the case of node failure. For this reason, we recommend that you use a replication controller for a continuously running application even if your application requires only a single pod, in which case you can omit `replicas` and it will default to a single replica. 
+
+## Viewing replication controller status
+
+You can view the replication controller you created using `get`:
+```bash
+$ kubectl get rc
+CONTROLLER   CONTAINER(S)   IMAGE(S)   SELECTOR    REPLICAS
+my-nginx     nginx          nginx      app=nginx   2
+```
+This tells you that your controller will ensure that you have two nginx replicas.
+
+You can see those replicas using `get`, just as with pods you created directly:
+```bash
+$ kubectl get pods
+NAME             READY     STATUS    RESTARTS   AGE
+my-nginx-065jq   1/1       Running   0          51s
+my-nginx-buaiq   1/1       Running   0          51s
+```
+## Deleting replication controllers
+
+When you want to kill your application, delete your replication controller, as in the [Quick start](quick-start.md):
+```bash
+$ kubectl delete rc my-nginx
+replicationcontrollers/my-nginx
+```
+
+By default, this will also cause the pods managed by the replication controller to be deleted. If there were a large number of pods, this may take a while to complete. If you want to leave the pods running, specify `--cascade=false`.
+
+If you try to delete the pods before deleting the replication controller, it will just replace them, as it is supposed to do.
+
+## Labels
+
+Kubernetes uses user-defined key-value attributes called [*labels*](../../docs/labels.md) to categorize and identify sets of resources, such as pods and replication controllers. The example above specified a single label in the pod template, with key `app` and value `nginx`. All pods created carry that label, which can be viewed using `-L`:
+```bash
+$ kubectl get pods -L app
+NAME             READY     STATUS    RESTARTS   AGE       APP
+my-nginx-afv12   0/1       Running   0          3s        nginx
+my-nginx-lg99z   0/1       Running   0          3s        nginx
+```
+
+The labels from the pod template are copied to the replication controller’s labels by default, as well -- all resources in Kubernetes support labels:
+```bash
+$ kubectl get rc my-nginx -L app
+CONTROLLER   CONTAINER(S)   IMAGE(S)   SELECTOR    REPLICAS   APP
+my-nginx     nginx          nginx      app=nginx   2          nginx
+```
+
+More importantly, the pod template’s labels are used to create a [`selector`](../../docs/labels.md#label-selectors) that will match pods carrying those labels. You can see this field by requesting it using the [Go template output format of `kubectl get`](../../docs/kubectl_get.md):
+```bash
+$ kubectl get rc my-nginx -o template --template="{{.spec.selector}}"
+map[app:nginx]
+```
+
+You could also specify the `selector` explicitly, such as if you wanted to specify labels in the pod template that you didn’t want to select on, but you should ensure that the selector will match the labels of the pods created from the pod template, and that it won’t match pods created by other replication controllers. The most straightforward way to ensure the latter is to create a unique label value for the replication controller, and to specify it in both the pod template’s labels and in the selector.
+
+
+[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/user-guide/deploying-applications.md?pixel)]()