Add ToC to some longer documents.

docs/user-guide/configuring-containers.md

@@ -14,6 +14,19 @@ certainly want the docs that go with that version.</h1>
 <!-- END MUNGE: UNVERSIONED_WARNING -->
 # Kubernetes User Guide: Managing Applications: Configuring and launching containers
 
+**Table of Contents**
+<!-- BEGIN MUNGE: GENERATED_TOC -->
+- [Kubernetes User Guide: Managing Applications: Configuring and launching containers](#kubernetes-user-guide:-managing-applications:-configuring-and-launching-containers)
+  - [Configuration in Kubernetes](#configuration-in-kubernetes)
+  - [Launching a container using a configuration file](#launching-a-container-using-a-configuration-file)
+  - [Validating configuration](#validating-configuration)
+  - [Environment variables and variable expansion](#environment-variables-and-variable-expansion)
+  - [Viewing pod status](#viewing-pod-status)
+  - [Viewing pod output](#viewing-pod-output)
+  - [Deleting pods](#deleting-pods)
+
+<!-- END MUNGE: GENERATED_TOC -->
+
 ## 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.

docs/user-guide/connecting-applications.md

@@ -14,6 +14,21 @@ certainly want the docs that go with that version.</h1>
 <!-- END MUNGE: UNVERSIONED_WARNING -->
 # Kubernetes User Guide: Managing Applications: Connecting applications
 
+**Table of Contents**
+<!-- BEGIN MUNGE: GENERATED_TOC -->
+- [Kubernetes User Guide: Managing Applications: Connecting applications](#kubernetes-user-guide:-managing-applications:-connecting-applications)
+- [The Kubernetes model for connecting Containers](#the-kubernetes-model-for-connecting-containers)
+  - [Exposing nginx pods to the cluster](#exposing-nginx-pods-to-the-cluster)
+  - [Creating a Service for the pods](#creating-a-service-for-the-pods)
+  - [Accessing the Service from other pods in the cluster](#accessing-the-service-from-other-pods-in-the-cluster)
+    - [Environment Variables:](#environment-variables:)
+    - [DNS:](#dns:)
+  - [Exposing the Service to the internet](#exposing-the-service-to-the-internet)
+
+<!-- END MUNGE: GENERATED_TOC -->
+
+# The Kubernetes model for connecting Containers
+
 Now that you have a continuously running, replicated application you can expose it on a network. Before discussing the Kubernetes approach to networking, it is worthwhile to contrast it with the "normal" way networking works with Docker.
 
 By default, Docker uses host-private networking, so containers can talk to other containers only if they are on the same machine. In order for Docker containers to communicate across nodes, they must be allocated ports on the machine's own IP address, which are then forwarded or proxied to the containers. This obviously means that containers must either coordinate which ports they use very carefully or else be allocated ports dynamically.

docs/user-guide/introspection-and-debugging.md

@@ -18,6 +18,15 @@ Once your application is running, you’ll inevitably need to debug problems wit
 Earlier we described how you can use ```kubectl get pods``` to retrieve simple status information about
 your pods. But there are a number of ways to get even more information about your application.
 
+**Table of Contents**
+<!-- BEGIN MUNGE: GENERATED_TOC -->
+- [Kubernetes User Guide: Managing Applications: Application Introspection and Debugging](#kubernetes-user-guide:-managing-applications:-application-introspection-and-debugging)
+  - [Using ```kubectl describe pod``` to fetch details about pods](#using-```kubectl-describe-pod```-to-fetch-details-about-pods)
+  - [Example: debugging Pending Pods](#example:-debugging-pending-pods)
+  - [Example: debugging a down/unreachable node](#example:-debugging-a-down/unreachable-node)
+
+<!-- END MUNGE: GENERATED_TOC -->
+
 ## Using ```kubectl describe pod``` to fetch details about pods
 
 For this example we’ll use a ReplicationController to create two pods, similar to the earlier example.

docs/user-guide/managing-deployments.md

@@ -16,6 +16,21 @@ certainly want the docs that go with that version.</h1>
 
 You’ve deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features we’ll discuss in more depth are [configuration files](configuring-containers.md#configuration-in-kubernetes) and [labels](deploying-applications.md#labels).
 
+**Table of Contents**
+<!-- BEGIN MUNGE: GENERATED_TOC -->
+- [Kubernetes User Guide: Managing Applications: Managing deployments](#kubernetes-user-guide:-managing-applications:-managing-deployments)
+  - [Organizing resource configurations](#organizing-resource-configurations)
+  - [Bulk operations in kubectl](#bulk-operations-in-kubectl)
+  - [Using labels effectively](#using-labels-effectively)
+  - [Canary deployments](#canary-deployments)
+  - [Updating labels](#updating-labels)
+  - [Scaling your application](#scaling-your-application)
+  - [Updating your application without a service outage](#updating-your-application-without-a-service-outage)
+  - [In-place updates of resources](#in-place-updates-of-resources)
+  - [Disruptive updates](#disruptive-updates)
+
+<!-- END MUNGE: GENERATED_TOC -->
+
 ## Organizing resource configurations
 
 Many applications require multiple resources to be created, such as a Replication Controller and a Service. Management of multiple resources can be simplified by grouping them together in the same file (separated by `---` in YAML). For example: