Reduce heading levels by 1.

2017-01-18 10:18:37 -08:00
parent 0f6b992771
commit 02d17ade5f
40 changed files with 178 additions and 187 deletions
@@ -28,7 +28,7 @@ load-balanced access to an application running in a cluster.

 {% capture lessoncontent %}

-### Creating a Service for an application running in two pods
+## Creating a Service for an application running in two pods

 1. Run a Hello World application in your cluster:

@@ -98,7 +98,7 @@ load-balanced access to an application running in a cluster.
    where `<minikube-node-ip-address>` us the IP address of your Minikube node,
    and `<service-node-port>` is the NodePort value for your service.

-### Using a service configuration file
+## Using a service configuration file

 As an alternative to using `kubectl expose`, you can use a
 [service configuration file](/docs/user-guide/services/operations)
@@ -108,15 +108,6 @@ to create a Service.
 {% endcapture %}


-{% capture cleanup %}
-
-If you want to stop the Hello World application, enter these commands:
-
-    TODO
-
-{% endcapture %}
-
-
 {% capture whatsnext %}

 Learn more about
@@ -22,7 +22,7 @@ for database debugging.

 {% capture steps %}

-### Creating a pod to run a Redis server
+## Creating a pod to run a Redis server

 1. Create a pod:

@@ -51,7 +51,7 @@ for database debugging.

        6379

-### Forward a local port to a port on the pod
+## Forward a local port to a port on the pod

 1. Forward port 6379 on the local workstation to port 6379 of redis-master pod:

@@ -77,7 +77,7 @@ for database debugging.

 {% capture discussion %}

-### Discussion
+## Discussion

 Connections made to local port 6379 are forwarded to port 6379 of the pod that
 is running the Redis server. With this connection in place you can use your
@@ -19,13 +19,13 @@ This page shows how to use an HTTP proxy to access the Kubernetes API.

 {% capture steps %}

-### Using kubectl to start a proxy server
+## Using kubectl to start a proxy server

 This command starts a proxy to the Kubernetes API server:

    kubectl proxy --port=8080

-### Exploring the Kubernetes API
+## Exploring the Kubernetes API

 When the proxy server is running, you can explore the API using `curl`, `wget`,
 or a browser.
@@ -15,7 +15,7 @@ Kubernetes cluster.

 {% capture steps %}

-### Adding a label to a node
+## Adding a label to a node

 1. List the nodes in your cluster:

@@ -49,7 +49,7 @@ Kubernetes cluster.
    In the preceding output, you can see that the `worker0` node has a
    `disktype=ssd` label.

-### Creating a pod that gets scheduled to your chosen node
+## Creating a pod that gets scheduled to your chosen node

 This pod configuration file describes a pod that has a node selector,
 `disktype: ssd`. This means that the pod will get scheduled on a node that has
@@ -15,7 +15,7 @@ PersistentVolume.

 {% capture steps %}

-### Why change reclaim policy of a PersistentVolume
+## Why change reclaim policy of a PersistentVolume

 `PersistentVolumes` can have various reclaim policies, including "Retain",
 "Recycle", and "Delete". For dynamically provisioned `PersistentVolumes`, 
@@ -27,7 +27,7 @@ policy. With the "Retain" policy, if a user deletes a `PeristentVolumeClaim`,
 the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to the
 `Released` phase, where all of its data can be manually recovered.

-### Changing the reclaim policy of a PersistentVolume
+## Changing the reclaim policy of a PersistentVolume

 1. List the PersistentVolumes in your cluster:

@@ -70,7 +70,7 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
 * Learn more about [PersistentVolumes](/docs/user-guide/persistent-volumes/).
 * Learn more about [PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims).

-#### Reference
+### Reference

 * [PersistentVolume](/docs/api-reference/v1/definitions/#_v1_persistentvolume)
 * [PersistentVolumeClaim](/docs/api-reference/v1/definitions/#_v1_persistentvolumeclaim)
@@ -19,7 +19,7 @@ Kubernetes cluster.

 {% capture steps %}

-### Determining whether DNS horizontal autoscaling is already enabled
+## Determining whether DNS horizontal autoscaling is already enabled

 List the Deployments in your cluster in the kube-system namespace:

@@ -36,7 +36,7 @@ If you see "kube-dns-autoscaler" in the output, DNS horizontal autoscaling is
 already enabled, and you can skip to
 [Tuning autoscaling parameters](#tuning-autoscaling-parameters).

-### Getting the name of your DNS Deployment or ReplicationController
+## Getting the name of your DNS Deployment or ReplicationController

 List the Deployments in your cluster in the kube-system namespace:

@@ -63,7 +63,7 @@ The output is similar to this:
    kube-dns-v20    1         1         1         ...
    ...

-### Determining your scale target
+## Determining your scale target

 If you have a DNS Deployment, your scale target is:

@@ -80,7 +80,7 @@ where <your-rc-name> is the name of your DNS ReplicationController. For example,
 if your DNS ReplicationController name is kube-dns-v20, your scale target is
 ReplicationController/kube-dns-v20.

-### Enabling DNS horizontal autoscaling
+## Enabling DNS horizontal autoscaling

 In this section, you create a Deployment. The Pods in the Deployment run a
 container based on the `cluster-proportional-autoscaler-amd64` image.
@@ -102,7 +102,7 @@ The output of a successful command is:

 DNS horizontal autoscaling is now enabled.

-### Tuning autoscaling parameters
+## Tuning autoscaling parameters

 Verify that the kube-dns-autoscaler ConfigMap exists:

@@ -139,12 +139,12 @@ cores, `nodesPerReplica` dominates.
 There are other supported scaling patterns. For details, see
 [cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler).

-### Disable DNS horizontal autoscaling
+## Disable DNS horizontal autoscaling

 There are a few options for turning DNS horizontal autoscaling. Which option to
 use depends on different conditions.

-#### Option 1: Scale down the kube-dns-autoscaler deployment to 0 replicas
+### Option 1: Scale down the kube-dns-autoscaler deployment to 0 replicas

 This option works for all situations. Enter this command:

@@ -165,7 +165,7 @@ The output displays 0 in the DESIRED and CURRENT columns:
    kube-dns-autoscaler   0         0         0            0           ...
    ...

-#### Option 2: Delete the kube-dns-autoscaler deployment
+### Option 2: Delete the kube-dns-autoscaler deployment

 This option works if kube-dns-autoscaler is under your own control, which means
 no one will re-create it:
@@ -176,7 +176,7 @@ The output is:

    deployment "kube-dns-autoscaler" deleted

-#### Option 3: Delete the kube-dns-autoscaler manifest file from the master node
+### Option 3: Delete the kube-dns-autoscaler manifest file from the master node

 This option works if kube-dns-autoscaler is under control of the
 [Addon Manager](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/README.md)'s
@@ -194,7 +194,7 @@ kube-dns-autoscaler Deployment.

 {% capture discussion %}

-### Understanding how DNS horizontal autoscaling works
+## Understanding how DNS horizontal autoscaling works

 * The cluster-proportional-autoscaler application is deployed separately from
 the DNS service.
@@ -215,7 +215,7 @@ the autoscaler Pod.
 * The autoscaler provides a controller interface to support two control
 patterns: *linear* and *ladder*.

-### Future enhancements
+## Future enhancements

 Control patterns, in addition to linear and ladder, that consider custom metrics
 are under consideration as a future development.
@@ -21,7 +21,7 @@ application-level disruption SLOs you want the system to enforce.

 {% capture steps %}

-### Use `kubectl drain` to remove a node from service
+## Use `kubectl drain` to remove a node from service

 You can use `kubectl drain` to safely evict all of your pods from a
 node before you perform maintenance on the node (e.g. kernel upgrade,
@@ -64,7 +64,7 @@ kubectl uncordon <node name>
 ```
 afterwards to tell Kubernetes that it can resume scheduling new pods onto the node.

-### Draining multiple nodes in parallel
+## Draining multiple nodes in parallel

 The `kubectl drain` command should only be issued to a single node at a
 time. However, you can run multiple `kubectl drain` commands for
@@ -19,7 +19,7 @@ in a Kubernetes Pod.

 {% capture steps %}

-### Assigning CPU and RAM resources to a container
+## Assigning CPU and RAM resources to a container

 When you create a Pod, you can request CPU and RAM resources for the containers
 that run in the Pod. You can also set limits for CPU and RAM resources. To
@@ -64,7 +64,7 @@ for the `Pod`:
              cpu:    250m
              memory:   64Mi

-### Understanding CPU and RAM units
+## Understanding CPU and RAM units

 The CPU resource is measured in *cpu*s. Fractional values are allowed. You can
 use the suffix *m* to mean mili. For example 100m cpu is 100 milicpu, and is
@@ -89,7 +89,7 @@ If you specify a request, a Pod is guaranteed to be able to use that much
 of the resource. See
 [Resource QoS](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/resource-qos.md) for the difference between resource limits and requests.

-### If you don't specify limits or requests
+## If you don't specify limits or requests

 If you don't specify a RAM limit, Kubernetes places no upper bound on the
 amount of RAM a Container can use. A Container could use all the RAM
@@ -21,7 +21,7 @@ Container is terminated.

 {% capture steps %}

-### Defining postStart and preStop handlers
+## 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.
@@ -60,7 +60,7 @@ The output shows the text written by the postStart handler:

 {% capture discussion %}

-### 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
@@ -83,7 +83,7 @@ unless the Pod's grace period expires. For more details, see
 * Learn more about the [lifecycle of a Pod](https://kubernetes.io/docs/user-guide/pod-states/).


-#### Reference
+### Reference
 
 * [Lifecycle](https://kubernetes.io/docs/resources-reference/1_5/#lifecycle-v1)
 * [Container](https://kubernetes.io/docs/resources-reference/1_5/#container-v1)
@@ -19,7 +19,7 @@ in the same Pod.

 {% capture steps %}

-###  Creating a Pod that runs two Containers
+##  Creating a Pod that runs two Containers

 In this exercise, you create a Pod that runs two Containers. The two containers
 share a Volume that they can use to communicate. Here is the configuration file
@@ -111,7 +111,7 @@ The output shows that nginx serves a web page written by the debian container:

 {% capture discussion %}

-### Discussion
+## Discussion

 The primary reason that Pods can have multiple containers is to support
 helper applications that assist a primary application. Typical examples of
@@ -30,7 +30,7 @@ When a Pod is not ready, it is removed from Service load balancers.

 {% capture steps %}

-### Defining a liveness command
+## Defining a liveness command

 Many applications running for long periods of time eventually transition to
 broken states, and cannot recover except by being restarted. Kubernetes provides
@@ -117,7 +117,7 @@ NAME            READY     STATUS    RESTARTS   AGE
 liveness-exec   1/1       Running   1          1m
 ```

-### Defining a liveness HTTP request
+## Defining a liveness HTTP request

 Another kind of liveness probe uses an HTTP GET request. Here is the configuration
 file for a Pod that runs a container based on the `gcr.io/google_containers/liveness`
@@ -173,7 +173,7 @@ the Container has been restarted:
 kubectl describe pod liveness-http
 ```

-### Using a named port
+## Using a named port

 You can use a named
 [ContainerPort](/docs/api-reference/v1/definitions/#_v1_containerport)
@@ -191,7 +191,7 @@ livenessProbe:
  port: liveness-port
 ```

-### Defining readiness probes
+## Defining readiness probes

 Sometimes, applications are temporarily unable to serve traffic.
 For example, an application might need to load large data or configuration
@@ -219,7 +219,7 @@ readinessProbe:

 {% capture discussion %}

-### Discussion
+## Discussion

 {% comment %}
 Eventually, some of this Discussion section could be moved to a concept topic.
@@ -260,7 +260,7 @@ In addition to command probes and HTTP probes, Kubenetes supports
 * Learn more about
 [Health Checking section](/docs/user-guide/walkthrough/k8s201/#health-checking).

-#### Reference
+### Reference

 * [Pod](http://kubernetes.io/docs/api-reference/v1/definitions#_v1_pod)
 * [Container](/docs/api-reference/v1/definitions/#_v1_container)
@@ -16,7 +16,7 @@ application Container runs.

 {% capture steps %}

-### Creating a Pod that has an init Container
+## Creating a Pod that has an init Container

 In this exercise you create a Pod that has one application Container and one
 init Container. The init Container runs to completion before the application
@@ -23,7 +23,7 @@ key-value cache and store.

 {% capture steps %}

-### Configuring a volume for a Pod
+## Configuring a volume for a Pod

 In this exercise, you create a Pod that runs one Container. This Pod has a
 Volume of type
@@ -19,7 +19,7 @@ in a Kubernetes Pod.

 {% capture steps %}

-### Defining a command and arguments when you create a Pod
+## Defining a command and arguments when you create a Pod

 When you create a Pod, you can define a command and arguments for the
 containers that run in the Pod. To define a command, include the `command`
@@ -60,7 +60,7 @@ from the Pod:
        command-demo
        tcp://10.3.240.1:443

-### Using environment variables to define arguments
+## Using environment variables to define arguments

 In the preceding example, you defined the arguments directly by
 providing strings. As an alternative to providing strings directly,
@@ -81,7 +81,7 @@ and
 NOTE: The environment variable appears in parentheses, `"$(VAR)"`. This is
 required for the variable to be expanded in the `command` or `args` field.

-### Running a command in a shell
+## Running a command in a shell

 In some cases, you need your command to run in a shell. For example, your
 command might consist of several commands piped together, or it might be a shell
@@ -19,7 +19,7 @@ in a Kubernetes Pod.

 {% capture steps %}

-### Defining an environment variable for a container
+## Defining an environment variable for a container

 When you create a Pod, you can set environment variables for the containers
 that run in the Pod. To set environment variables, include the `env` field in
@@ -15,7 +15,7 @@ encryption keys, into Pods.

 {% capture steps %}

-### Converting your secret data to a base-64 representation
+## Converting your secret data to a base-64 representation

 Suppose you want to have two pieces of secret data: a username `my-app` and a password
 `39528$vdg7Jb`. First, use [Base64 encoding](https://www.base64encode.org/) to
@@ -28,7 +28,7 @@ example:
 The output shows that the base-64 representation of your username is `bXktYXBwCg==`,
 and the base-64 representation of your password is `Mzk1MjgkdmRnN0piCg==`.

-### Creating a Secret
+## Creating a Secret

 Here is a configuration file you can use to create a Secret that holds your
 username and password:
@@ -72,7 +72,7 @@ username and password:
        password:   13 bytes
        username:   7 bytes

-### Creating a Pod that has access to the secret data through a Volume
+## Creating a Pod that has access to the secret data through a Volume

 Here is a configuration file you can use to create a Pod:

@@ -119,7 +119,7 @@ is exposed:
        my-app
        39528$vdg7Jb

-### Creating a Pod that has access to the secret data through environment variables
+## Creating a Pod that has access to the secret data through environment variables

 Here is a configuration file you can use to create a Pod:

@@ -160,7 +160,7 @@ Here is a configuration file you can use to create a Pod:
 * Learn more about [Secrets](/docs/user-guide/secrets/).
 * Learn about [Volumes](/docs/user-guide/volumes/).

-#### Reference
+### Reference

 * [Secret](docs/api-reference/v1/definitions/#_v1_secret)
 * [Volume](docs/api-reference/v1/definitions/#_v1_volume)
@@ -20,7 +20,7 @@ private Docker registry or repository.

 {% capture steps %}

-### Logging in to Docker
+## Logging in to Docker

    docker login

@@ -43,7 +43,7 @@ The output contains a section similar to this:
        }
    }

-### Creating a Secret that holds your authorization token
+## Creating a Secret that holds your authorization token

 Create a Secret named `regsecret`:

@@ -55,7 +55,7 @@ where:
 * `<your-pword>` is your Docker password.
 * `<your-email>` is your Docker email.

-### Understanding your Secret
+## Understanding your Secret

 To understand what's in the Secret you just created, start by viewing the
 Secret in YAML format:
@@ -92,7 +92,7 @@ The output is similar to this:
 Notice that the secret data contains the authorization token from your
 `config.json` file.

-### Creating a Pod that uses your Secret
+## Creating a Pod that uses your Secret

 Here is a configuration file for a Pod that needs access to your secret data:

@@ -27,7 +27,7 @@ the general

 {% capture steps %}

-### Writing and reading a termination message
+## Writing and reading a termination message

 In this exercise, you create a Pod that runs one container.
 The configuration file specifies a command that runs when
@@ -75,7 +75,7 @@ only the termination message:
 {% raw %}    kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"{% endraw %}
 ```

-### Setting the termination log file
+## Setting the termination log file

 By default Kubernetes retrieves termination messages from
 `/dev/termination-log`. To change this to a different file,
@@ -26,7 +26,7 @@ This task shows you how to debug a StatefulSet.

 {% capture steps %}

-### Debugging a StatefulSet
+## Debugging a StatefulSet

 In order to list all the pods which belong to a StatefulSet, which have a label `app=myapp` set on them, you can use the following: 

@@ -44,7 +44,7 @@ kubectl annotate pods <pod-name> pod.alpha.kubernetes.io/initialized="false" --o

 When the annotation is set to `"false"`, the StatefulSet will not respond to its Pods becoming unhealthy or unavailable. It will not create replacement Pods till the annotation is removed or set to `"true"` on each StatefulSet Pod. 

-#### Step-wise Initialization
+### Step-wise Initialization

 You can also use the same annotation to debug race conditions during bootstrapping of the StatefulSet by setting the `pod.alpha.kubernetes.io/initialized` annotation to `"false"` in the `.spec.template.metadata.annotations` field of the StatefulSet prior to creating it. 

@@ -21,13 +21,13 @@ This page shows how to delete Pods which are part of a stateful set, and explain
 {% capture steps %}


-### StatefulSet considerations
+## StatefulSet considerations

 In normal operation of a StatefulSet, there is **never** a need to force delete a StatefulSet Pod. The StatefulSet controller is responsible for creating, scaling and deleting members of the StatefulSet. It tries to ensure that the specified number of Pods from ordinal 0 through N-1 are alive and ready. StatefulSet ensures that, at any time, there is at most one Pod with a given identity running in a cluster. This is referred to as *at most one* semantics provided by a StatefulSet.

 Manual force deletion should be undertaken with caution, as it has the potential to violate the at most one semantics inherent to StatefulSet. StatefulSets may be used to run distributed and clustered applications which have a need for a stable network identity and stable storage. These applications often have configuration which relies on an ensemble of a fixed number of members with fixed identities. Having multiple members with the same identity can be disastrous and may lead to data loss (e.g. split brain scenario in quorum-based systems). 

-### Deleting Pods
+## Deleting Pods

 You can perform a graceful pod deletion with the following command:

@@ -46,7 +46,7 @@ The recommended best practice is to use the first or second approach. If a Node

 Normally, the system completes the deletion once the Pod is no longer running on a Node, or the Node is deleted by an administrator. You may override this by force deleting the Pod.

-#### Force Deletion
+### Force Deletion

 Force deletions **do not** wait for confirmation from the kubelet that the Pod has been terminated. Irrespective of whether a force deletion is successful in killing a Pod, it will immediately free up the name from the apiserver. This would let the StatefulSet controller create a replacement Pod with that same identity; this can lead to the duplication of a still-running Pod, and if said Pod can still communicate with the other members of the StatefulSet, will violate the at most one semantics that StatefulSet is designed to guarantee.

@@ -22,7 +22,7 @@ This task shows you how to delete a StatefulSet.

 {% capture steps %}

-### Deleting a StatefulSet
+## Deleting a StatefulSet

 You can delete a StatefulSet in the same way you delete other resources in Kubernetes: use the `kubectl delete` command, and specify the StatefulSet either by file or by name.

@@ -52,13 +52,13 @@ By passing `--cascade=false` to `kubectl delete`, the Pods managed by the Statef
 kubectl delete pods -l app=myapp
 ```

-#### Persistent Volumes
+### Persistent Volumes

 Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have left the [terminating state](/docs/user-guide/pods/index#termination-of-pods) might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.

 **Note: Use caution when deleting a PVC, as it may lead to data loss.**

-#### Complete deletion of a StatefulSet
+### Complete deletion of a StatefulSet

 To simply delete everything in a StatefulSet, including the associated pods, you can run a series of commands similar to the following:

@@ -72,7 +72,7 @@ kubectl delete pvc -l app=myapp

 In the example above, the Pods have the label `app=myapp`; substitute your own label as appropriate.

-#### Force deletion of StatefulSet pods
+### Force deletion of StatefulSet pods

 If you find that some pods in your StatefulSet are stuck in the 'Terminating' or 'Unknown' states for an extended period of time, you may need to manually intervene to forcefully delete the pods from the apiserver. This is a potentially dangerous task. Refer to [Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/) for details.

@@ -25,13 +25,13 @@ This page shows how to scale a StatefulSet.

 {% capture steps %}

-### Use `kubectl` to scale StatefulSets
+## Use `kubectl` to scale StatefulSets

 Make sure you have `kubectl` upgraded to Kubernetes version 1.5 or later before
 continuing. If you're unsure, run `kubectl version` and check `Client Version`
 for which kubectl you're using.

-#### `kubectl scale`
+### `kubectl scale`

 First, find the StatefulSet you want to scale. Remember, you need to first understand if you can scale it or not. 

@@ -45,7 +45,7 @@ Change the number of replicas of your StatefulSet:
 kubectl scale statefulsets <stateful-set-name> --replicas=<new-replicas>
 ```

-#### Alternative: `kubectl apply` / `kubectl edit` / `kubectl patch`
+### Alternative: `kubectl apply` / `kubectl edit` / `kubectl patch`

 Alternatively, you can do [in-place updates](/docs/user-guide/managing-deployments/#in-place-updates-of-resources) on your StatefulSets. 

@@ -68,9 +68,9 @@ Or use `kubectl patch`:
 kubectl patch statefulsets <stateful-set-name> -p '{"spec":{"replicas":<new-replicas>}}'
 ```

-### Troubleshooting
+## Troubleshooting

-#### Scaling down doesn't not work right
+### Scaling down doesn't not work right

 You cannot scale down a StatefulSet when any of the stateful Pods it manages is unhealthy. Scaling down only takes place
 after those stateful Pods become running and ready. 
@@ -23,7 +23,7 @@ This page shows how to upgrade from PetSets (Kubernetes version 1.3 or 1.4) to *

 {% capture steps %}

-### Differences between alpha PetSets and beta StatefulSets
+## Differences between alpha PetSets and beta StatefulSets

 PetSet was introduced as an alpha resource in Kubernetes release 1.3, and was renamed to StatefulSet as a beta resource in 1.5. 
 Here are some notable changes:
@@ -33,13 +33,13 @@ Here are some notable changes:
 * **Flipped debug annotation behavior**: The default value of the debug annotation (`pod.alpha.kubernetes.io/initialized`) is now `true`. The absence of this annotation will pause PetSet operations, but will NOT pause StatefulSet operations. In most cases, you no longer need this annotation in your StatefulSet manifests. 


-### Upgrading from PetSets to StatefulSets
+## Upgrading from PetSets to StatefulSets

 Note that these steps need to be done in the specified order. You **should
 NOT upgrade your Kubernetes master, nodes, or `kubectl` to Kubernetes version
 1.5 or later**, until told to do so.

-#### Find all PetSets and their manifests 
+### Find all PetSets and their manifests 

 First, find all existing PetSets in your cluster:

@@ -60,7 +60,7 @@ Here's an example command for you to save all existing PetSets as one file.
 kubectl get petsets --all-namespaces -o yaml > all-petsets.yaml
 ```

-#### Prepare StatefulSet manifests 
+### Prepare StatefulSet manifests 

 Now, for every PetSet manifest you have, prepare a corresponding StatefulSet manifest: 

@@ -71,7 +71,7 @@ Now, for every PetSet manifest you have, prepare a corresponding StatefulSet man
 It's recommended that you keep both PetSet manifests and StatefulSet manifests, so that you can safely roll back and recreate your PetSets, 
 if you decide not to upgrade your cluster. 

-#### Delete all PetSets without cascading
+### Delete all PetSets without cascading

 If you find existing PetSets in your cluster in the previous step, you need to delete all PetSets *without cascading*. You can do this from `kubectl` with `--cascade=false`. 
 Note that if the flag isn't set, **cascading deletion will be performed by default**, and all Pods managed by your PetSets will be gone. 
@@ -103,18 +103,18 @@ kubectl get petsets --all-namespaces
 At this moment, you've deleted all PetSets in your cluster, but not their Pods, Persistent Volumes, or Persistent Volume Claims. 
 However, since the Pods are not managed by PetSets anymore, they will be vulnerable to node failures until you finish the master upgrade and recreate StatefulSets.

-#### Upgrade your master to Kubernetes version 1.5 or later
+### Upgrade your master to Kubernetes version 1.5 or later

 Now, you can [upgrade your Kubernetes master](/docs/admin/cluster-management/#upgrading-a-cluster) to Kubernetes version 1.5 or later.
 Note that **you should NOT upgrade Nodes at this time**, because the Pods
 (that were once managed by PetSets) are now vulnerable to node failures. 

-#### Upgrade kubectl to Kubernetes version 1.5 or later
+### Upgrade kubectl to Kubernetes version 1.5 or later

 Upgrade `kubectl` to Kubernetes version 1.5 or later, following [the steps for installing and setting up 
 kubectl](/docs/user-guide/prereqs/).

-#### Create StatefulSets
+### Create StatefulSets

 Make sure you have both master and `kubectl` upgraded to Kubernetes version 1.5
 or later before continuing:
@@ -147,7 +147,7 @@ newly-upgraded cluster:
 kubectl get statefulsets --all-namespaces
 ```

-#### Upgrade nodes to Kubernetes version 1.5 or later (optional)
+### Upgrade nodes to Kubernetes version 1.5 or later (optional)

 You can now [upgrade Kubernetes nodes](/docs/admin/cluster-management/#upgrading-a-cluster)
 to Kubernetes version 1.5 or later. This step is optional, but needs to be done after all StatefulSets
@@ -30,7 +30,7 @@ Init Containers.

 {% capture steps %}

-### Checking the status of Init Containers
+## Checking the status of Init Containers

 The Pod status will give you an overview of Init Container execution:

@@ -49,7 +49,7 @@ NAME         READY     STATUS     RESTARTS   AGE
 See [Understanding Pod status](#understanding-pod-status) for more examples of
 status values and their meanings.

-### Getting details about Init Containers
+## Getting details about Init Containers

 You can see detailed information about Init Container execution by running:

@@ -98,7 +98,7 @@ kubectl get pod <pod-name> --template '{{index .metadata.annotations "pod.beta.k

 This will return the same information as above, but in raw JSON format.

-### Accessing logs from Init Containers
+## Accessing logs from Init Containers

 You can access logs for an Init Container by passing its Container name along
 with the Pod name:
@@ -115,7 +115,7 @@ commands as they're executed. For example, you can do this in Bash by running

 {% capture discussion %}

-### Understanding Pod status
+## Understanding Pod status

 A Pod status beginning with `Init:` summarizes the status of Init Container
 execution. The table below describes some example status values that you might