Replace `` with when emphasizing something inline in docs/

docs/user-guide/application-troubleshooting.md

@@ -75,32 +75,32 @@ The first step in debugging a Pod is taking a look at it.  Check the current sta
 $ kubectl describe pods ${POD_NAME}
 ```
 
-Look at the state of the containers in the pod.  Are they all ```Running```?  Have there been recent restarts?
+Look at the state of the containers in the pod.  Are they all `Running`?  Have there been recent restarts?
 
 Continue debugging depending on the state of the pods.
 
 #### My pod stays pending
 
-If a Pod is stuck in ```Pending``` it means that it can not be scheduled onto a node.  Generally this is because
+If a Pod is stuck in `Pending` it means that it can not be scheduled onto a node.  Generally this is because
 there are insufficient resources of one type or another that prevent scheduling.  Look at the output of the
-```kubectl describe ...``` command above.  There should be messages from the scheduler about why it can not schedule
+`kubectl describe ...` command above.  There should be messages from the scheduler about why it can not schedule
 your pod.  Reasons include:
 
 * **You don't have enough resources**:  You may have exhausted the supply of CPU or Memory in your cluster, in this case
 you need to delete Pods, adjust resource requests, or add new nodes to your cluster. See [Compute Resources document](compute-resources.md#my-pods-are-pending-with-event-message-failedscheduling) for more information. 
 
-* **You are using ```hostPort```**:  When you bind a Pod to a ```hostPort``` there are a limited number of places that pod can be
-scheduled.  In most cases, ```hostPort``` is unnecessary, try using a Service object to expose your Pod.  If you do require
-```hostPort``` then you can only schedule as many Pods as there are nodes in your Kubernetes cluster.
+* **You are using `hostPort`**:  When you bind a Pod to a `hostPort` there are a limited number of places that pod can be
+scheduled.  In most cases, `hostPort` is unnecessary, try using a Service object to expose your Pod.  If you do require
+`hostPort` then you can only schedule as many Pods as there are nodes in your Kubernetes cluster.
 
 
 #### My pod stays waiting
 
-If a Pod is stuck in the ```Waiting``` state, then it has been scheduled to a worker node, but it can't run on that machine.
-Again, the information from ```kubectl describe ...``` should be informative.  The most common cause of ```Waiting``` pods is a failure to pull the image.  There are three things to check:
+If a Pod is stuck in the `Waiting` state, then it has been scheduled to a worker node, but it can't run on that machine.
+Again, the information from `kubectl describe ...` should be informative.  The most common cause of `Waiting` pods is a failure to pull the image.  There are three things to check:
 * Make sure that you have the name of the image correct
 * Have you pushed the image to the repository?
-* Run a manual ```docker pull <image>``` on your machine to see if the image can be pulled. 
+* Run a manual `docker pull <image>` on your machine to see if the image can be pulled. 
 
 #### My pod is crashing or otherwise unhealthy
 
@@ -117,13 +117,13 @@ If your container has previously crashed, you can access the previous container'
 $ kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
 ```
 
-Alternately, you can run commands inside that container with ```exec```:
+Alternately, you can run commands inside that container with `exec`:
 
 ```console
 $ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
 ```
 
-Note that ```-c ${CONTAINER_NAME}``` is optional and can be omitted for Pods that only contain a single container.
+Note that `-c ${CONTAINER_NAME}` is optional and can be omitted for Pods that only contain a single container.
 
 As an example, to look at the logs from a running Cassandra pod, you might run
 
@@ -141,7 +141,7 @@ feature request on GitHub describing your use case and why these tools are insuf
 Replication controllers are fairly straightforward.  They can either create Pods or they can't.  If they can't
 create pods, then please refer to the [instructions above](#debugging-pods) to debug your pods. 
 
-You can also use ```kubectl describe rc ${CONTROLLER_NAME}``` to introspect events related to the replication
+You can also use `kubectl describe rc ${CONTROLLER_NAME}` to introspect events related to the replication
 controller.
 
 ### Debugging Services
@@ -183,10 +183,10 @@ $ kubectl get pods --selector=name=nginx,type=frontend
 to list pods that match this selector.  Verify that the list matches the Pods that you expect to provide your Service.
 
 If the list of pods matches expectations, but your endpoints are still empty, it's possible that you don't
-have the right ports exposed.  If your service has a ```containerPort``` specified, but the Pods that are
+have the right ports exposed.  If your service has a `containerPort` specified, but the Pods that are
 selected don't have that port listed, then they won't be added to the endpoints list.
 
-Verify that the pod's ```containerPort``` matches up with the Service's ```containerPort```
+Verify that the pod's `containerPort` matches up with the Service's `containerPort`
 
 #### Network traffic is not forwarded
 
@@ -197,7 +197,7 @@ There are three things to
 check:
    * Are your pods working correctly?  Look for restart count, and [debug pods](#debugging-pods)
    * Can you connect to your pods directly?  Get the IP address for the Pod, and try to connect directly to that IP
-   * Is your application serving on the port that you configured?  Kubernetes doesn't do port remapping, so if your application serves on 8080, the ```containerPort``` field needs to be 8080.
+   * Is your application serving on the port that you configured?  Kubernetes doesn't do port remapping, so if your application serves on 8080, the `containerPort` field needs to be 8080.
 
 #### More information