Updated on 2024-07-04 GMT+08:00

Jobs

A job is responsible for batch processing of short lived one-off tasks that are executed only once. It ensures that one or more pods are successfully completed.

A job is a resource object that Kubernetes uses to control batch tasks. Batch jobs are different from long-term servo jobs (such as Deployments). The former can be started and terminated at specific time, while the latter runs unceasingly until it is terminated. The pods managed by a job will be automatically removed after successfully completing tasks based on user-defined configurations.

This run-to-completion feature of jobs is especially suitable for one-off tasks, such as continuous integration (CI). It works with the per-second billing of CCI to implement pay-per-use in the real sense.

Creating a Job

  1. Log in to the CCI console. In the navigation pane on the left, choose Workloads > Jobs. On the page displayed, click Create from Image.
  2. Specify basic information.

    • Job Name

      Enter 1 to 52 characters starting and ending with a letter or digit. Only lowercase letters, digits, hyphens (-), and periods (.) are allowed. Do not enter consecutive periods or place a hyphen before or after a period. The job name cannot be changed after creation. If you need to change the name, create another job.

    • Namespace

      Select a namespace. If no namespaces are available, create one by following the procedure provided in Namespace.

    • Description

      Enter a description, which cannot exceed 250 characters.

    • Pod Specifications

      You can select GPU-accelerated and allocate GPUs to the workload only if the namespace is a GPU-accelerated namespace.

      For details about the pod specifications, see "Pod Specifications" in the Notes and Constraints.

    • Container Settings
      A pod generally contains only one container. A pod can also contain multiple containers created from different images. If your application needs to run on multiple containers in a pod, click Add Container and then select an image.

      If different containers in a pod listen to the same port, a port conflict will occur and the pod may fail to start. For example, if an Nginx container (which listens to port 80) has been added to a pod, a port conflict will occur when another HTTP container in the pod tries to listen to port 80.

      • My Images: images you have uploaded to SWR

        If you are an IAM user, you must obtain permissions before you can use the private images of your account. For details on how to set permissions, see (Optional) Uploading Images.

        Currently, CCI does not support third-party image repositories.

      • Open Source Images: displays public images in the image center.
      • Shared Images: images shared by others through SWR

      Select the image version and set the container name and CPU and memory specifications (the minimum configuration of a single container is 0.25 vCPUs and 0.2 GiB). You can also enable the collection of standard output files. If you enable file collection, you will be billed for the log storage space you use.

      You can also configure the following advanced settings for containers:

      • Storage: You can mount persistent volumes to containers. Currently, EVS and SFS Turbo volumes are supported. On the EVS Volumes or SFS Turbo Volumes tab, set the volume name, capacity, container path, and disk type. After the job is created, you can manage the storage volumes. For details, see EVS Volumes, or SFS Turbo Volumes.
      • Log Collection: Application logs will be collected in the path you set. You need to configure policies to prevent logs from being over-sized. Click Add Log Storage, enter a container path for storing logs, and set the upper limit of log file size. After the workload is created, you can view logs on the AOM console. For details, see Log Management.
      • Environment Variables: You can manually set environment variables or add variable references. Environment variables add flexibility to workload configuration. The environment variables for which you have assigned values during container creation will take effect upon container startup. This saves you the trouble of rebuilding the container image.

        To manually set variables, enter the variable name and value.

        To reference variables, set the variable name, reference type, and referenced value for each variable. The following variables can be referenced: PodIP (pod IP address), PodName (pod name), and Secret. For details about how to create a secret reference, see Secrets.

      • Liveness Probe: You can configure a liveness probe for customized health check of the container. If the container fails the check, the CCI will stop the container and determine whether to restart the container based on the restart policy. For details about how to configure a liveness probe, see Setting Health Check Parameters.
      • Lifecycle: Lifecycle scripts specify actions that applications take when a lifecycle event occurs. For details about how to configure the scripts, see Container Lifecycle.
      • Startup Commands: You can set the commands to be executed immediately after the container is started. Startup commands correspond to the ENTRYPOINT startup instructions of the container engine. For details, see Setting Container Startup Commands.
      • Configuration Management: You can mount ConfigMaps and secrets to a container. For details about how to create ConfigMaps and secrets, see ConfigMaps and Secrets.

  3. Click Next: Configure Advanced Settings and configure advanced settings.

    Jobs can be classified into one-off jobs and custom jobs.

    • One-off job: A one-off job creates one pod each time. The job is completed when the pod is successfully executed.
    • Custom job: You can set the number of executions and the number of concurrent executions for a custom job. Completions specifies the number of pods that need to be successfully executed until the job is completed. Parallelism specifies the maximum number of pods that can run concurrently during the execution of the job. The number of parallel jobs should be less than the number of times the job is executed.

    You can set the timeout period for the job. When the job execution duration exceeds the timeout period, the job will be identified as failed, and all pods under this job will be deleted. If you leave this parameter blank, the job will never time out.

  4. Click Next: Confirm. After you confirm the configuration, click Submit. Then click Back to Job List.

    If the job status is Executing, the job is created successfully. You can click the job name to view job details and press F5 to view the real-time job status.

Creating a Job Using kubectl

For details, see Creating a Job.