This section describes how to create a Job.

Prerequisites

You need to join a cluster and have the Application Workload Management permission in the cluster. For more information, see Cluster Members and Cluster Roles.

Steps

Refer to Parameter Description to set the Job parameters.

  1. Log in to the KubeSphere web console with a user who has Application Workload Management permissions and enter your cluster.

  2. Click Application Workloads > Jobs or CronJobs in the left navigation pane.

  3. Click Create on the page.

  4. On the Basic Information tab, set the basic information and scheduling policy for the Job, then click Next.

  5. On the Policy Settings tab, set the policy for a single Job, then click Next.

  6. On the Pod Settings tab, set the restart policy and containers for the pods managed by the Job, then click Next.

  7. On the Storage Settings tab, mount volumes for the containers managed by the Job, then click Next.

  8. On the Advanced Settings tab, specify nodes for the pods managed by the Job, and set the metadata for the Job, then click Create. Once created, the Job will appear in the Job list.

Parameter Description

The following describes how to set the Job parameters.

  • Basic Information

    Parameter Description

    Name

    The name of the Job. The name can only contain lowercase letters, numbers, and hyphens (-), must start and end with a lowercase letter or number, with a maximum length of 63 characters.

    Alias

    The alias of the Job. Different Jobs can have the same alias.

    Project

    The project to which the Job belongs. System projects are typically used for managing system resources. It is recommended to select a user project.

    Description

    The description of the Job. The description can contain any characters, with a maximum length of 256 characters.

    Schedule

    The CRON expression for the run cycle of the CronJob. KubeSphere uses UTC time by default. You need to adjust it according to your time zone. Only available for CronJobs.

    Starting Deadline

    The maximum delay time for starting the Job when it fails to start as scheduled due to some reason. Only available for CronJobs.

    Successful Jobs History Limit

    The number of successful Jobs allowed to be retained, with a default value of 3. Each run of a CronJob creates a Job. You can specify to retain a certain number of Jobs as historical records. Only available for CronJobs.

    Failed Jobs History Limit

    The number of failed Jobs allowed to be retained, with a default value of 1. Each run of a CronJob creates a Job. You can specify to retain a certain number of Jobs as historical records. Only available for CronJobs.

    Concurrency Policy

    The strategy the system adopts when multiple Jobs created by a CronJob overlap. Only available for CronJobs. Includes the following policy types:

    • Allow: New Jobs and old Jobs run concurrently.

    • Forbid: New Jobs are not run.

    • Replace: Old Jobs are terminated immediately and then new Jobs are run.

  • Policy Settings

    Configure the policy for each run of the Job.

    Parameter Description

    Max Retries

    The maximum number of times a pod in the Job can be restarted. If the maximum retry count is reached without meeting the Job completion conditions, the Job will be marked as failed.

    Completions

    The number of successfully completed pods required to mark the Job as complete.

    Parallelism

    The number of pod replicas running in parallel within the Job.

    Active Deadline Seconds

    The maximum running time for the Job, in seconds. If the maximum running time is reached without meeting the Job completion conditions, the Job will be terminated and marked as failed.

    • Pod Settings > Restart Policy

    Set the policy for the system to take when a container fails.

Parameter Description

Recreate Pod

The system will recreate the entire pod.

Restart Container

The system will restart the container.

  • Pod Settings > Add Container

Create containers to run in the pod. You can create multiple containers in a pod.

  • Click Add Container to create a container.

  • Hover over a created container, then click pen on the right to edit the container’s settings.

  • Hover over a created container, then click trash-light on the right to delete the container.

  • Pod Settings > Add Container > Container Settings

Set the image, name, type, and resources for the container.

Parameter Description

Image

The image required to create the container.

  • Enter the name (e.g., nginx:latest) or path (e.g., docker.io/nginx:latest) of the image, then press Enter to search for the image.

  • If you only enter the image name, it will be pulled from Docker Hub by default. To use a private image service, you need to create a Secret containing the private image service information, then select the private image service from the left side of the Image text box.

  • Click template to browse images in the current image service.

Container Name

The name of the container. The name can only contain lowercase letters, numbers, and hyphens (-), must start and end with a lowercase letter or number, and can be up to 63 characters long.

Container Type

The type of container.

  • Init Container: A container that performs initialization work for the main application container. The main application container will only start after all init containers have completed successfully. If an init container fails, the system will set the pod’s status to failed.

  • Main Container: The container that runs the application. It is generally recommended to run only one main container per pod.

CPU Reservation

CPU resources reserved for the container, in cores.

CPU Limit

The maximum CPU resources allowed for the container, in cores.

Memory Reservation

Memory resources reserved for the container, in MiB.

Memory Limit

The maximum memory resources allowed for the container, in MiB.

GPU Type

The type of GPU allowed for the container.

GPU Limit

The maximum number of GPUs allowed for the container, in GPUs.

  • Pod Settings > Add Container > Port Settings

Set the container port. Click Use Default Image Port to set the container port to the default port of the image. Click Add Port to set multiple ports for the container.

Parameter Description

Protocol

The actual protocol that the application in the container listens on. To use the application governance features provided by KubeSphere, ensure that the protocol selected here is consistent with the actual protocol that the application in the container listens on.

Name

The name of the port. To use the application governance features provided by KubeSphere, use the lowercase protocol name as the prefix of the port name (e.g., http-).

Container Port

The actual port number that the application in the container listens on.

  • Pod Settings > Add Container > Image Pull Policy

Configure whether to pull images from the image service when creating or updating a pod.

Parameter Description

Prefer Local Image

When creating or updating a pod, prioritize using the image files stored on the node by the container runtime.

Always Pull Image

When creating or updating a pod, always attempt to pull the image from the image service.

Use Local Image Only

When creating or updating a pod, use only the images stored on the node by the container runtime. If the required image does not exist locally, pod creation will fail.

  • Pod Settings > Add Container > Health Check

Check the health status of containers. Before using this feature, you need to configure your container’s application to return health check results.

KubeSphere supports the following health check types:

Parameter Description

Liveness Probe

Checks if the container is alive. If the liveness probe fails, the system will attempt to restart the container.

Readiness Probe

Checks if the container is ready. If the readiness probe fails, the system will prevent access to the pod where the container resides via services.

Startup Probe

Checks if the container has started. If the startup probe fails, the system will disable other probes for the container and attempt to restart the container.

KubeSphere supports the following check methods:

Parameter Description

HTTP Request

Sends an HTTP GET request to the pod’s virtual IP address. The check is successful if the response status code is 2XX or 3XX.

Command

Runs a command inside the container. The check is successful if the command’s exit code is 0.

TCP Port

Attempts to establish a TCP connection to the specified container port. The check is successful if the connection is established.

  • Pod Settings > Add Container > Health Check > Add Probe

Create probes to perform liveness, readiness, or startup checks on containers.

  • Click Add Probe to create a probe.

  • Hover over a created probe, then click pen on the right to edit the probe’s settings.

  • Hover over a created probe, then click trash-light on the right to delete the probe.

Parameter Description

Path

The protocol (HTTP or HTTPS) for the HTTP request, the path of the request target relative to the pod’s virtual IP address, and the port number for the request. Available only when the health check method is HTTP Request.

Command

The command to be executed inside the container. You can use commas (,) to separate the command and its arguments. Available only when the health check method is Command.

Port

The container port number for TCP checks. Available only when the health check method is TCP Port.

Initial Delay

The delay time, in seconds, after the container starts before the probe is initiated.

Timeout

The probe timeout period, in seconds. After the probe times out, the check is considered a failure. The value must be an integer, with a minimum value of 0.

Check Interval

The time interval, in seconds, between check executions. The value must be an integer, with a minimum value of 1.

Success Threshold

The minimum number of consecutive successful checks required after a failure for the check to be considered successful again. The minimum value is 1. For liveness and startup probes, this value must be 1.

Failure Threshold

The minimum number of consecutive failed checks required after a success for the check to be considered failed again. The minimum value is 1.

  • Pod Settings > Add Container > Lifecycle Management

Set the actions that need to be executed after a container starts or before it terminates, for environment checks or graceful termination. Before using this feature, you need to configure your container’s application so that it can return the execution result of the action.

Parameter Description

Post-start Action

The action to be executed after the container starts. If this action fails, the system will attempt to restart the container.

Pre-stop Action

The action to be executed before the container terminates. This action follows these rules:

  • If the pre-stop action fails, the system will terminate the container immediately.

  • The default value for the container’s graceful termination period is 30s. If the pre-stop action is still executing when the graceful termination period is reached, the system will provide a one-time grace period of 2s.

  • After the grace period ends, regardless of whether the pre-stop action has finished executing, the system will terminate the container.

KubeSphere supports the following execution methods for post-start and pre-stop actions:

Parameter Description

HTTP Request

Send an HTTP GET request to the pod’s virtual IP address. If the response status code is 2XX or 3XX, the action is considered successful.

Command

Run a command inside the container. If the command’s exit code is 0, the action is considered successful.

TCP Port

Attempt to establish a TCP connection to the specified container port. If the connection is successfully established, the action is considered successful.

  • Pod Settings > Add Container > Lifecycle Management > Add Action

Create post-start or pre-stop actions for containers.

  • Click Add Action to create an action.

  • Hover over a created action, then click pen on the right to edit the action’s settings.

  • Hover over a created action, then click trash-light on the right to delete the action.

Parameter Description

Path

The protocol (HTTP or HTTPS), the path of the request target relative to the pod’s virtual IP address, and the port number for the HTTP request. Available only when the action execution method is HTTP Request.

Command

The command to be run inside the container. You can use commas (,) to separate the command and its arguments. Available only when the action execution method is Command.

Port

The container port number for TCP checks. Available only when the action execution method is TCP Port.

  • Pod Settings > Add Container > Startup Command

Set the command to be executed inside the container when it starts.

Parameter Description

Command

The name of the command to be executed.

Arguments

The arguments for the command to be executed. You can use commas (,) to separate multiple arguments.

  • Pod Settings > Add Container > Environment Variables

Set environment variables for the container.

  • Click Add Environment Variable to set multiple environment variables.

  • Click Batch Reference to create environment variables using data from a ConfigMap or Secret. The ConfigMap or Secret must belong to the same project as the container to be referenced by the container. After the container is created, the values of the environment variables will not change dynamically with updates to the ConfigMap or Secret settings.

  • Click trash-light on the right side of a created environment variable to delete it.

Parameter Description

Key

The name of the environment variable.

Value

The value of the environment variable.

Resource

The name of the ConfigMap or Secret. Only available when referencing a ConfigMap or Secret.

Key in Resource

The key within the ConfigMap or Secret. The value corresponding to this key will be used as the value of the environment variable. Only available when referencing a ConfigMap or Secret.

  • Pod Settings > Add Container > Pod Security Context

Set the permissions of container processes in the Linux system.

Parameter Description

Access Control

Access permissions for container processes.

  • Privileged Mode: Runs the container process as the root user on the host.

  • Allow Privilege Escalation: Allows the container process to acquire more privileges than its parent process. This option is enabled by default when Privileged Mode is enabled.

  • Read-only Root Filesystem: Sets the root directory of the container’s filesystem to read-only.

Users and User Groups

The user and user group that run the container process entry point.

  • Run as non-root only: Check whether the container will run as the root user before starting the container. If the container will run as the root user, the container will not be started. When this feature is enabled, the system will ignore the Privileged Mode setting.

  • User: The UID that executes the container process entry point. Defaults to the UID specified in the image metadata.

  • User Group: The GID that executes the container process entry point. Defaults to the default GID of the container runtime.

SELinux Context

The SELinux label for the container process, including Level, Role, Type, and User. For more information, refer to the SELinux official documentation.

Capabilities

Additional permissions added to or removed from container processes in the Linux system. Refer to the Linux official documentation for a list of Linux process capabilities.

  • When adding or removing capabilities for container processes, you need to remove the CAP_ prefix from the capability name. For example, entering SYS_TIME in the Remove text box removes the CAP_SYS_TIME capability from the container process.

  • Click Add to set multiple capability addition or removal instructions.

  • Pod Settings > Add Container > Sync Host Timezone

Selecting the checkbox to the left of Synchronize Host Timezone will synchronize the timezone of the container with that of the host.

  • Storage Settings

Mount volumes, ConfigMaps or Secrets for containers.

Parameter Description

Mount Volume

Mount persistent volumes, ephemeral volumes, or HostPath volumes to containers.

Mount ConfigMap or Secret

Mount data from a ConfigMap or Secret as a volume to a container.

  • Hover over an added volume, then click pen on the right to edit the volume settings.

  • Hover over a mounted volume, then click trash-light on the right to delete the volume.

  • Storage Settings > Mount Volume > Persistent Volume

Mount a persistent volume for a container. The persistent volume claim used to create the persistent volume must belong to the same project as the container.

Parameter Description

Select Persistent Volume Claim

Select the persistent volume claim used to create the persistent volume. This persistent volume claim must belong to the same project as the container. If there are no available persistent volume claims in the container’s project, you need to create one in advance.

Mount Mode

The method by which a volume is mounted to a container.

  • ReadWrite: Allows the container to read data from and write data to the volume.

  • ReadOnly: Only allows the container to read data from the volume.

  • Unmounted: The volume is not mounted to the container.

Mount Path

The path where the volume is mounted to the container. Click textfield to set the subpath of the volume to be mounted. If no subpath is set, the entire volume is mounted by default.

  • Storage Settings > Mount Volume > Temporary Volume

Mount a temporary volume for a container. Temporary volumes have the following characteristics:

  • Automatically created by the system in the storage system of the node where the pod resides.

  • Automatically managed by the system, with a capacity limit equal to the node’s storage capacity.

  • Cannot store persistent data. The temporary volume is automatically created by the system when the pod is created and automatically deleted when the pod is deleted.

Parameter Description

Volume Name

The name of the temporary volume.

Capacity Limit

The capacity limit of the current volume.

Mount Mode

The method by which a volume is mounted to a container.

  • ReadWrite: Allows the container to read data from and write data to the volume.

  • ReadOnly: Only allows the container to read data from the volume.

  • Unmounted: The volume is not mounted to the container.

Mount Path

The path where the volume is mounted to the container. Click textfield to set the subpath of the volume to be mounted. If no subpath is set, the entire volume is mounted by default.

  • Storage Settings > Mount Volume > HostPath Volume

Mount files or directories from the node where the pod is located to the container.

  • Files or folders at the same path on different nodes may differ, so pod replicas on different nodes may read different data from the HostPath volume.

  • You need to ensure that the mounted path exists on the node where the pod is located and that the pod process has the necessary permissions. Otherwise, the pod process will be unable to read data from or write data to the HostPath volume.

Parameter Description

Volume Name

The name of the HostPath volume.

Host Path

The path of the file or folder on the node that needs to be mounted.

Mount Mode

The method by which a volume is mounted to a container.

  • ReadWrite: Allows the container to read data from and write data to the volume.

  • ReadOnly: Only allows the container to read data from the volume.

  • Unmounted: The volume is not mounted to the container.

Mount Path

The path where the volume is mounted to the container. Click textfield to set the subpath of the volume to be mounted. If no subpath is set, the entire volume is mounted by default.

  • Storage Settings > Mount ConfigMap or Secret

Mount data from a ConfigMap or Secret as a volume to a container.

Parameter Description

Select ConfigMap/Select Secret

Select a ConfigMap or Secret from the current project.

Mount Mode

Set how the data from the ConfigMap or Secret is mounted on the container. ConfigMaps and Secrets only support mounting as Read-Only or Do Not Mount.

Mount Path

Set the path on the container where the data from the ConfigMap or Secret is mounted.

  • The system will generate a folder based on the data in the ConfigMap or Secret, mapping each key-value pair to a file, where the key is the filename and the value is the file content.

  • Click textfield to specify key-value pairs from the ConfigMap or Secret to be mounted as files. If no subpath is specified, the entire ConfigMap or Secret is mounted by default. If a subpath is used, the files mounted into the container will not be dynamically updated with changes to the ConfigMap or Secret.

Select Specific Key

Mount key-value pairs from the ConfigMap or Secret as files into the container. Files mounted into the container will be dynamically updated with changes to the ConfigMap or Secret. Click Add to mount multiple key-value pairs.

  • Key: The key name of the key-value pair in the ConfigMap or Secret that needs to be mounted.

  • Path: The path within the container relative to the Mount Path. The specified key-value pair from the ConfigMap or Secret will be mounted at this path, overwriting any existing files at the Mount Path.

  • Advanced Settings

Specify nodes for the pods managed by the Job, and set the Job’s metadata.

Parameter Description

Select Node

Schedule pod replicas to nodes with specified labels.

  • You can manually enter the label key-value pairs for the target node, or click Specify Node to select a node.

  • Click Add Node Selector to set multiple labels. Pod replicas will be scheduled to nodes that have all the specified labels.

  • Click trash-light to the right of a created label to delete it.

Add Metadata

Set labels and annotations for a Job.

  • Click Add to set multiple labels or annotations.

  • Click trash-light on the right side of a created label or annotation to delete it.