Create a Job application by using an image

Container Service for Kubernetes allows you to create Job applications on the web UI. This topic describes the features of Job applications and how to create a Job application. The following example creates a Job application named busybox.

1. Log on to the Container Service console.
2. In the left-side navigation pane under Container Service - Kubernetes, choose Applications > Jobs. On the Jobs page that appears, click Create from Image in the upper-right corner.
3. Configure basic application information and click Next.
   • Name: the name of the application.
   • Cluster: the cluster in which the application is deployed.
   • Namespace: the namespace in which the application is deployed. If you leave this field unspecified, the system uses the default namespace.
   • Type: the application type. Select Job from the drop-down list.
     Note This example describes how to create a Job application.

   

4. Configure containers.
   Note You can configure multiple containers for the pods of the application.
   1. Set basic parameters.
      • Image Name: Click Select Image. In the dialog box that appears, select an image and click OK. In this example, the busybox image is used.

        You can also enter a private registry in the format of domainname/namespace/imagename:tag.

      • Image Version: Click Select Image Version to select a version. If this parameter is not specified, the latest image version is used.
      • Always Pull Images: Container Service caches the image to improve the deployment efficiency. During deployment, if the tag of the newly specified image is the same as that of the cached image, Container Service reuses the cached image instead of pulling the same image again. Therefore, if you do not modify the image tag when you modify the code or image, the earlier image in the local cache is used for the application deployment. If you select this check box, Container Service ignores the cached image and re-pulls the image during application deployment. This ensures that the application is deployed based on the latest image and code.
      • Set ImagePullSecret: If you use a private image, we recommend that you configure a Secret to secure the image. For more information, see Use an image Secret.
      • Resource Limit: the upper limit of CPU and memory resources available for the application. This prevents the application from occupying excessive resources. CPU is measure in millicores, that is, one thousandth of one core. Memory is measured in bytes, which can be GiB, MiB, or KiB.
      • Required Resources: the amount of CPU and memory resources that are reserved for the application, that is, exclusive to the container. This prevents the application from becoming unavailable due to resource shortage when other services or processes compete for resources.
      • Init Container: Select this check box to create an Init Container. Init Container contains useful tools. For more information, see Init Container.

      

   2. Optional:Set environment variables.

      You can use key-value pairs to set environment variables for the pods. Environment variables are used to add environmental labels or pass configuration parameters to the pods. For more information, see Pod variable.

   3. Optional:Configure health checks.

      You can set liveness probes and readiness probes. Liveness probes are used to determine when to restart the container. Readiness probes are used to determine when the container is ready to start accepting traffic. For more information about health checks, see health checks.

      

      Request type	Description
      HTTP request	Sends an HTTP GET request to the container. Supported parameters are as follows: Protocol: HTTP or HTTPS. Path: the requested path on the server. Port: the port exposed by the container. The port number must be in the range of 1 to 65535. HTTP Header: the custom headers in the HTTP request. Duplicate headers are allowed. Key-value pairs are supported. Initial Delay (s): the initialDelaySeconds field. The time (in seconds) to wait before performing the first probe after the container is started. Default value: 3. Period (s): the periodSeconds field. How often (in seconds) to perform the probe. Default value: 10. Minimum value: 1. Timeout (s): the timeoutSeconds field. The time (in seconds) after which the probe times out. Default value: 1. Minimum value: 1. Healthy Threshold: the minimum number of consecutive successes that must occur for the probe to be considered successful after having failed. Default value: 1. Minimum value: 1. For liveness probes, this parameter must be set to 1. Unhealthy Threshold: the minimum number of consecutive failures that must occur for the probe to be considered failed after having succeeded. Default value: 3. Minimum value: 1.
      TCP connection	Sends a TCP socket to the container. Then, kubelet will attempt to open a socket to your container on the specified port. If a connection can be established, the container is considered healthy. Otherwise, it is considered unhealthy. Supported parameters are as follows: Port: the port exposed by the container. The port number must be in the range of 1 to 65535. Initial Delay (s): the initialDelaySeconds field. The time (in seconds) to wait before performing the first probe after the container is started. Default value: 15. Period (s): the periodSeconds field. How often (in seconds) to perform the probe. Default value: 10. Minimum value: 1. Timeout (s): the timeoutSeconds field. The time (in seconds) after which the probe times out. Default value: 1. Minimum value: 1. Healthy Threshold: the minimum number of consecutive successes that must occur for the probe to be considered successful after having failed. Default value: 1. Minimum value: 1. For liveness probes, this parameter must be set to 1. Unhealthy Threshold: the minimum number of consecutive failures that must occur for the probe to be considered failed after having succeeded. Default value: 3. Minimum value: 1.
      Command line	Runs a probe command in the container to check its health. Supported parameters are as follows: Command: the probe command that is used to check the health of the container. Initial Delay (s): the initialDelaySeconds field. The time (in seconds) to wait before performing the first probe after the container is started. Default value: 5. Period (s): the periodSeconds field. How often (in seconds) to perform the probe. Default value: 10. Minimum value: 1. Timeout (s): the timeoutSeconds field. The time (in seconds) after which the probe times out. Default value: 1. Minimum value: 1. Healthy Threshold: the minimum number of consecutive successes that must occur for the probe to be considered successful after having failed. Default value: 1. Minimum value: 1. For liveness probes, this parameter must be set to 1. Unhealthy Threshold: the minimum number of consecutive failures that must occur for the probe to be considered failed after having succeeded. Default value: 3. Minimum value: 1.

   4. Optional:Configure the lifecycle.

      You can set the following parameters to configure the lifecycle of the container: Container Start Parameter, Start, Post Start, and Pre Stop. For more information, see Attach Handlers to Container Lifecycle Events.

      • Container Start Parameter: You can select stdin to enable standard input for the container, or select tty to assign a virtual terminal to the container to send signals to the container. Normally, select both options so that you can bind the terminal (tty) to the standard input (stdin). For example, an interactive program can obtain standard input from users and then display the obtained standard input on the terminal.
      • Start: the command to run when the container starts and the command parameter.
      • Post Start: the command to run after the container starts.
      • Pre Stop: the command to run before the container stops.

      

   5. Optional:Configure volumes.

      Local volumes and cloud volumes are supported.

      • Local Volume: supports hostPath, ConfigMaps, Secrets, and temporary directories. A local volume mounts the corresponding mount source to a path in the container. For more information, see Volumes.
      • Cloud Volume: supports Alibaba Cloud disk, Network Attached Storage (NAS), and Object Storage Service (OSS).
   6. Optional:Configure Log Service. You can set log collection parameters and customize tags.
      Note Ensure that a Kubernetes cluster is deployed and the Log Service agent is installed in the cluster.

      Log collection parameters are as follows:

      • Logstore: the Logstore to be generated in Log Service for storing collected logs.
      • Log Path in Container: You can set this parameter to stdout or a log path.
        • stdout: collects the standard output logs of the container.
        • Log path: collects the text logs in the specified path. Wildcards can be used in setting the log path.

      You can also set custom tags. The custom tags are added to the logs of the container when they are collected. Custom tags make it easy to collect log statistics, filter logs, and analyze logs.

5. Set other parameters based on your needs and click Next.
6. Configure advanced settings.

   You can configure Job settings.

   Parameter	Description
   Completions	The number of pods that must be run successfully by the configured Job. Default value: 1.
   Parallelism	The number of pods that must be run in parallel by the configured Job at any time. Default value: 1.
   ActiveDeadlineSeconds	The operating time limit of the configured Job. If the Job is not completed within the time limit, the system tries to terminate the Job.
   BackoffLimit	The number of retries performed by the configured Job to create pods after a failure. Each time the Job fails, the failed pods associated with the Job are restarted with time delay. The time delay grows exponentially each time. Default value: 6. Maximum value: 6.
   Restart	Only Never and OnFailure restart policies are supported.

   

7. Click Create.
8. After the application is created, you are directed to the Complete page, which displays the resource objects under the application.

   

   You can click View Details to view application details.

   During creation, you can view the creation status of pods in the Status column. In this example, two pods are created in parallel according to the Job definition.

   

   Wait until all pods are created.

   

9. Click Back in the upper-left corner. On the Job List page that appears, you can view the completion time of the Job.
   Note If some pods are still being created, the page does not display the Job completion time.