removing toc shortcode. (#10720)

content/en/docs/concepts/architecture/cloud-controller.md

@@ -18,7 +18,6 @@ Here's the architecture of a Kubernetes cluster without the cloud controller man
 
 {{% /capture %}}
 
-{{< toc >}}
 
 {{% capture body %}}
 
@@ -46,16 +45,16 @@ The CCM breaks away some of the functionality of Kubernetes controller manager (
 In version 1.9, the CCM runs the following controllers from the preceding list:
 
 * Node controller
-* Route controller 
+* Route controller
 * Service controller
 
-Additionally, it runs another controller called the PersistentVolumeLabels controller. This controller is responsible for setting the zone and region labels on PersistentVolumes created in GCP and AWS clouds. 
+Additionally, it runs another controller called the PersistentVolumeLabels controller. This controller is responsible for setting the zone and region labels on PersistentVolumes created in GCP and AWS clouds.
 
 {{< note >}}
-**Note:** Volume controller was deliberately chosen to not be a part of CCM. Due to the complexity involved and due to the existing efforts to abstract away vendor specific volume logic, it was decided that volume controller will not be moved to CCM. 
+**Note:** Volume controller was deliberately chosen to not be a part of CCM. Due to the complexity involved and due to the existing efforts to abstract away vendor specific volume logic, it was decided that volume controller will not be moved to CCM.
 {{< /note >}}
 
-The original plan to support volumes using CCM was to use Flex volumes to support pluggable volumes. However, a competing effort known as CSI is being planned to replace Flex. 
+The original plan to support volumes using CCM was to use Flex volumes to support pluggable volumes. However, a competing effort known as CSI is being planned to replace Flex.
 
 Considering these dynamics, we decided to have an intermediate stop gap measure until CSI becomes ready.
 
@@ -68,7 +67,7 @@ The CCM inherits its functions from components of Kubernetes that are dependent
 The majority of the CCM's functions are derived from the KCM. As mentioned in the previous section, the CCM runs the following control loops:
 
 * Node controller
-* Route controller 
+* Route controller
 * Service controller
 * PersistentVolumeLabels controller
 
@@ -92,7 +91,7 @@ The Service controller is responsible for listening to service create, update, a
 
 #### PersistentVolumeLabels controller
 
-The PersistentVolumeLabels controller applies labels on AWS EBS/GCE PD volumes when they are created. This removes the need for users to manually set the labels on these volumes. 
+The PersistentVolumeLabels controller applies labels on AWS EBS/GCE PD volumes when they are created. This removes the need for users to manually set the labels on these volumes.
 
 These labels are essential for the scheduling of pods as these volumes are constrained to work only within the region/zone that they are in. Any Pod using these volumes needs to be scheduled in the same region/zone.
 
@@ -100,7 +99,7 @@ The PersistentVolumeLabels controller was created specifically for the CCM; that
 
 ### 2. Kubelet
 
-The Node controller contains the cloud-dependent functionality of the kubelet. Prior to the introduction of the CCM, the kubelet was responsible for initializing a node with cloud-specific details such as IP addresses, region/zone labels and instance type information. The introduction of the CCM has moved this initialization operation from the kubelet into the CCM. 
+The Node controller contains the cloud-dependent functionality of the kubelet. Prior to the introduction of the CCM, the kubelet was responsible for initializing a node with cloud-specific details such as IP addresses, region/zone labels and instance type information. The introduction of the CCM has moved this initialization operation from the kubelet into the CCM.
 
 In this new model, the kubelet initializes a node without cloud-specific information. However, it adds a taint to the newly created node that makes the node unschedulable until the CCM initializes the node with cloud-specific information. It then removes this taint.
 
@@ -118,13 +117,13 @@ For more information about developing plugins, see [Developing Cloud Controller
 
 ## Authorization
 
-This section breaks down the access required on various API objects by the CCM to perform its operations. 
+This section breaks down the access required on various API objects by the CCM to perform its operations.
 
 ### Node Controller
 
 The Node controller only works with Node objects. It requires full access to get, list, create, update, patch, watch, and delete Node objects.
 
-v1/Node: 
+v1/Node:
 
 - Get
 - List
@@ -136,17 +135,17 @@ v1/Node:
 
 ### Route controller
 
-The route controller listens to Node object creation and configures routes appropriately. It requires get access to Node objects. 
+The route controller listens to Node object creation and configures routes appropriately. It requires get access to Node objects.
 
-v1/Node: 
+v1/Node:
 
 - Get
 
 ### Service controller
 
-The service controller listens to Service object create, update and delete events and then configures endpoints for those Services appropriately. 
+The service controller listens to Service object create, update and delete events and then configures endpoints for those Services appropriately.
 
-To access Services, it requires list, and watch access. To update Services, it requires patch and update access. 
+To access Services, it requires list, and watch access. To update Services, it requires patch and update access.
 
 To set up endpoints for the Services, it requires access to create, list, get, watch, and update.
 
@@ -249,7 +248,7 @@ rules:
 
 ## Vendor Implementations
 
-The following cloud providers have implemented CCMs: 
+The following cloud providers have implemented CCMs:
 
 * [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
 * [Oracle](https://github.com/oracle/oci-cloud-controller-manager)

content/en/docs/concepts/architecture/master-node-communication.md

@@ -18,7 +18,6 @@ cloud provider).
 
 {{% /capture %}}
 
-{{< toc >}}
 
 {{% capture body %}}
 
@@ -67,9 +66,9 @@ The connections from the apiserver to the kubelet are used for:
 
   * Fetching logs for pods.
   * Attaching (through kubectl) to running pods.
-  * Providing the kubelet's port-forwarding functionality. 
+  * Providing the kubelet's port-forwarding functionality.
 
-These connections terminate at the kubelet's HTTPS endpoint. By default, 
+These connections terminate at the kubelet's HTTPS endpoint. By default,
 the apiserver does not verify the kubelet's serving certificate,
 which makes the connection subject to man-in-the-middle attacks, and
 **unsafe** to run over untrusted and/or public networks.

content/en/docs/concepts/architecture/nodes.md

@@ -18,7 +18,6 @@ architecture design doc for more details.
 
 {{% /capture %}}
 
-{{< toc >}}
 
 {{% capture body %}}
 
@@ -76,18 +75,18 @@ the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce fr
 permanently left a cluster, the cluster administrator may need to delete the node object by hand.  Deleting the node object from
 Kubernetes causes all the Pod objects running on the node to be deleted from the apiserver, and frees up their names.
 
-In version 1.12, `TaintNodesByCondition` feature is promoted to beta，so node lifecycle controller automatically creates 
+In version 1.12, `TaintNodesByCondition` feature is promoted to beta，so node lifecycle controller automatically creates
 [taints](/docs/concepts/configuration/taint-and-toleration/) that represent conditions.
 Similarly the scheduler ignores conditions when considering a Node; instead
 it looks at the Node's taints and a Pod's tolerations.
 
 Now users can choose between the old scheduling model and a new, more flexible scheduling model.
-A Pod that does not have any tolerations gets scheduled according to the old model. But a Pod that 
+A Pod that does not have any tolerations gets scheduled according to the old model. But a Pod that
 tolerates the taints of a particular Node can be scheduled on that Node.
 
 {{< caution >}}
-**Caution:** Enabling this feature creates a small delay between the 
-time when a condition is observed and when a taint is created. This delay is usually less than one second, but it can increase the number of Pods that are successfully scheduled but rejected by the kubelet. 
+**Caution:** Enabling this feature creates a small delay between the
+time when a condition is observed and when a taint is created. This delay is usually less than one second, but it can increase the number of Pods that are successfully scheduled but rejected by the kubelet.
 {{< /caution >}}
 
 ### Capacity
@@ -127,7 +126,7 @@ a node from the following content:
 Kubernetes creates a node object internally (the representation), and
 validates the node by health checking based on the `metadata.name` field. If the node is valid -- that is, if all necessary
 services are running -- it is eligible to run a pod. Otherwise, it is
-ignored for any cluster activity until it becomes valid. 
+ignored for any cluster activity until it becomes valid.
 
 {{< note >}}
 **Note:** Kubernetes keeps the object for the invalid node and keeps checking to see whether it becomes valid.