Shulou(Shulou.com)06/02 Report--

Job resource object

Pod container of service class: RC, RS, DS, Deployment

The Pod container of the work class: Job--- > execute once, or execute the handler in batch, and exit the container when you are finished.

Note: if the task is executed incorrectly in the container, the container will be operated according to the container's restart policy, but here

The container restart strategy can only be: Never and OnFailure.

Concept

In some scenarios, you want to run containers to perform a specific task, and once the task is completed, there is no need for the container to exist. In this scenario, it is not appropriate to create a pod. So that's it. Job,Job means those one-time tasks. Run a container through Job, and when its task is finished, it automatically exits, and the cluster does not wake it up again.

From the running mode of the program, Pod can be divided into two categories: long-running services (jboss, mysql, etc.) and one-time tasks (data calculation, testing). The Pod created by RC is a long-running service. Job is mostly used to execute one-time tasks, batch work, and so on, which will be stopped after execution (status.phase becomes Succeeded).

Environment introduction host IP address service master192.168.1.21k8snode01192.168.1.22k8snode02192.168.1.23k8s

The experiment based on [https://blog.51cto.com/14320361/2464655]()] continues

1. Kubernetes supports the following types of job non-parallel job: usually a pod is created until it finishes successfully. Job with a fixed number of terminations: set the spec.completions and create multiple pod until the .spec.completions pod ends successfully. Parallel job with work queues: set .spec.Parallelism but not .spec.completions, and job is considered successful when all pod ends and at least one is successful. Job Controller

Job Controller is responsible for creating the pod based on the Job Spec and continuously monitoring the status of the pod until its successful completion. If it fails, it decides whether to create a new pod and retry the task based on the restartPolicy (only OnFailure and Never are supported, not Always).

Example (1) write a yaml file of job [root@master yaml] # vim jop.yamlkind: JobapiVersion: name: test-jobspec: template: metadata: name: test-jobspec: containers:-name: hello image: busybox command: ["echo", "hello k8s job!"] RestartPolicy: Never (2) execute [root@master yaml] # kubectl apply-f jop.yaml (3) check [root@master yaml] # kubectl get pod

View log [root@master yaml] # kubectl logs test-job-gs45w

We can see that job is different from other resource objects in that it only executes one-time tasks. By default, job ends after pod is run, and the status is Completed.

(4) modify the yaml file of jop Replace the echo command with garbled [root@master yaml] # vim jop.yamlkind: JobapiVersion: batch/v1metadata: name: test-jobspec: template: metadata: name: test-jobspec: containers:-name: hello image: busybox command: ["asdasxsddwefew" "hello K8s job!"] # modify restartPolicy: Never (5) delete the previous pod [root@master yaml] # kubectl delete jobs.batch test-job (6) execute [root@master yaml] # kubectl apply-f jop.yaml (7) check [root@master yaml] # kubectl get pod-w

It creates the pod until the command is completed.

(8) modify the yaml file of jop and modify the restart policy [root@master yaml] # vim jop.yaml kind: JobapiVersion: batch/v1metadata: name: test-jobspec: template: metadata: name: test-jobspec: containers:-name: hello image: busybox command: ["asdasxsddwefew", "hello k8s job!"] RestartPolicy: OnFailure (9) first delete the previous pod [root@master yaml] # kubectl delete jobs.batch test-job (10) execute [root@master yaml] # kubectl apply-f jop.yaml (11) check [root@master yaml] # kubectl get pod-w

It restarts the pod to complete the command until it restarts a certain number of times and then deletes the job.

Second, improve the implementation efficiency of Job 1. We can add the [parallelism] () option under the Job.spec field. Indicates how many Pod execution tasks are running at the same time. (1) write a yaml file of job [root@master yaml] # vim jop.yamlkind: JobapiVersion: batch/v1metadata: name: test-jobspec: parallelism: 2 # enable several pod template: metadata: name: test-jobspec: containers:-name: hello image: busybox command: ["echo", "hello k8s job!"] RestartPolicy: OnFailure (3) execute [root@master yaml] # kubectl apply-f jop.yaml (4) check [root@master yaml] # kubectl get pod

View the log

two。 We can add the complations option under the Job.spec field. Indicates the total number of Pod that needs to be completed (1) write a job yaml file [root@master yaml] # vim jop.yamlkind: JobapiVersion: batch/v1metadata: name: test-jobspec: complations: 8 # Total number of parallelism: 2 # running pod 8 parallelism: 2 # run 2 pod template: metadata: name: test-jobspec: containers:-name: hello image : busybox command: ["echo" "hello K8s job!"] RestartPolicy: OnFailure

The job field explains:

Completions: the number of Pod that needs to be run successfully to mark the end of Job. Default is 1.

Parallelism: indicates the number of Pod running in parallel. Default is 1.

ActiveDeadlineSeconds: marks the maximum time for a failed Pod to retry, after which no retry will be made.

(2) delete the previous pod [root@master yaml] # kubectl delete jobs.batch test-job (3) execute [root@master yaml] # kubectl apply-f jop.yaml (4) check [root@master yaml] # kubectl get pod

You can see that the pod is started by two.

3. How to execute Job regularly (1) write a yaml file of cronjob [root@master yaml] # vim cronjop.yamlkind: CronJobapiVersion: batch/v1beta1metadata: name: hellospec: schedule: "* / 1 *" # limit time jobTemplate: spec: template: spec: containers:-name: hello image: busybox command: ["echo", "hello" "cronjob"] restartPolicy: OnFailure (2) delete the previous pod [root@master yaml] # kubectl delete jobs.batch test-job (3) execute [root@master yaml] # kubectl apply-f jop.yaml (4) check [root@master yaml] # kubectl get pod

[root@master yaml] # kubectl get cronjobs.batch

If you look at the status of Pod at this point, you will find that every minute a new Pod is run to perform whatever is specified in the command.

Business.

Exercise: specify 2020.1.15.10.5 to run the crontab task above. (1) write a yaml file of cronjob [root@master yaml] # vim cronjop.yamlkind: CronJobapiVersion: batch/v1beta1metadata: name: hellospec: schedule: "5 10 15 1 *" # time limit jobTemplate: spec: template: spec: containers:-name: busybox command: ["echo", "hello" "cronjob"] restartPolicy: OnFailure (2) delete the previous pod [root@master yaml] # kubectl delete cronjobs.batch hello (3) execute [root@master yaml] # kubectl apply-f jop.yaml (4) check [root@master yaml] # kubectl get pod

At this point, you will find that if you specify a specific time, the task may not be carried out.

(5) add apiVersion library [root@master yaml] # vim / etc/kubernetes/manifests/kube-apiserver.yaml spec: containers:-command:-kube-apiserver-runtime-config=batch/v2alpha1=true # add

(6) restart kubelet [root@master yaml] # systemctl restart kubelet.service (7) View api version [root@master yaml] # kubectl api-versions

(8) write a yaml file of cronjob [root@master yaml] # vim cronjop.yamlkind: CronJobapiVersion: batch/v1beta1metadata: name: hellospec: schedule: "47 10 15 1 *" # time limit jobTemplate: spec: template: spec: containers:-name: busybox command: ["echo", "hello" "cronjob"] restartPolicy: OnFailure (9) execute [root@master yaml] # kubectl apply-f jop.yaml (4) check [root@master yaml] # kubectl get pod-w

Note: the specified time Job still cannot be run properly at this time, because the official K8s has not improved this feature in the support of cronjob as a resource object and has yet to be developed.

Concurrent Job parameters are also supported under cronjob.spec.jobTemplate.spec like Job resources:

Parallelism, also supports the total number of completed Pod parameters: completionsr

Summary

As a resource used to process tasks in Kubernetes, Job is not much different from other resources. It also uses the controller mode common in Kubernetes to listen for events in Informer and run syncHandler synchronization tasks.

Because of the particularity of its function, CronJob takes resources out of apiserver every 10 seconds and checks whether scheduling should be triggered to create new resources. It should be noted that CronJob cannot guarantee execution at an accurate target time, and execution will lag to a certain extent.

The implementation of the two controllers is relatively clear, but there are many boundary conditions, so we must pay more attention to it when analyzing its implementation principle.

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.