Merge branch 'master' into redirect-production-pods

steveperry-53 · web-flow · commit 775b9d0681fb · 2017-01-17T16:11:37.000-08:00
diff --git a/.travis.yml b/.travis.yml
@@ -1,6 +1,6 @@
 language: go
 go:
-  - 1.6.2
+  - 1.7.3
 
 # Don't want default ./... here:
 install:
diff --git a/_data/tasks.yml b/_data/tasks.yml
@@ -13,7 +13,8 @@ toc:
   - docs/tasks/configure-pod-container/pull-image-private-registry.md
   - docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md
   - docs/tasks/configure-pod-container/communicate-containers-same-pod.md
-  - docs/tasks/configure-pod-container/configure-pod-initialization.md 
+  - docs/tasks/configure-pod-container/configure-pod-initialization.md
+  - docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
 
 - title: Accessing Applications in a Cluster
   section:
diff --git a/docs/admin/salt.md b/docs/admin/salt.md
@@ -6,7 +6,7 @@ title: Configuring Kubernetes with Salt
 
 The Kubernetes cluster can be configured using Salt.
 
-The Salt scripts are shared across multiple hosting providers, so it's important to understand some background information prior to making a modification to ensure your changes do not break hosting Kubernetes across multiple environments.  Depending on where you host your Kubernetes cluster, you may be using different operating systems and different networking configurations.  As a result, it's important to understand some background information before making Salt changes in order to minimize introducing failures for other hosting providers.
+The Salt scripts are shared across multiple hosting providers and depending on where you host your Kubernetes cluster, you may be using different operating systems and different networking configurations. As a result, it's important to understand some background information before making Salt changes in order to minimize introducing failures for other hosting providers.
 
 ## Salt cluster setup
 
diff --git a/docs/getting-started-guides/minikube.md b/docs/getting-started-guides/minikube.md
@@ -225,7 +225,7 @@ Any services of type `NodePort` can be accessed over that IP address, on the Nod
 
 To determine the NodePort for your service, you can use a `kubectl` command like this:
 
-`kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].NodePort}"'`
+`kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'`
 
 ## Persistent Volumes
 Minikube supports [PersistentVolumes](http://kubernetes.io/docs/user-guide/persistent-volumes/) of type `hostPath`.
diff --git a/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
@@ -0,0 +1,94 @@
+---
+title: Attaching Handlers to Container Lifecycle Events
+---
+
+{% capture overview %}
+
+This page shows how to attach handlers to Container lifecycle events. Kubernetes supports
+the postStart and preStop events. Kubernetes sends the postStart event immediately
+after a Container is started, and it sends the preStop event immediately before the
+Container is terminated.
+
+{% endcapture %}
+
+
+{% capture prerequisites %}
+
+{% include task-tutorial-prereqs.md %}
+
+{% endcapture %}
+
+
+{% capture steps %}
+
+### Defining postStart and preStop handlers
+
+In this exercise, you create a Pod that has one Container. The Container has handlers
+for the postStart and preStop events.
+
+Here is the configuration file for the Pod:
+
+{% include code.html language="yaml" file="lifecycle-events.yaml" ghlink="/docs/tasks/configure-pod-container/lifecycle-events.yaml" %}
+
+In the configuration file, you can see that the postStart command writes a `message`
+file to the Container's `/usr/share` directory. The preStop command shuts down
+nginx gracefully. This is helpful if the Container is being terminated because of a failure.
+
+Create the Pod:
+
+    kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/lifecycle-events.yaml
+
+Verify that the Container in the Pod is running:
+
+    kubectl get pod lifecycle-demo
+
+Get a shell into the Container running in your Pod:
+
+    kubectl exec -it lifecycle-demo -- /bin/bash
+
+In your shell, verify that the `postStart` handler created the `message` file:
+
+    root@lifecycle-demo:/# cat /usr/share/message
+
+The output shows the text written by the postStart handler:
+
+    Hello from the postStart handler
+
+{% endcapture %}
+
+
+
+{% capture discussion %}
+
+### Discussion
+
+Kubernetes sends the postStart event immediately after the Container is created.
+There is no guarantee, however, that the postStart handler is called before
+the Container's entrypoint is called. The postStart handler runs asynchronously
+relative to the Container's code, but Kubernetes' management of the container
+blocks until the postStart handler completes. The Container's status is not
+set to RUNNING until the postStart handler completes.
+
+Kubernetes sends the preStop event immediately before the Container is terminated.
+Kubernetes' management of the Container blocks until the preStop handler completes,
+unless the Pod's grace period expires. For more details, see
+[Termination of Pods](/docs/user-guide/pods/#termination-of-pods).
+
+{% endcapture %}
+
+
+{% capture whatsnext %}
+
+* Learn more about [Container lifecycle hooks](/docs/user-guide/container-environment/.)
+* Learn more about the [lifecycle of a Pod](https://kubernetes.io/docs/user-guide/pod-states/).
+
+
+#### Reference
+ 
+* [Lifecycle](https://kubernetes.io/docs/resources-reference/1_5/#lifecycle-v1)
+* [Container](https://kubernetes.io/docs/resources-reference/1_5/#container-v1)
+* See `terminationGracePeriodSeconds` in [PodSpec](/docs/resources-reference/v1.5/#podspec-v1)
+
+{% endcapture %}
+
+{% include templates/task.md %}
diff --git a/docs/tasks/configure-pod-container/lifecycle-events.yaml b/docs/tasks/configure-pod-container/lifecycle-events.yaml
@@ -0,0 +1,33 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: lifecycle-demo
+spec:
+  containers:
+  - name: lifecycle-demo-container
+    image: nginx
+
+    lifecycle:
+      postStart:
+        exec:
+          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
+      preStop:
+        exec:
+          command: ["/usr/sbin/nginx","-s","quit"]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tasks/index.md b/docs/tasks/index.md
@@ -20,6 +20,7 @@ single thing, typically by giving a short sequence of steps.
 * [Configuring Liveness and Readiness Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)
 * [Communicating Between Pods Running in the Same Container](/docs/tasks/configure-pod-container/communicate-containers-same-pod/)
 * [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/)
 
 #### Accessing Applications in a Cluster
 
diff --git a/docs/tutorials/kubernetes-basics/explore-intro.html b/docs/tutorials/kubernetes-basics/explore-intro.html
@@ -28,7 +28,7 @@ <h3>Objectives</h3>
 
 			<div class="col-md-8">
 				<h2>Kubernetes Pods</h2>
-				<p>When you created a Deployment in Module <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>, Kubernetes created a <b>Pod</b> to host your application instance. A Pod is Kubernetes abstraction that represents a group of one or more application containers (such as Docker or rkt), and some shared resources for those containers. Those resources include:</p>
+				<p>When you created a Deployment in Module <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>, Kubernetes created a <b>Pod</b> to host your application instance. A Pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker or rkt), and some shared resources for those containers. Those resources include:</p>
 				<ul>
 					<li>Shared storage, as Volumes</li>
 					<li>Networking, as a unique cluster IP address</li>
diff --git a/docs/user-guide/kubeconfig-file.md b/docs/user-guide/kubeconfig-file.md
@@ -16,7 +16,7 @@ So in order to easily switch between multiple clusters, for multiple users, a ku
 
 This file contains a series of authentication mechanisms and cluster connection information associated with nicknames.  It also introduces the concept of a tuple of authentication information (user) and cluster connection information called a context that is also associated with a nickname.
 
-Multiple kubeconfig files are allowed, if specified explicitly.  At runtime they are loaded and merged along with override options specified from the command line (see [rules](#loading-and-merging) below).
+Multiple kubeconfig files are allowed, if specified explicitly.  At runtime they are loaded and merged along with override options specified from the command line (see [rules](#loading-and-merging-rules) below).
 
 ## Related discussion
 
