All Products
Search
Document Center

Microservices Engine:Kubernetes job

Last Updated:Jul 17, 2026

Install the SchedulerX agent in Kubernetes to schedule native Pods and Jobs. SchedulerX provides status monitoring, alerting, log collection, and diagnostics for your jobs.

How it works

The following diagram shows how SchedulerX schedules a Kubernetes job:

image

The following table compares Kubernetes jobs and script jobs.

Scenario

Script job

Kubernetes job

Infrequent execution with high resource consumption.

Not recommended. Forking a child process for each run consumes resources on the agent's machine and can overload the system.

Recommended. Kubernetes uses its load balancing strategy to launch a new Pod for each run, ensuring high stability.

Frequent execution with low resource consumption.

Recommended. Forking a child process is fast and resource-efficient.

Not recommended. Pulling an image and starting a Pod for each run is slow. Frequent API server calls to schedule Pods or Jobs can lead to rate limiting.

How to build dependencies.

Manually deploy dependencies to ECS instances in advance.

Build dependencies into a base image. You must rebuild the base image if dependencies change.

Prerequisites

Connect to SchedulerX. For more information, see Deploy SchedulerX in a Kubernetes cluster.

Create a Kubernetes job

Shell script

To run a shell script in a Pod without building your own image, create a Kubernetes job on the Tasks page and select Shell-Script as the resource type. The default image is BusyBox, which you can replace with your own.

Example configuration: Set Task type to K8s and resource type to Shell-Script. The default Image is BusyBox. Enter your shell script content, such as echo hello schedulerx, in the script editor.

Click Run once. A Pod named schedulerx-shell-{JobId} starts in the Kubernetes cluster.

$ kubectl get pods
NAME                          READY   STATUS    RESTARTS   AGE
schedulerx-shell-xxx          1/1     Running   0          xxx

On the Task Management page in the SchedulerX console, you can view the execution history and Pod logs. The log output area displays the script's result, such as hello schedulerx, along with the execution time and status.

Python script

To run a Python script in a Pod without building your own image, create a Kubernetes job on the Tasks page and select Python-Script as the resource type. The default image is python, which you can replace with your own.

Example configuration: Set Task type to K8s and resource type to Python-Script. The default Image is python. Enter your Python script content, such as print('hello schedulerx'), in the script editor.

Click Run once. A Pod named schedulerx-python-{JobId} starts in the Kubernetes cluster.

$ kubectl get pods
NAME                            READY   STATUS    RESTARTS   AGE
schedulerx-python-xxx           1/1     Running   0          xxx

On the Task Management page in the SchedulerX console, you can view the execution history and Pod logs. The procedure is the same as for shell scripts. The log output area displays the script's result.

PHP script

To run a PHP script in a Pod without building your own image, create a Kubernetes job on the Tasks page and select Php-Script as the resource type. The default image is php:7.4-cli, which you can replace with your own.

Example configuration: Set Task type to K8s and resource type to Php-Script. The default Image is php:7.4-cli. Enter your PHP script content in the script editor.

Click Run once. A Pod named schedulerx-php-{JobId} starts in the Kubernetes cluster.

$ kubectl get pods
NAME                         READY   STATUS    RESTARTS   AGE
schedulerx-php-xxx           1/1     Running   0          xxx

On the Task Management page in the SchedulerX console, you can view the execution history and Pod logs. The procedure is the same as for shell scripts. The log output area displays the script's result.

Node.js script

To run a Node.js script in a Pod without building your own image, create a Kubernetes job on the Tasks page and select Node.js-Script as the resource type. The default image is node:16, which you can replace with your own.

Example configuration: Set Task type to K8s and resource type to Node.js-Script. The default Image is node:16. Enter your Node.js script content, such as console.log('hello schedulerx'), in the script editor.

Click Run once. A Pod named schedulerx-node-{JobId} starts in the Kubernetes cluster.

$ kubectl get pods
NAME                          READY   STATUS    RESTARTS   AGE
schedulerx-node-xxx           1/1     Running   0          xxx

On the Task Management page in the SchedulerX console, you can view the execution history and Pod logs. The procedure is the same as for shell scripts. The log output area displays the script's result.

Job-YAML

You can also use SchedulerX to run a native Kubernetes Job. Set the task type to K8s and the resource type to Job-YAML.

Example configuration: Set Task type to K8s and resource type to Job-YAML. Enter the standard Kubernetes Job definition in the YAML editor, including fields such as apiVersion, kind, metadata, and spec.

Click Run once. The Job and its associated Pod start in the Kubernetes cluster.

$ kubectl get jobs
NAME                COMPLETIONS   DURATION   AGE
schedulerx-xxx      1/1           xxx        xxx

$ kubectl get pods
NAME                     READY   STATUS      RESTARTS   AGE
schedulerx-xxx           0/1     Completed   0          xxx

On the Task Management page in the SchedulerX console, you can view the execution history and Pod logs. The log output area displays the Job's result, execution time, and status.

Important

When running a Kubernetes Job with SchedulerX, we recommend against using a CronJob. Instead, configure the schedule in SchedulerX to ensure that it collects the execution history and logs for each Pod.

Pod-YAML

You can also use SchedulerX to run a native Kubernetes Pod. Set the task type to K8s and the resource type to Pod-YAML.

Example configuration: Set Task type to K8s and resource type to Pod-YAML. Enter the standard Kubernetes Pod definition in the YAML editor, including fields such as apiVersion, kind, metadata, and spec.

Click Run once. The Pod starts in the Kubernetes cluster.

$ kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
schedulerx-xxx              1/1     Running   0          xxx

On the Task Management page in the SchedulerX console, you can view the execution history and Pod logs. The log output area displays the Pod's result, execution time, and status.

Important

When you use SchedulerX to run a Kubernetes Pod, we recommend that you do not run long-lived Pods, such as those for web applications that never terminate. You must set the restart policy to Never. Otherwise, the Pod will restart continuously.

Job parameters from environment variables

SchedulerX injects job parameters as environment variables. Scripts, Pods, and Jobs can read these parameters directly from the environment.

Note

This feature requires SchedulerX agent version 1.10.14 or later.

Parameter

Description

SCHEDULERX_JOB_NAME

The name of the job.

SCHEDULERX_SCHEDULE_TIMESTAMP

The job's scheduling timestamp.

SCHEDULERX_DATA_TIMESTAMP

The data timestamp for the job.

SCHEDULERX_WORKFLOW_INSTANCE_ID

The ID of the workflow instance, if the job is part of a workflow.

SCHEDULERX_JOB_PARAMETERS

The job parameters.

SCHEDULERX_INSTANCE_PARAMETERS

The instance parameters of the job.

SCHEDULERX_JOB_SHARDING_PARAMETER

The sharding parameters, if the job is a sharded job.

The following example retrieves a SchedulerX job parameter:

Example: Enter a value in the Job Parameters field in the job configuration. In your script, you can then read the SCHEDULERX_JOB_PARAMETERS environment variable to access this value. For example, a shell script can use echo $SCHEDULERX_JOB_PARAMETERS to print the parameter.

Advantages

Scheduling a Kubernetes Job with SchedulerX offers the following advantages over native Kubernetes Jobs:

Online script editing

Kubernetes Jobs are commonly used for data processing or operations tasks implemented as scripts. Natively, you must package each script into an image and configure the command in a YAML file, rebuilding and redeploying the image for every change. For 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

SchedulerX eliminates the need to build images or write YAML for scripts. You can edit Shell, Python, PHP, and Node.js scripts directly in the console, and the system runs them in a Pod automatically. Updates take effect at the next scheduled run.

For example:

On the job editing page in the SchedulerX console, you can write and modify script content directly in the script editor. After you finish, click Save. The latest version of the script will automatically run at the next scheduled time.

Visual job orchestration

In the Kubernetes ecosystem, Argo is a popular solution for workflow orchestration. For 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}}"]

SchedulerX lets you visually orchestrate Kubernetes Jobs by using a drag-and-drop interface.

Compared to Argo, SchedulerX provides a visual workflow graph at runtime that tracks job progress, making it easy to identify bottlenecks or failures.

In the workflow instance view, each task node is color-coded by its status (for example, green for success and red for failure), allowing you to visually pinpoint the failure.

Monitoring and alerting

SchedulerX includes built-in monitoring and alerting for Pods and Jobs.

  • Supported alert channels: SMS, phone call, email, and webhook (for DingTalk, WeCom, and Lark).

  • Supported alert policies: alert on failure and alert on execution timeout.

Log service

SchedulerX automatically collects logs from Pod execution without requiring a separate log service. If a Pod fails, you can view the failure reason in the SchedulerX console for quick troubleshooting.

Task instance details include complete Pod execution logs with stack traces and failure reasons.

Monitoring dashboard

SchedulerX provides a built-in job monitoring dashboard, eliminating the need to set up Prometheus or a similar service.

The dashboard displays key metrics such as job execution counts, success and failure rates, and execution duration trends.

Mixed job deployment

SchedulerX supports both Java and Kubernetes job types for mixed deployment. Use in-process method invocation for latency-sensitive online jobs such as order processing, and run resource-intensive offline jobs such as report exports as scripts in separate Pods.