blog: make minor corrections to upcoming SuspendJob post

Signed-off-by: Adhityaa Chandrasekar <adtac@google.com>
This commit is contained in:
Adhityaa Chandrasekar
2021-04-09 15:57:31 +00:00
parent 9dd42da09e
commit eb558e2442
@@ -8,7 +8,7 @@ layout: blog
**Author:** Adhityaa Chandrasekar (Google) **Author:** Adhityaa Chandrasekar (Google)
[Jobs](/docs/concepts/workloads/controllers/job/) are a crucial part of [Jobs](/docs/concepts/workloads/controllers/job/) are a crucial part of
Kubernetes API. While other kinds of workloads such as [Deployments](/docs/concepts/workloads/controllers/deployment/), Kubernetes' API. While other kinds of workloads such as [Deployments](/docs/concepts/workloads/controllers/deployment/),
[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/), [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/),
[StatefulSets](/docs/concepts/workloads/controllers/statefulset/), and [StatefulSets](/docs/concepts/workloads/controllers/statefulset/), and
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/) [DaemonSets](/docs/concepts/workloads/controllers/daemonset/)
@@ -33,8 +33,8 @@ in order to use it.
## API changes ## API changes
A new boolean field `suspend` is introduced in the Job spec API. Let's say I We introduced a new boolean field `suspend` into the `.spec` of Jobs. Let's say
create the following Job: I create the following Job:
```yaml ```yaml
apiVersion: batch/v1 apiVersion: batch/v1
@@ -55,17 +55,17 @@ spec:
``` ```
Jobs are not suspended by default, so I'm explicitly setting the `suspend` field Jobs are not suspended by default, so I'm explicitly setting the `suspend` field
to true in the above Job spec. In the above example, the Job controller will to _true_ in the `.spec` of the above Job manifest. In the above example, the
refrain from creating Pods until I'm ready to start the Job, which I can do by Job controller will refrain from creating Pods until I'm ready to start the Job,
updating the field to false. which I can do by updating `suspend` to false.
As another example, consider a Job that was created with the `suspend` field As another example, consider a Job that was created with the `suspend` field
omitted. The Job controller will happily create Pods to work towards Job omitted. The Job controller will happily create Pods to work towards Job
completion. However, before the Job completes, if I explicitly set the field to completion. However, before the Job completes, if I explicitly set the field to
true with a Job update, the Job controller will terminate all active Pods that true with a Job update, the Job controller will terminate all active Pods that
are running and will wait indefinitely for the flag to be flipped back to false. are running and will wait indefinitely for the flag to be flipped back to false.
Pod termination is done by sending a SIGTERM signal to all active Pods; the Typically, Pod termination is done by sending a SIGTERM signal to all container
[graceful termination period](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) processes in the Pod; the [graceful termination period](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
defined in the Pod spec will be honoured. Pods terminated this way will not be defined in the Pod spec will be honoured. Pods terminated this way will not be
counted as failures by the Job controller. counted as failures by the Job controller.
@@ -91,8 +91,8 @@ resources are cheaper at night than in the morning. If I have a long-running Job
that takes multiple days to complete, being able to suspend the Job in the that takes multiple days to complete, being able to suspend the Job in the
morning and then resume it in the evening every day can reduce costs. morning and then resume it in the evening every day can reduce costs.
Since this field is a part of the Job spec, CronJobs automatically get this Since this field is a part of the Job spec, [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/)
feature for free too. automatically get this feature for free too.
## References and next steps ## References and next steps
@@ -101,9 +101,9 @@ the decisions we have taken, consider reading the [enhancement proposal](https:/
There's more detail on suspending and resuming jobs in the documentation for [Job](/docs/concepts/workloads/controllers/job#suspending-a-job). There's more detail on suspending and resuming jobs in the documentation for [Job](/docs/concepts/workloads/controllers/job#suspending-a-job).
As previously mentioned, this feature is currently in alpha and is available As previously mentioned, this feature is currently in alpha and is available
only if you explicitly opt-in through the `SuspendJob` feature gate. If this is only if you explicitly opt-in through the `SuspendJob` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
a feature you're interested in, please consider testing suspended Jobs in your If this is a feature you're interested in, please consider testing suspended
cluster and providing feedback. You can discuss this enhancement [on GitHub](https://github.com/kubernetes/enhancements/issues/2232). Jobs in your cluster and providing feedback. You can discuss this enhancement [on GitHub](https://github.com/kubernetes/enhancements/issues/2232).
The SIG Apps community also [meets regularly](https://github.com/kubernetes/community/tree/master/sig-apps#meetings) The SIG Apps community also [meets regularly](https://github.com/kubernetes/community/tree/master/sig-apps#meetings)
and can be reached through [Slack or the mailing list](https://github.com/kubernetes/community/tree/master/sig-apps#contact). and can be reached through [Slack or the mailing list](https://github.com/kubernetes/community/tree/master/sig-apps#contact).
Barring any unexpected changes to the API, we intend to graduate the feature to Barring any unexpected changes to the API, we intend to graduate the feature to