Kubernetes of Job, CronJob Detailed

Job recent study Kubernetes met and CronJob, summarized here record it.

Job

Job controller is also an important resource controller Kubernetes in, but it and Deployment, different DaemonSet is: Job controller for the deployment of run-time objects pod task.

Task may run more than once in practice is over, the user can configure them to run in serial or parallel fashion.

Job Run

Summed up two operation modes: parallel and serial.

• Single work queue serial manner: i.e. a plurality of disposable jobs performed in the discharge serial tasks repeatedly, until a desired number of times to satisfy, may be understood as a degree of parallelism job execution mode, at a certain moment to the presence of a pod resources.
• Multiple parallel work queue: This mode of operation may be provided the number of tasks, the degree of parallelism. A plurality of queues each queue task can perform a task may be performed a plurality of queues each queue a plurality of tasks.

Create a sample to the following job description:

apiVersion: batch/v1
kind: Job
metadata:
  name: job-example
spec:
  template:
    spec:
      containers:
      - name: myjob
        image: nginx
        command: ["/bin/sh","-c", "sleep 120"]
        restartPolicy: Never

note:

• Job located in the API Group "batch / v1".
• spec.restartPolicy Pod template defaults to "Always", this does not apply for the Job Controller is concerned, it must be specified as Never or OnFailure.

The above-described example is a parallel type Job, set a value spec.parallelism and set the value of the total number of tasks of spec.completion. In the example above indicates two queues run, a total of 5 runs the task.

Job expansion

Spec.parallelism defined parallelism Job controller indicates the number of simultaneous objects running Pod adjusted runtime supports this attribute value to change the total number of its queue, to achieve expansion of volume reduction.

Use "Kubectl scale --replicas" command extension:

$ Kubectl scale jobs job-example --replicas=3

Job Delete

Job controller wait until after the end of execution, will not take up system resources. Users can delete resources on demand, but there are some Job Controller container can not end properly and restartPolicy and is defined as the restart, then it might have been in a restart state.

Job controller provides the following two ways to prevent such situation:

• spec.activeDealineSeconds: Job's DEADLINE, specifies the maximum length of events, beyond this length of time the job is terminated. .
• spec.backoffLimit: mark the job number of retries before failure state, the default value is 6.

spec: 
  backoffLimit: 5
  activeDealineSeconds: 100

Having said that Job, that CronJob and it has to do with it

CronJob

CronJob controller is used to manage run-time Job Controller resources.

Job controller defined job tasks can be executed immediately after creating its controller resources, but CronJob way the Linux operating system can do periodic tasks work plan (cronTab) is similar to the control point in time it runs and run repeatedly the way. It includes the following two:

• At some future point in time to run the job once.
• Repeat run the job at a specified point in time.

CronJob object creation

spec CronJob field controller can be nested following fields:

• jobTemplate: Job templates controller, for generating a Job object CronJob controller;
• schedule: Cron job scheduling run time point format;
• concurrencyPolicy: concurrent execution policy, the available values ​​are Allow (allowed), Forbid (prohibited) and Replace (replacement), for a job to run along the previously defined whether and when to run a job has not been completed;
• failedJobHistoryLimit: for the failure of task execution history to retain the number, the default is 1.
• successfulJobHistoryLimit: keep a history of successful execution of the task, the default is 3;
• startingDeadlineSeconds: CEO job because of the lack of time-out errors starting point of time due to job and will be credited to the error history for various reasons;
• suspend: whether to suspend the implementation of the follow-up task, the default is false, it will not affect the operations of the task;

Illustrated by the following CronJob:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: Cronjob-example
  labels:
    app: mycronjob
spec:
  schedule: "*/2 * * * *"
  jobTemplate:
    metadata:
      labels:
        app: mycronjob-jobs
    spec:
      parallelism: 2
      template:
        spec;
          containers:
          - name: myjob
            image: nginx
            command: ["/bin/sh","-c", "sleep 120"]
            restartPolicy: OnFailure

The example creates a run once every two minutes CronJob simple task.

CronJob control mechanisms

CronJob with a high level of resources, which is based Job controller resources to control objects and help it manage Pod resource objects.

If you repeat a specified time-intensive job ,, and job execution time and relatively long, the case of two Job objects exist appears. Some Job object may not exist or circumstances that can not run at the same time, the mechanism will work co-exist at this time is controlled by spec.concurrencyPolicy property, it defaults to "Allow", before and after allowing Job Job even belong to the same CronJob at the same time run. Two other available values, "foebid" before and after the ban for two job running simultaneously, "Replace" is used in place of the previous one make a.

Reference books "Kubernetes Advanced real"
personal github account: https://github.com/SpecialAll