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
@@ -16,13 +16,12 @@ One CronJob object is like one line of a _crontab_ (cron table) file. It runs a
 on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
 {{< note >}}
 **Note:** All **CronJob** `schedule:` times are denoted in UTC.
-{{< /note >}} 
+{{< /note >}}

 For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -42,7 +41,7 @@ For every CronJob, the CronJob controller checks how many schedules it missed in
 Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.
 ````

-It is important to note that if the `startingDeadlineSeconds` field is set (not `nil`), the controller counts how many missed jobs occurred from the value of `startingDeadlineSeconds` until now rather than from the last scheduled time until now. For example, if `startingDeadlineSeconds` is `200`, the controller counts how many missed jobs occurred in the last 200 seconds. 
+It is important to note that if the `startingDeadlineSeconds` field is set (not `nil`), the controller counts how many missed jobs occurred from the value of `startingDeadlineSeconds` until now rather than from the last scheduled time until now. For example, if `startingDeadlineSeconds` is `200`, the controller counts how many missed jobs occurred in the last 200 seconds.

 A CronJob is counted as missed if it has failed to be created at its scheduled time. For example, If `concurrencyPolicy` is set to `Forbid` and a CronJob was attempted to be scheduled when there was a previous schedule still running, then it would count as missed.

@@ -29,7 +29,6 @@ different flags and/or different memory and cpu requests for different hardware

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -130,7 +129,7 @@ That introduces the following issues:
 * [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/)
   is handled by default scheduler. When preemption is enabled, the DaemonSet controller
   will make scheduling decisions without considering pod priority and preemption.
- 
+
 `ScheduleDaemonSetPods` allows you to schedule DaemonSets using the default
 scheduler instead of the DaemonSet controller, by adding the `NodeAffinity` term
 to the DaemonSet pods, instead of the `.spec.nodeName` term. The default
@@ -26,7 +26,6 @@ A Job can also be used to run multiple pods in parallel.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -223,7 +222,7 @@ Do this by setting the `.spec.activeDeadlineSeconds` field of the Job to a numbe

 The `activeDeadlineSeconds` applies to the duration of the job, no matter how many Pods are created.
 Once a Job reaches `activeDeadlineSeconds`, the Job and all of its Pods are terminated.
-The result is that the job has a status with `reason: DeadlineExceeded`. 
+The result is that the job has a status with `reason: DeadlineExceeded`.

 Note that a Job's `.spec.activeDeadlineSeconds` takes precedence over its `.spec.backoffLimit`. Therefore, a Job that is retrying one or more failed Pods will not deploy additional Pods once it reaches the time limit specified by `activeDeadlineSeconds`, even if the `backoffLimit` is not yet reached.

@@ -252,7 +251,7 @@ Note that both the Job Spec and the [Pod Template Spec](https://kubernetes.io/do

 Finished Jobs are usually no longer needed in the system. Keeping them around in
 the system will put pressure on the API server. If the Jobs are managed directly
-by a higher level controller, such as 
+by a higher level controller, such as
 [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), the Jobs can be
 cleaned up by CronJobs based on the specified capacity-based cleanup policy.

@@ -261,7 +260,7 @@ cleaned up by CronJobs based on the specified capacity-based cleanup policy.
 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}

 Another way to clean up finished Jobs (either `Complete` or `Failed`)
-automatically is to use a TTL mechanism provided by a 
+automatically is to use a TTL mechanism provided by a
 [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for
 finished resources, by specifying the `.spec.ttlSecondsAfterFinished` field of
 the Job.
@@ -290,16 +289,16 @@ spec:
 ```

 The Job `pi-with-ttl` will be eligible to be automatically deleted, `100`
-seconds after it finishes. 
+seconds after it finishes.

 If the field is set to `0`, the Job will be eligible to be automatically deleted
 immediately after it finishes. If the field is unset, this Job won't be cleaned
 up by the TTL controller after it finishes.

 Note that this TTL mechanism is alpha, with feature gate `TTLAfterFinished`. For
-more information, see the documentation for 
+more information, see the documentation for
 [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for
-finished resources. 
+finished resources.

 ## Job Patterns

@@ -24,7 +24,6 @@ Alpha Disclaimer: this feature is currently alpha, and can be enabled with
 {{% /capture %}}


-{{< toc >}}


 {{% capture body %}}
@@ -34,7 +33,7 @@ Alpha Disclaimer: this feature is currently alpha, and can be enabled with
 The TTL controller only supports Jobs for now. A cluster operator can use this feature to clean
 up finished Jobs (either `Complete` or `Failed`) automatically by specifying the
 `.spec.ttlSecondsAfterFinished` field of a Job, as in this
-[example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically). 
+[example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
 The TTL controller will assume that a resource is eligible to be cleaned up
 TTL seconds after the resource has finished, in other words, when the TTL has expired. When the
 TTL controller cleans up a resource, it will delete it cascadingly, i.e. delete
@@ -18,7 +18,6 @@ cluster actions, like upgrading and autoscaling clusters.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -266,6 +265,3 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
 * Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/)

 {{% /capture %}}
-
-
-
@@ -12,7 +12,6 @@ Containers that run before app Containers and can contain utilities or setup
 scripts not present in an app image.
 {{% /capture %}}

-{{< toc >}}

 This feature has exited beta in 1.6. Init Containers can be specified in the PodSpec
 alongside the app `containers` array. The beta annotation value will still be respected
@@ -329,6 +328,3 @@ is removed, requiring a conversion from the deprecated annotations to the
 * [Creating a Pod that has an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)

 {{% /capture %}}
-
-
-
@@ -10,7 +10,6 @@ weight: 10
 This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model.
 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}
 ## Understanding Pods
@@ -104,5 +103,3 @@ Rather than specifying the current desired state of all replicas, pod templates
  * [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
  * Other Pod Topics
 {{% /capture %}}
-
-
@@ -12,7 +12,6 @@ managed in Kubernetes.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -12,7 +12,6 @@ certain information into pods at creation time. The information can include
 secrets, volumes, volume mounts, and environment variables.
 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}
 ## Understanding Pod Presets
@@ -22,7 +21,7 @@ into a Pod at creation time.
 You use [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
 to specify the Pods to which a given Pod Preset applies.

-Using a Pod Preset allows pod template authors to not have to explicitly provide 
+Using a Pod Preset allows pod template authors to not have to explicitly provide
 all information for every pod. This way, authors of pod templates consuming a
 specific service do not need to know all the details about that service.

@@ -53,7 +52,7 @@ the Pod; for changes to `Volume`, Kubernetes modifies the Pod Spec.

 {{< note >}}
 **Note:** A Pod Preset is capable of modifying the `.spec.containers` field in a
-Pod spec when appropriate. *No* resource definition from the Pod Preset will be 
+Pod spec when appropriate. *No* resource definition from the Pod Preset will be
 applied to the `initContainers` field.
 {{< /note >}}

@@ -69,7 +68,7 @@ In order to use Pod Presets in your cluster you must ensure the following:

 1.  You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For
    example, this can be done by including `settings.k8s.io/v1alpha1=true` in
-    the `--runtime-config` option for the API server. 
+    the `--runtime-config` option for the API server.
 1.  You have enabled the admission controller `PodPreset`. One way to doing this
    is to include `PodPreset` in the `--enable-admission-plugins` option value specified
    for the API server.
@@ -83,5 +82,3 @@ In order to use Pod Presets in your cluster you must ensure the following:
 * [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/)

 {{% /capture %}}
-
-