:Kubernetes jobs

After you complete the configuration, you can click Run once in the Actions column of the Kubernetes job on the Task Management page. Then, a pod named schedulerx-shell-{JobId} is started in the desired cluster, as shown in the following figure.

You can go to the Task Management page and click Historical records in the Actions column of the Kubernetes job to view the operational logs of the pod.

After you complete the configuration, you can click Run once in the Actions column of the Kubernetes job on the Task Management page. Then, a pod named schedulerx-python-{JobId} is started in the desired cluster, as shown in the following figure.

You can go to the Task Management page and click Historical records in the Actions column of the Kubernetes job to view the operational logs of the pod.

After you complete the configuration, you can click Run once in the Actions column of the Kubernetes job on the Task Management page. Then, a pod named schedulerx-php-{JobId} is started in the desired cluster, as shown in the following figure.

You can go to the Task Management page and click Historical records in the Actions column of the Kubernetes job to view the operational logs of the pod.

After you complete the configuration, you can click Run once in the Actions column of the Kubernetes job on the Task Management page. Then, a pod named schedulerx-node-{JobId} is started in the desired cluster, as shown in the following figure.

You can go to the Task Management page and click Historical records in the Actions column of the Kubernetes job to view the operational logs of the pod.

After you complete the configuration, you can click Run once in the Actions column of the Kubernetes job on the Task Management page. Then, a pod and the job are started in the desired cluster, as shown in the following figure.

You can go to the Task Management page and click Historical records in the Actions column of the Kubernetes job to view the operational logs of the pod.

After you complete the configuration, you can click Run once in the Actions column of the Kubernetes job on the Task Management page. Then, the native Kubernetes pod is started in the desired Kubernetes cluster, as shown in the following figure.

You can go to the Task Management page and click Historical records in the Actions column of the Kubernetes job to view the operational logs of the pod.

Obtain job parameters based on environment variables

SchedulerX supports job parameters preconfigured in environment variables. In this case, regardless of whether it is a script job, a pod, or a native Kubernetes job, SchedulerX can read the job parameters from the environment variables, which simplifies job creation.

The following figure shows the sample job parameters read by SchedulerX.

Benefits

Compared with the native Kubernetes jobs, Kubernetes jobs created by using SchedulerX provide the following benefits:

Online script editing

In most cases, Kubernetes jobs are script jobs used for data processing and O&M. The native Kubernetes jobs require you to package scripts into images and to configure script commands in YAML files. Therefore, each time you want to modify a script, you must rebuild and release your image, which is a tedious process. Example:

apiVersion: batch/v1
kind: Job
metadata:
  name: hello
spec:
  template:
    spec:
      containers:
      - name: hello
        image: busybox
        command: ["sh",  "/root/hello.sh"]
      restartPolicy: Never
  backoffLimit: 4

If you use SchedulerX to manage Kubernetes jobs, you do not need to rebuild images or compile scripts in YAML files. The SchedulerX console supports online editing of scripts in Shell, Python, PHP, and Node.js programming languages. After your editing, SchedulerX automatically runs the new version of scripts in pod mode. If you want to update scripts, you need only to modify the scripts and save the modifications in the SchedulerX console. Next time SchedulerX schedules Kubernetes jobs, the modifications automatically take effect. This greatly improves the development and management efficiency of Kubernetes jobs. In addition, the Kubernetes job feature provided by SchedulerX completely hides container details. For developers who are unfamiliar with container services, this feature undoubtedly improves the development efficiency and brings great convenience.

Example:

Visual job orchestration

In the Kubernetes ecosystem, Argo is a popular workflow orchestration tool. Example:

# The following workflow executes a diamond workflow
# 
#   A
#  / \
# B   C
#  \ /
#   D
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: dag-diamond-
spec:
  entrypoint: diamond
  templates:
  - name: diamond
    dag:
      tasks:
      - name: A
        template: echo
        arguments:
          parameters: [{name: message, value: A}]
      - name: B
        depends: "A"
        template: echo
        arguments:
          parameters: [{name: message, value: B}]
      - name: C
        depends: "A"
        template: echo
        arguments:
          parameters: [{name: message, value: C}]
      - name: D
        depends: "B && C"
        template: echo
        arguments:
          parameters: [{name: message, value: D}]

  - name: echo
    inputs:
      parameters:
      - name: message
    container:
      image: alpine:3.7
      command: [echo, "{{inputs.parameters.message}}"]

The workflow feature of SchedulerX provides an intuitive visual interface for you to effectively orchestrate Kubernetes jobs by drags and drops, as shown in the following figure.

Compared with Argo, SchedulerX provides better user experience. It is easier to use and visualizes job workflows. This helps you easily track the job progress and locate steps in which jobs are blocked and troubleshoot issues, as shown in the following figure.

Alerting and monitoring

If you use SchedulerX to schedule your pods and jobs, you can fully utilize the built-in altering and monitoring mechanism. This enables effective tracking of job status and alerting of exceptions.

• SchedulerX supports the following alert notification methods: text message, phone call, email, and WebHook (DingTalk, WeCom, and Lark).

• SchedulerX supports the following alert policies: alert upon failure and alert upon execution timeout.

Logging

If you use SchedulerX to schedule your pods and jobs, you do not need to additionally activate log services such as Simple Log Service. SchedulerX automatically collects the operational logs of pods. Once a pod fails to run, you can go to the SchedulerX console to view and analyze the failure details and effectively troubleshoot issues and debug the pod.

Monitoring dashboard

If you use SchedulerX to schedule your pods and jobs, you can view the built-in job monitoring features without the need to additionally activate Managed Service for Prometheus.

Mixed deployment of online and offline jobs

If you have online scheduled jobs that require high real-time performance, such as order processing jobs, you can call methods in the same process as other online jobs to effectively process the jobs. This ensures seamless integration of online scheduled jobs into online business. If you have offline scheduled jobs that require low real-time performance but consume a lot of resources, such as financial report generation jobs, you can compile scripts and start separate pods to run the jobs. SchedulerX supports Java and Kubernetes jobs and enables the mixed deployment and scheduling of online and offline jobs, which provides flexible solutions that meet diverse business requirements.