removing toc shortcode. (#10720)

2018-10-26 02:02:31 +08:00
parent 8f2bb3d6ad
commit 04163e9a7c
81 changed files with 183 additions and 289 deletions
@@ -15,7 +15,6 @@ running cluster.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -21,7 +21,6 @@ in the Kubernetes source directory for a canonical example.

 {{% /capture %}}

-{{< toc >}}

 {{% capture prerequisites %}}

@@ -12,7 +12,6 @@ content_template: templates/task

 {{% /capture %}}

-{{< toc >}}

 {{% capture prerequisites %}}

@@ -20,7 +20,6 @@ directives.

 {{% /capture %}}

-{{< toc >}}

 {{% capture prerequisites %}}

@@ -178,7 +177,7 @@ spec:
 ```

 This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
-And the container's resource limit for the CPU resource is an integer greater than 
+And the container's resource limit for the CPU resource is an integer greater than
 or equal to one. The `nginx` container is granted 2 exclusive CPUs.


@@ -213,8 +212,8 @@ spec:
 ```

 This pod runs in the `Guaranteed` QoS class because only `limits` are specified
-and `requests` are set equal to `limits` when not explicitly specified. And the 
-container's resource limit for the CPU resource is an integer greater than or 
+and `requests` are set equal to `limits` when not explicitly specified. And the
+container's resource limit for the CPU resource is an integer greater than or
 equal to one. The `nginx` container is granted 2 exclusive CPUs.

 {{% /capture %}}
@@ -22,7 +22,6 @@ To dive a little deeper into implementation details, all cloud controller manage

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -18,7 +18,6 @@ vacated by the evicted critical add-on pod or the amount of resources available

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -51,7 +50,7 @@ killed for this purpose. Please ensure that rescheduler is not enabled along wit

 Rescheduler doesn't have any user facing configuration (component config) or API.

-### Marking pod as critical when using Rescheduler. 
+### Marking pod as critical when using Rescheduler.

 To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and

@@ -14,7 +14,6 @@ This document describes how to use kube-up/down scripts to manage highly availab

 {{% /capture %}}

-{{< toc >}}

 {{% capture prerequisites %}}

@@ -20,7 +20,6 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu

 {{% /capture %}}

-{{< toc >}}

 {{% capture prerequisites %}}

@@ -18,7 +18,6 @@ nodes become unstable.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -205,7 +204,7 @@ If `nodefs` filesystem has met eviction thresholds, `kubelet` frees up disk spac

 If the `kubelet` is unable to reclaim sufficient resource on the node, `kubelet` begins evicting Pods.

-The `kubelet` ranks Pods for eviction first by whether or not their usage  of the starved resource exceeds requests, 
+The `kubelet` ranks Pods for eviction first by whether or not their usage  of the starved resource exceeds requests,
 then by [Priority](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/), and then by the consumption of the starved compute resource relative to the Pods' scheduling requests.

 As a result, `kubelet` ranks and evicts Pods in the following order:
@@ -213,15 +212,15 @@ As a result, `kubelet` ranks and evicts Pods in the following order:
 * `BestEffort` or `Burstable` Pods whose usage of a starved resource exceeds its request.
 Such pods are ranked by Priority, and then usage above request.
 * `Guaranteed` pods and `Burstable` pods whose usage is beneath requests are evicted last.
-`Guaranteed` Pods are guaranteed only when requests and limits are specified for all 
-the containers and they are equal. Such pods are guaranteed to never be evicted because 
+`Guaranteed` Pods are guaranteed only when requests and limits are specified for all
+the containers and they are equal. Such pods are guaranteed to never be evicted because
 of another Pod's resource consumption. If a system daemon (such as `kubelet`, `docker`,
 and `journald`) is consuming more resources than were reserved via `system-reserved` or
-`kube-reserved` allocations, and the node only has `Guaranteed` or `Burstable` Pods using 
-less than requests remaining, then the node must choose to evict such a Pod in order to 
+`kube-reserved` allocations, and the node only has `Guaranteed` or `Burstable` Pods using
+less than requests remaining, then the node must choose to evict such a Pod in order to
 preserve node stability and to limit the impact of the unexpected consumption to other Pods.
 In this case, it will choose to evict pods of Lowest Priority first.
- 
+
 If necessary, `kubelet` evicts Pods one at a time to reclaim disk when `DiskPressure`
 is encountered. If the `kubelet` is responding to `inode` starvation, it reclaims
 `inodes` by evicting Pods with the lowest quality of service first. If the `kubelet`
@@ -23,7 +23,6 @@ on each node.

 {{% /capture %}}

-{{< toc >}}

 {{% capture prerequisites %}}

@@ -17,7 +17,6 @@ The `cloud-controller-manager` can be linked to any cloud provider that satisfie

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -16,7 +16,6 @@ This means that the pods are visible on the API server but cannot be controlled

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -103,7 +102,7 @@ Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/

 {{<note>}}
 **Note**: Make sure the kubelet has permission to create the mirror pod in the API server.
-If not, the creation request is rejected by the API server. See 
+If not, the creation request is rejected by the API server. See
 [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/).
 {{</note>}}