Fix some format (#7139)

docs/concepts/workloads/controllers/deployment.md

@@ -52,9 +52,10 @@ In this example:
   [Docker Hub](https://hub.docker.com/) image at version 1.7.9.
 * The Deployment opens port 80 for use by the Pods.
 
-Note: `matchLabels` is a map of {key,value} pairs. A single {key,value} in the matchLabels map 
+**Note:** `matchLabels` is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map 
-is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In",
+is equivalent to an element of `matchExpressions`, whose key field is "key", the operator is "In",
 and the values array contains only "value". The requirements are ANDed.
+{: .note}
 
 The `template` field contains the following instructions:
 
@@ -69,9 +70,10 @@ To create this Deployment, run the following command:
 kubectl create -f https://raw.githubusercontent.com/kubernetes/website/master/docs/concepts/workloads/controllers/nginx-deployment.yaml
 ```
 
-Note: You can append `--record` to this command to record the current command in the annotations of
+**Note:** You can append `--record` to this command to record the current command in the annotations of
 the created or updated resource. This is useful for future review, such as investigating which
 commands were executed in each Deployment revision.
+{: .note}
 
 Next, run `kubectl get deployments`. The output is similar to the following:
 
@@ -145,7 +147,7 @@ The created ReplicaSet ensures that there are three `nginx` Pods running at all
 **Note:** Do not change this label.
 {: .note}
 
-The `pod-template-hash label` is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts.
+The `pod-template-hash` label is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts.
 
 This label ensures that child ReplicaSets of a Deployment do not overlap. It is generated by hashing the `PodTemplate` of the ReplicaSet and using the resulting hash as the label value that is added to the ReplicaSet selector, Pod template labels,
 and in any existing Pods that the ReplicaSet might have.
@@ -273,7 +275,7 @@ in the new ReplicaSet, and the old ReplicaSet is scaled down to 0.
 
 ### Rollover (aka multiple updates in-flight)
 
-Each time a new deployment object is observed by the deployment controller, a ReplicaSet is created to bring up
+Each time a new deployment object is observed by the Deployment controller, a ReplicaSet is created to bring up
 the desired Pods if there is no existing ReplicaSet doing so. Existing ReplicaSet controlling Pods whose labels
 match `.spec.selector` but whose template does not match `.spec.template` are scaled down. Eventually, the new
 ReplicaSet will be scaled to `.spec.replicas` and all old ReplicaSets will be scaled to 0.
@@ -362,7 +364,7 @@ nginx-deployment-3066724191-eocby   0/1       ImagePullBackOff   0          6s
 
 **Note:** The Deployment controller will stop the bad rollout automatically, and will stop scaling up the new
 ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified.
-Kubernetes by default sets the value to 1 and spec.replicas to 1 so if you haven't cared about setting those
+Kubernetes by default sets the value to 1 and `spec.replicas` to 1 so if you haven't cared about setting those
 parameters, your Deployment can have 100% unavailability by default! This will be fixed in Kubernetes in a future
 version.
 {: .note}
@@ -526,7 +528,7 @@ deployment "nginx-deployment" image updated
 ```
 
 The image update starts a new rollout with ReplicaSet nginx-deployment-1989198191, but it's blocked due to the
-maxUnavailable requirement that we mentioned above.
+`maxUnavailable` requirement that we mentioned above.
 
 ```shell
 $ kubectl get rs