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