Shulou(Shulou.com)05/31 Report--

This article will explain in detail the example analysis of the introduction of the suspension feature of Kubernetes version 1.21. The editor thinks it is very practical, so I share it with you for reference. I hope you can get something after reading this article.

Job (homework) is an important part of Kubernetes API. While other types of workloads (such as Deployment, ReplicaSet, StatefulSet, and DaemonSet) address use cases that require Pod to run forever, Job is useful when Pod needs to run to completion. Job is typically used for parallel batch processing and can be used in a variety of applications, from video rendering and database maintenance to sending batch emails and scientific computing.

Although parallelism and conditions for Job completion are configurable, Kubernetes API lacks the ability to suspend and resume Job. This is usually required when the cluster resources are limited and a higher priority Job needs to be executed at another Job location. Deleting the lower priority Job is a bad solution because the Pod completion history and other Job-related metrics will be lost.

In the most recent version of Kubernetes 1.21, you can pause Job by updating its specification. This feature is currently in the alpha phase and requires you to enable the suspend Job feature gate on the API server and controller manager to use it.

Changes in API

We have introduced a new Boolean field suspend into the. spec of Job. Suppose I created the following job:

ApiVersion: batch/v1

Kind: Job

Metadata:

Name: my-job

Spec:

Suspend: true

Parallelism: 2

Completions: 10

Template:

Spec:

Containers:

-name: my-container

Image: busybox

Command: ["sleep", "5"]

RestartPolicy: Never

Job is not paused by default, so I explicitly set the suspend field to true in the .spec of the above Job listing. In the above example, the Job controller will not create the Pod until I am ready to start the Job, which I can do by updating the suspend to false.

As another example, consider a Job that is created with the suspend field omitted. The Job controller will happily create the Pod to complete the Job. However, before the Job is complete, if I explicitly set this field to the true,Job controller through the Job update, I will terminate all running active Pod and wait indefinitely for the flag to be set back to false. Typically, Pod termination is accomplished by sending SIGTERM signals to all container processes in Pod; the elegant termination period [1] defined in the Pod specification will be observed. A Pod terminated in this way will not be considered a failure by the Job controller.

It is important to understand that after you pause Job, past successes and failures of Pod will continue to exist. That is, once you restart Job, they will be counted as part of the Job completion. You can verify this by looking at the status of Job before and after the pause.

Where does this work?

Suppose I am an operator of a large cluster. I have a lot of users who submit Job to the cluster, but not all Job are equal-some Job are more important than others. Cluster resources are not unlimited, so all users must share resources. If all the Job were created in a paused state and placed in a paused queue, I could achieve priority-based Job scheduling by restoring the Job in the correct order.

As another motivational use case, consider a cloud provider whose computing resources are cheaper at night than in the morning. If I have a long-running Job that takes several days to complete, I can pause Job in the morning and resume it in the evening, which reduces costs.

Because this field is part of the Job specification, CronJobs also automatically acquires this feature.

Quotation and next step

If you are interested in learning more about the rationale behind this feature and the decisions we have made, please consider reading the enhancement recommendations [4]. There are more details on pausing and resuming Job in the Job documentation.

As mentioned earlier, this feature is currently in the alpha phase and is available only if it is explicitly selected to join through the SuspendJob feature gate. If this is a feature you are interested in, consider testing the pause feature in the cluster and providing feedback. You can discuss this enhancement on GitHub [5]. The SIG Apps community also meets regularly [6] and can participate through Slack or mailing lists. Unless there are any unexpected changes in API, we plan to upgrade this feature to a beta version in Kubernetes 1.22 so that it can be used by default.

This is the end of this article on the "sample analysis of the introduction of suspended jobs in Kubernetes version 1.21". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it out for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.