An application is an instance installed by the Helm tool. It is a collection of resource objects such as workloads, services and storage. Applications support unified management of resources.

Installing an application means installing a chart to a cluster to deploy an application instance. You can install an application in two ways, on the Application page or on the Artifact Repository page. This section describes how to install an application on the Application page.

In the ZStack Zaku main menu, click Container Orchestration > Application Management > Application to enter the Application page. Click Install Application. The Install Application page is displayed.

In the ZStack Zaku main menu, click Container Orchestration > Application Management > Application to enter the Application page.

Applications support the following operations:

Operation	Description
Install application	Install a chart to a cluster to deploy an application instance.
Update application	Update the application configuration based on the current chart, or update the application with a new chart. Note: Applications that were not installed or updated from the console do not support updates based on the current chart. Updates based on the current chart are not supported when the current chart has been deleted.
Application details	Go to the application details page to view basic information, version history, configuration resources and related resources of the application, including pods, PVCs, services and ingresses.
Roll back application	Roll back the application to a specified version. Note: To perform this operation, go to the application details page and click History Version > Action > Rollback. Rollback is supported only to versions in the Enabled or Installed status.
Delete historical version	Delete a historical version of the application. Note: To perform this operation, go to the application details page and click History Version > Action > Delete.
Delete application	Delete the application from the cluster. Note: After deletion, the resource objects related to the application are deleted at the same time. PVCs created in the application through volumeClaimTemplates are not deleted at the same time. To delete them, go to the PVC list and perform the delete operation separately.

A workload is an application running on Kubernetes. It manages a group of pods that use the same image, and includes types such as Deployment, StatefulSet and DaemonSet.

In the ZStack Zaku main menu, click Container Orchestration > Application Management > Workload to enter the Workload page. Click Create Workload and the Create Workload page is displayed.

Creating a workload includes the following five steps:

1. Basic information
   You can refer to the following example to enter the required information:

   • Name: set the workload name. Naming rules: the length is limited to 2-50 characters, the input can contain only lowercase letters, digits and hyphens (-), and it must start with a lowercase letter and end with a digit or a lowercase letter.
     Note: Workloads of the same type cannot use the same name under the same namespace.
   • Type: select the workload type. Three types are supported: Deployment, StatefulSet and DaemonSet. For the differences between the types, see Workload Types
   • Replicas: set the number of pods that the workload contains. Up to 100 replicas are supported. Workloads of the DeamonSet type do not need the number of replicas to be set.
   • Workload Label: set the workload label. By default, the system adds two labels, app and workloadType, to the workload, whose values correspond to the workload name and the workload type respectively. These two labels cannot be edited or deleted. You can also add other custom labels. Set the following parameters:
     • Key: enter the label key.
       Note:

       • Usually the key can contain 1-63 characters, including letters, digits and the following special characters: (-)(_)(.). The special characters cannot be used at the beginning or the end of the key.
       • A prefix can be added before the key and connected to the key with /, for example k8s.io/app. All the characters before / are considered the key prefix, and all the characters after / are considered the key.
       • The key prefix can contain 1-253 characters, including lowercase letters, digits and the following special characters: (-)(_)(.). Two or more special characters cannot be used consecutively, and special characters cannot be used at the beginning or the end of the prefix.
       • Note that you do not have to use a key prefix, but the key is required.
     • Value: enter the label value.
   • Workload Annotation: optional. Add workload annotations.
     • Key: enter the annotation key.
       Note:

       • Usually the key can contain 1-63 characters, including letters, digits and the following special characters: (-)(_)(.). The special characters cannot be used at the beginning or the end of the key.
       • A prefix can be added before the key and connected to the key with /, for example k8s.io/app. All the characters before / are considered the key prefix, and all the characters after / are considered the key.
       • The key prefix can contain 1-253 characters, including lowercase letters, digits and the following special characters: (-)(_)(.). Two or more special characters cannot be used consecutively, and special characters cannot be used at the beginning or the end of the prefix.
       • Note that you do not have to use a key prefix, but the key is required.
     • Value: enter the annotation value.
   • Pod Label: set the pod label. By default, the system adds two labels, app and workloadType, to the pod, whose values correspond to the workload name and the workload type respectively. These two labels cannot be edited or deleted. You can also add other custom labels. Set the following parameters:
     • Key: enter the label key.
       Note:

       • Usually the key can contain 1-63 characters, including letters, digits and the following special characters: (-)(_)(.). The special characters cannot be used at the beginning or the end of the key.
       • A prefix can be added before the key and connected to the key with /, for example k8s.io/app. All the characters before / are considered the key prefix, and all the characters after / are considered the key.
       • The key prefix can contain 1-253 characters, including lowercase letters, digits and the following special characters: (-)(_)(.). Two or more special characters cannot be used consecutively, and special characters cannot be used at the beginning or the end of the prefix.
       • Note that you do not have to use a key prefix, but the key is required.
     • Value: enter the label value.
   • Pod Annotation: optional. Add pod annotations.
     • Key: enter the annotation key.
       Note:

       • Usually the key can contain 1-63 characters, including letters, digits and the following special characters: (-)(_)(.). The special characters cannot be used at the beginning or the end of the key.
       • A prefix can be added before the key and connected to the key with /, for example k8s.io/app. All the characters before / are considered the key prefix, and all the characters after / are considered the key.
       • The key prefix can contain 1-253 characters, including lowercase letters, digits and the following special characters: (-)(_)(.). Two or more special characters cannot be used consecutively, and special characters cannot be used at the beginning or the end of the prefix.
       • Note that you do not have to use a key prefix, but the key is required.
     • Value: enter the annotation value.
2. Container configuration
   Click Add Container and refer to the following example to enter the required information. Multiple container configurations can be added to one workload:

   • Container Name: set the container name. Naming rules: the length is limited to 1-63 characters, the input can contain only lowercase letters, digits and hyphens (-), and it must start with a lowercase letter.
   • Container Type: select the container type. Two types are supported: worker container and init container. The default type is worker container.
   • Image Source: select the source of the container image. Both a repository and an external repository are supported.
     If you select Repository, the container is created using an image that has been uploaded to the ZStack Zaku repository. Set the following parameters:

     • Image: select the container image.
     • Tag: select the image tag.
     If you select External repository, the image is pulled from a repository outside ZStack Zaku to create the container. Set the following parameters:

     • Image: enter the detailed image address, for example: docker.io/library/nginx:latest.
     • Image pulling Secret: optional. If the external repository to which the image belongs is a private repository, select a secret for repository authentication.
   • imagePullPolicy: select the image pull policy, which defines whether the image is pulled from the repository again each time the container starts. The following three policies are supported:
     • Always: the specified image is pulled again each time the container starts.
     • IfNotPresent: the image is pulled again only when the specified container image does not exist on the node where the container is located.
     • Never: the image is never pulled again, no matter whether the specified container image exists on the node where the container is located. When the specified image is not available on the node, the container fails to start.
   • privileged: select whether to enable the privileged mode for the container. After it is enabled, the node where the container is located runs the container process as the root user.
   • Resource request: optional. Set the CPU/memory request value of the container. Unit of CPU: core. Unit of memory: Mi, Gi.
     Note:

     • The CPU/memory request value is the minimum CPU/memory value required by the container. During container scheduling, the container is scheduled to a node only when the total allocatable CPU/memory of the node is greater than or equal to the CPU/memory request value of the container.
     • The CPU/memory request value cannot be greater than the CPU/memory limit value.
     • The CPU/memory request value cannot be greater than the CPU/memory quota of the current namespace. Otherwise, the workload fails to be created.
     • If it is not set, the CPU/memory request value equals the CPU/memory limit value by default.
     • You can set the CPU request value and the memory request value at the same time, or set the CPU request value or the memory request value separately.
   • Resource limit: optional. Set the CPU/memory limit value of the container. Unit of CPU: core. Unit of memory: Mi, Gi.
     Note:

     • The CPU/memory limit value is the maximum CPU/memory that the container can use. Setting the CPU/memory limit value is recommended in production environments, to avoid system failures caused by excessive container resource usage.
     • When the CPU/memory used by a container exceeds the limit value, a pod restart may be triggered, which affects the normal running of the workload. Set the limit value according to your actual situation.
     • If it is not set, the container uses the default resource limit of the current namespace.
     • You can set the CPU limit value and the memory limit value at the same time, or set the CPU limit value or the memory limit value separately.
   • Command: optional. Set the command to be run when the container starts, for example: /bin/sh. If it is left blank, the container runs the default command of the image when it starts.
   • Argument: optional. Set the arguments of the command. Multiple arguments are supported, separated by half-width commas (,).
   • Env: optional. Add container environment variables. Variables can be added in the following ways:
     • Custom key/value pair: add container environment variables with custom key/value pairs.
       • Variable name: set the variable name.
       • Variable value: set the variable value.
     • Reference pod information: reference a field of the pod Yaml as a container environment variable.
       • Variable name: set the variable name.
       • Pod path: select the pod field to be referenced.
     • Reference resource request/limit information: reference a resource request/limit field of the container as an environment variable.
       • Variable name: set the variable name.
       • Resource path: select the resource request/limit field to be referenced.
       • Container Name: set the name of the container to be referenced. If it is left blank, the resource request/limit field of the current container is referenced by default.
     • Import a configmap key/value: reference a specified configmap key/value as an environment variable.
       • Variable name: set the variable name.
       • Configmap: select the configmap to be referenced.
       • Configmap key: select the configmap key to be referenced.
     • Import a configmap: reference a complete specified configmap as environment variables.
       • Configmap: select the configmap to be referenced.
       • Prefix: optional. Enter a prefix. The prefix and the configmap key together form the environment variable name.
     • Import a secret key/value: reference a specified secret key/value as an environment variable.
       • Variable name: set the variable name.
       • Configmap: select the secret to be referenced.
       • Configmap key: select the secret key to be referenced.
     • Import a secret: reference a complete specified secret as environment variables.
       • Secret: select the secret to be referenced.
       • Prefix: optional. Enter a prefix. The prefix and the secret key together form the environment variable name.
   • livenessProbe: select whether to enable the liveness probe, which determines whether the container is alive. When the container is detected as not alive, it is restarted automatically. To enable the liveness probe, set the following parameters:
     • Probe type: select the probe type. Four probe types are supported: httpGet, tcpSocket, exec and GRPC.
       • httpGet: this type is mainly used to probe containers that provide HTTP/HTTPS services. The cluster periodically sends an HTTP/HTTPS GET request to the container. If the returned code is within the range of 200 to 399, the probe succeeds. Otherwise, the probe fails. If you select httpGet, set the following parameters:
         • Protocol: select the probe protocol. Two protocol types are supported: HTTP and HTTPS.
         • Path: optional. Enter the probe path.
         • Port: enter the probe port.
         • httpHeaders: optional. Enter the probe request headers.

           Example: if you select the HTTP protocol, enter /healthcheck as the probe path and 8080 as the probe port, and the container IP address is 192.168.0.32, the cluster sends periodic GET requests to http://192.168.0.32:8080/healthcheck.

       • tcpSocket: this type is mainly used to probe containers that provide TCP services. The cluster periodically establishes a TCP connection to the container. If the connection succeeds, the probe succeeds. Otherwise, the probe fails. If you select tcpSocket, set the following parameters:
         • Port: enter the port used to establish the TCP connection.
       • exec: this type requires a custom command that can be executed in the container. The cluster periodically executes the command in the container. If the command returns 0, the probe succeeds. Otherwise, the probe fails. If you select exec, set the following parameters:
         • Exec: enter the custom probe command.
       • GRPC: this type is mainly used to probe containers that implement the GRPC health checking protocol. The cluster periodically performs a remote procedure call through GRPC. If the response status is SERVING, the probe succeeds. Otherwise, the probe fails. If you select GRPC, set the following parameters:
         • Port: enter the port used for the GRPC probe.
     • initialDelaySeconds: set the delay before the initial probe. The initial probe is performed after the container starts and the delay ends. The default value is 3 seconds.
     • periodSeconds: set the probe frequency. By default, the probe is performed every 10 seconds.
     • Timeout: set the probe timeout period. The default value is 1 second.
     • failureThreshold: set the number of probe failures allowed. The default value is 3. When the set upper limit is reached, the application container is considered not alive and is restarted automatically.
   • readinessProbe: select whether to enable the readiness probe, which determines whether the container is ready to provide services. When the container is detected as not ready, traffic is not forwarded to it. To enable the readiness probe, set the following parameters:
     • Probe type: select the probe type. Four probe types are supported: httpGet, tcpSocket, exec and GRPC.
       • httpGet: this type is mainly used to probe containers that provide HTTP/HTTPS services. The cluster periodically sends an HTTP/HTTPS GET request to the container. If the returned code is within the range of 200 to 399, the probe succeeds. Otherwise, the probe fails. If you select httpGet, set the following parameters:
         • Protocol: select the probe protocol. Two protocol types are supported: HTTP and HTTPS.
         • Path: optional. Enter the probe path.
         • Port: enter the probe port.
         • httpHeaders: optional. Enter the probe request headers.

           Example: if you select the HTTP protocol, enter /healthcheck as the probe path and 8080 as the probe port, and the container IP address is 192.168.0.32, the cluster sends periodic GET requests to http://192.168.0.32:8080/healthcheck.

       • tcpSocket: this type is mainly used to probe containers that provide TCP services. The cluster periodically establishes a TCP connection to the container. If the connection succeeds, the probe succeeds. Otherwise, the probe fails. If you select tcpSocket, set the following parameters:
         • Port: enter the port used to establish the TCP connection.
       • exec: this type requires a custom command that can be executed in the container. The cluster periodically executes the command in the container. If the command returns 0, the probe succeeds. Otherwise, the probe fails. If you select exec, set the following parameters:
         • Exec: enter the custom probe command.
       • GRPC: this type is mainly used to probe containers that implement the GRPC health checking protocol. The cluster periodically performs a remote procedure call through GRPC. If the response status is SERVING, the probe succeeds. Otherwise, the probe fails. If you select GRPC, set the following parameters:
         • Port: enter the port used for the GRPC probe.
     • initialDelaySeconds: set the delay before the initial probe. The initial probe is performed after the container starts and the delay ends. The default value is 3 seconds.
     • periodSeconds: set the probe frequency. By default, the probe is performed every 10 seconds.
     • Timeout: set the probe timeout period. The default value is 1 second.
     • failureThreshold: set the number of probe failures allowed. The default value is 3. When the set upper limit is reached, the container is considered not ready, and traffic is not forwarded to it.
     • successThreshold: set the minimum number of successful probes required before the container is considered ready. The default value is 1. If it is set to 2, the container must be probed successfully twice in a row before it is considered ready.
   • startupProbe: select whether to enable the startup probe, which determines whether the container application has been initialized successfully. When the application is detected as not initialized successfully, the container is restarted automatically. If the container application takes a long time to initialize, enabling the startup probe is recommended. To enable the startup probe, set the following parameters:
     • Probe type: select the probe type. Four probe types are supported: httpGet, tcpSocket, exec and GRPC.
       • httpGet: this type is mainly used to probe containers that provide HTTP/HTTPS services. The cluster periodically sends an HTTP/HTTPS GET request to the container. If the returned code is within the range of 200 to 399, the probe succeeds. Otherwise, the probe fails. If you select httpGet, set the following parameters:
         • Protocol: select the probe protocol. Two protocol types are supported: HTTP and HTTPS.
         • Path: optional. Enter the probe path.
         • Port: enter the probe port.
         • httpHeaders: optional. Enter the probe request headers.

           Example: if you select the HTTP protocol, enter /healthcheck as the probe path and 8080 as the probe port, and the container IP address is 192.168.0.32, the cluster sends periodic GET requests to http://192.168.0.32:8080/healthcheck.

       • tcpSocket: this type is mainly used to probe containers that provide TCP services. The cluster periodically establishes a TCP connection to the container. If the connection succeeds, the probe succeeds. Otherwise, the probe fails. If you select tcpSocket, set the following parameters:
         • Port: enter the port used to establish the TCP connection.
       • exec: this type requires a custom command that can be executed in the container. The cluster periodically executes the command in the container. If the command returns 0, the probe succeeds. Otherwise, the probe fails. If you select exec, set the following parameters:
         • Exec: enter the custom probe command.
       • GRPC: this type is mainly used to probe containers that implement the GRPC health checking protocol. The cluster periodically performs a remote procedure call through GRPC. If the response status is SERVING, the probe succeeds. Otherwise, the probe fails. If you select GRPC, set the following parameters:
         • Port: enter the port used for the GRPC probe.
     • initialDelaySeconds: set the delay before the initial probe. The initial probe is performed after the container starts and the delay ends. The default value is 3 seconds.
     • periodSeconds: set the probe frequency. By default, the probe is performed every 10 seconds.
     • Timeout: set the probe timeout period. The default value is 1 second.
     • failureThreshold: set the number of probe failures allowed. The default value is 3. When the set upper limit is reached, the container application is considered not initialized successfully, and the container is restarted automatically.
   • PostStart: select whether to enable the PostStart callback, which is used to perform specified initialization operations immediately after the container is created. To enable the PostStart callback, set the following parameters:
     • Lifecycle hook: select the hook type. Two types are supported: httpGet and custom command.
       • httpGet: send an HTTP request to a specific endpoint of the container. If you select httpGet, set the following parameters:
         • Protocol: select the protocol type. The current Kubernetes version supports only the HTTP protocol.
         • Request address: set the HTTP request address. If it is left blank, the IP address of the current pod is used by default.
         • Path: optional. Set the HTTP request path. The default value is /
         • Port: set the HTTP request port.
         • httpHeaders: optional. Set the HTTP request headers.
       • Custom command: execute a custom command in the cgroups and namespaces of the container. If you select the custom command, set the following parameters:

         • Custom command: set the custom command. Multiple commands are supported, separated by half-width commas (,).

         Note: The resources consumed by the custom command are counted in the total resource consumption of the container.
   • PreStop: select whether to enable the PreStop callback, which is used to perform specified cleanup operations before the container stops, such as saving data, closing connections and notifying other systems. To enable the PreStop callback, set the following parameters:
     • Lifecycle hook: select the hook type. Two types are supported: httpGet and custom command.
       • httpGet: send an HTTP request to a specific endpoint of the container. If you select httpGet, set the following parameters:
         • Protocol: select the protocol type. The current Kubernetes version supports only the HTTP protocol.
         • Request address: set the HTTP request address. If it is left blank, the IP address of the current pod is used by default.
         • Path: optional. Set the HTTP request path. The default value is /
         • Port: set the HTTP request port.
         • httpHeaders: optional. Set the HTTP request headers.
       • Custom command: execute a custom command in the cgroups and namespaces of the container. If you select the custom command, set the following parameters:
         • Custom command: set the custom command. Multiple commands are supported, separated by half-width commas (,).
         Note: The resources consumed by the custom command are counted in the total resource consumption of the container.
3. Resource mounting
   1. Mount PVC. PVCs can be mounted in two ways: creating a new PVC or mounting an existing PVC.
      • Create a new PVC: create a PVC for each pod under the workload through a PVC template and mount them separately. This method applies only to workloads of the StatefulSet type. Click Add PVC Template and set the following parameters:
        • PVC Name: set the name of the PVC. Naming rules: the length is limited to 1-50 characters, the input can contain only lowercase letters, digits and hyphens (-), and it must start with a lowercase letter and end with a digit or a lowercase letter.
        • storage class: select a storage class (StorageClass) for creating the pvc based on the storage type, reclaim policy, and expansion requirements.
          Note:

          • A storageclass is a configuration template used in Kubernetes to dynamically create PVCs. It defines the properties of the PVC, the creation policy and the required storage plugins.
          • Storageclasses are created and managed by the administrator. If no storageclass is available, contact the administrator.
        • access mode: select an access mode supported by the selected storage class. The access modes include:
          • ReadWriteOnce: read-write by a single node only.
          • ReadWriteMany: read-write by multiple nodes.
          • ReadOnlyMany: read-only by multiple nodes.
          Note: Local storage supports only ReadWriteOnce. Check the access mode again after changing the storage class.
        • Capacity: set the capacity of the PVC. Unit: Gi, Ti.
        • Container: select the container to which the PVC is to be mounted.
        • Mount path: select the mount path of the PVC on the container.
        • Permission: set the permission of the PVC. Read-only and read-write are supported.
        • subPath: optional. Enter the subPath of the PVC to be mounted to the container.
          Note:

          • The subPath is a directory or a file in the PVC. After it is entered, only the content under this path is mounted. When the same PVC is mounted to multiple containers or to multiple paths of one container, the subPath may need to be entered.
          • If it is left blank, the content under the root directory of the PVC is mounted by default.
      • Mount an existing PVC: select an existing PVC and mount it to the workload. All pods under the workload share this PVC. Click Add PVC and set the following parameters:
        • PVC: select a PVC.
          Note:

          • A pvc of the exclusive disk type supports read and write access by only one pod at a time. It can therefore be mounted to only one workload, and the workload must have exactly one replica.
          • Block storage or local storage pvcs that are already mounted cannot be selected again.
        • Container: select the container to which the PVC is to be mounted.
        • Mount path: set the mount path of the PVC on the container. Within the same container, the mount paths of all mounted resources must be different.
        • Permission: set the permission of the PVC. Read-only and read-write are supported.
        • subPath: optional. Enter the subPath of the PVC to be mounted to the container.
          Note:

          • The subPath is a directory or a file in the PVC. After it is entered, only the content under this path is mounted. When the same PVC is mounted to multiple containers or to multiple paths of one container, the subPath may need to be entered.
          • If it is left blank, the content under the root directory of the PVC is mounted by default.
   2. Mount hostpath: mount a file directory of the node to the workload. All pods under the workload can use this hostpath. Click Add hostpath and set the following parameters:
      • Hostpath: enter the host directory to be mounted.
        Note:

        • The hostpath must start with /.
        • The following system directories cannot be mounted: /, /bin, /boot, /data, /dev, /etc, /home, /lib, /lib64, /opt, /proc, /root, /run, /sbin, /srv, /sys, /tmp, /usr, /var
      • Container: select the container to which the hostpath is to be mounted.
      • Mount path: set the mount path of the host directory on the container. Within the same container, the mount paths of all mounted resources must be different.
      • Permission: set the permission of the hostpath. Read-only and read-write are supported.
      • subPath: optional. Enter the subPath of the hostpath to be mounted to the container.
        Note:

        • The subPath is a directory or a file under the current hostpath. After it is entered, only this directory or file is mounted. When the same hostpath is mounted to multiple containers or to multiple paths of one container, the subPath may need to be entered.
        • If it is left blank, all the content under this hostpath is mounted by default.
   3. Mount ConfigMap: mount an existing configmap to the workload. All pods under the workload can use this configmap. Click Add ConfigMap and set the following parameters:
      • Configmap: select a configmap.
      • Mount content: select the content to be mounted. You can mount all keys under the configmap, or only one or more specific keys.
        If you choose to mount all keys, set the following mount parameters:

        • Container: select the container to which the configmap is to be mounted.
        • Mount path: set the mount path of the configmap on the container. Within the same container, the mount paths of all resources must be different.
        • subPath: optional. Enter the subPath inside the configmap volume to be mounted to the container.
          Note:

          • If the subPath is entered, the configmap generates the corresponding file under the penultimate level of the mount path, and the file name is the last level of the mount path. For example, if the mount path is set to /data/config.conf, the configmap is mounted to the /data/ directory of the container with the file name config.conf, and the other existing files in the /data/ directory are not overwritten.
          • When the mount content is all keys of the configmap, the subPath must be entered as a key name in the configmap, and one subPath can correspond to only one key name. You can click Add Mount to set the mount configuration of different keys.
          • If the subPath is entered, the pod needs to be restarted after each configmap update to synchronize the update.
          • If it is left blank, the configmap is mounted to the last level of the mount path. For example, if the mount path is set to /data/config, the configmap is mounted to the /data/config directory, and the existing files in the /data/config directory are overwritten.
        If you choose to mount specific keys, set the following parameters:

        • Key: select a specific key.
        • Path: define the path generated for the key under the mount directory. If a subPath is used in the mount configuration, the path entered here must be the same as the subPath. Do not use an absolute path.

          Set the mount parameters:

        • Container: select the container to which the configmap is to be mounted.
        • Mount path: set the mount path of the configmap on the container. Within the same container, the mount paths of all resources must be different.
        • subPath: optional. Enter the subPath inside the configmap volume to be mounted to the container.
          Note:

          • If the subPath is entered, the configmap generates the corresponding file under the penultimate level of the mount path, and the file name is the last level of the mount path. For example, if the mount path is set to /data/config.conf, the configmap is mounted to the /data/ directory of the container with the file name config.conf, and the other existing files in the /data/ directory are not overwritten.
          • When the mount content is a specific key of the configmap, the subPath must be the same as the key path. You can click Add Mount to set the mount configuration of different keys.
          • If the subPath is entered, the pod needs to be restarted after each configmap update to synchronize the update.
          • If it is left blank, the configmap is mounted to the last level of the mount path. For example, if the mount path is set to /data/config, the configmap is mounted to the /data/config directory, and the existing files in the /data/config directory are overwritten.
   4. Mount Secret: mount an existing secret to the workload. All pods under the workload can use this secret. Click Add Secret and set the following parameters:
      • Secret: select a secret.
      • Mount content: select the content to be mounted. You can mount all keys under the secret, or only one or more specific keys.
        If you choose to mount all keys, set the following mount parameters:

        • Container: select the container to which the secret is to be mounted.
        • Mount path: set the mount path of the secret on the container. Within the same container, the mount paths of all resources must be different.
        • subPath: optional. Enter the subPath inside the secret volume to be mounted to the container.
          Note:

          • If the subPath is entered, the secret generates the corresponding file under the penultimate level of the mount path, and the file name is the last level of the mount path. For example, if the mount path is set to /data/config.conf, the secret is mounted to the /data/ directory of the container with the file name config.conf, and the other existing files in the /data/ directory are not overwritten.
          • When the mount content is all keys of the secret, the subPath must be entered as a key name in the secret, and one subPath can correspond to only one key name. You can click Add Mount to set the mount configuration of different keys.
          • If the subPath is entered, the pod needs to be restarted after each secret update to synchronize the update.
          • If it is left blank, the secret is mounted to the last level of the mount path. For example, if the mount path is set to /data/config, the secret is mounted to the /data/config directory, and the existing files in the /data/config directory are overwritten.
        If you choose to mount specific keys, set the following parameters:

        • Key: select a specific key.
        • Path: define the path generated for the key under the mount directory. If a subPath is used in the mount configuration, the path entered here must be the same as the subPath. Do not use an absolute path.

          Set the mount parameters:

        • Container: select the container to which the secret is to be mounted.
        • Mount path: set the mount path of the secret on the container. Within the same container, the mount paths of all resources must be different.
        • subPath: optional. Enter the subPath inside the secret volume to be mounted to the container.
          Note:

          • If the subPath is entered, the secret generates the corresponding file under the penultimate level of the mount path, and the file name is the last level of the mount path. For example, if the mount path is set to /data/config.conf, the secret is mounted to the /data/ directory of the container with the file name config.conf, and the other existing files in the /data/ directory are not overwritten.
          • When the mount content is a specific key of the secret, the subPath must be the same as the key path.
          • If the subPath is entered, the pod needs to be restarted after each secret update to synchronize the update.
          • If it is left blank, the secret is mounted to the last level of the mount path. For example, if the mount path is set to /data/config, the secret is mounted to the /data/config directory, and the existing files in the /data/config directory are overwritten.
4. Advanced configuration
   You can refer to the following example to enter the required information:

   • GPU Configuration: disabled by default. Enable it if GPU resources are required, and set the following parameters:
     • GPU manufacturer: select the GPU manufacturer. NVIDIA, huawei, HYGON, Iluvatar, and Alibaba are supported.
       • When the GPU manufacturer is NVIDIA, set the following parameters:
         • GPU Selection Method: select the GPU selection method. The following three methods are supported: Do not specify GPU, Specify GPU Model and Specify GPU.
           • Do not specify GPU: the GPU to be used by the pod is not specified. The platform schedules the pod to any GPU that meets the GPU resource configuration based on the GPU resource configuration.
           • Specify GPU Model: select one or more GPU models. The workload pods are scheduled to the GPUs of the selected models that meet the GPU resource configuration.
           • Specify GPU: select one or more GPUs. The workload pods are scheduled to the GPUs among the selected ones that meet the GPU resource configuration.
         • GPU model/GPU: specify the GPU model or the GPU.
           Note: You can select devices based on their status, temperature, and power consumption. When specifying GPUs, you can select only GPUs in the Normal state.
         • Container: fixed to the first worker container. Only the first worker container can use the GPU.
         • GPU Number: set the number of GPUs that the container needs to use.
           Note: A container can use only the GPUs of the node where the pod is located and cannot use GPUs across nodes.
         • GPU memory: set the memory size of a single GPU that the container needs to use. Selectable units: Gi, Mi.
           Note:

           • If the GPU number is greater than 1, each GPU requests the GPU memory size set here.
           • The GPU memory cannot exceed the maximum memory of a single GPU.
         • GPU Core Percentage: set the percentage of the computing power of a single GPU that the container needs to use.
           Note:

           • If the GPU number is greater than 1, each GPU can use up to the GPU core percentage set here.
           • If the GPU core percentage is not set, it is 0 by default, and the pod may be scheduled to any GPU that meets the GPU memory requirement.
           • The container uses the GPU in a shared way. If exclusive use is required, set the GPU core percentage to 100%.
       • When the GPU manufacturer is Huawei, set the following parameters:
         • GPU model: select the model of the GPU to be used. The available models are all the Huawei GPU models in the current cluster.
         • Container: fixed to the first worker container. Only the first worker container can use the GPU.
         • GPU Number: set the number of GPUs required by the container.
           Note:

           • A container can use only the GPUs on the node where its pod runs. It cannot use GPUs across nodes.
           • Each physical Ascend 910C card contains two logical devices. A GPU Number of 1 uses shared mode. To use entire cards exclusively, enter a multiple of 2. For example, enter 2 to use one physical card.
         • exclusive GPU: set whether the container uses GPUs in shared or exclusive mode. Shared mode is used by default.
           Note:

           • huawei does not support sharing multiple GPUs. For Ascend 910C, shared or exclusive mode is determined by GPU Number and does not require manual configuration. For other models, only exclusive mode is supported when GPU Number is greater than 1.
           • Avoid frequently switching between shared and exclusive modes on the same physical Ascend 910C card. If the NPU becomes unavailable after a switch, contact the administrator to stop or migrate the services on the affected node, restart the node, and try again.
         • GPU memory: in shared mode, select the GPU memory required by the container on each GPU.
           Note: Huawei allows GPUs to be sliced only according to several fixed specifications, and the number of AI Core cores corresponding to the memory is also fixed. Different GPUs have different slicing specifications. For the specific specifications, see the GPU memory drop-down list.
       • When the GPU manufacturer is HYGON, set the following parameters:
         • GPU model: select the model of the GPU to be used. The available models are all the HYGON GPU models in the current cluster.
           Note: If a HYGON GPU memory quota is configured for the namespace, the GPU model must be specified when the GPU is used exclusively. Otherwise, the pod fails to be created.
         • Container: fixed to the first worker container. Only the first worker container can use the GPU.
         • GPU Number: set the number of GPUs that the container needs to use.
           Note: A container can use only the GPUs of the node where the pod is located and cannot use GPUs across nodes.
         • Exclusive GPU: select whether to use the GPU exclusively. It is disabled by default, in which case the container uses the GPU in a shared way. Enable this configuration if the whole card is required.
           Note: HYGON does not support sharing multiple cards, that is, when the GPU number is greater than 1, the GPUs can only be used exclusively.
         • GPU memory: enter the memory size of a single GPU that the container needs to use. Selectable units: Gi, Mi.
           Note: The GPU memory cannot exceed the maximum memory of a single GPU.
         • GPU Core Percentage: set the percentage of the computing power of a single GPU that the container needs to use.
       • When the GPU manufacturer is Iluvatar, set the following parameters:
         • GPU model: select the model of the GPU to be used. The available models are all the Iluvatar GPU models in the current cluster.
         • Container: fixed to the first worker container. Only the first worker container can use the GPU.
         • GPU Number: set the number of GPUs that the container needs to use.
           Note: A container can use only the GPUs of the node where the pod is located and cannot use GPUs across nodes.
         • Exclusive GPU: select whether to use the GPU exclusively. It is disabled by default, in which case the container uses the GPU in a shared way. Enable this configuration if the whole card is required.
           Note: Iluvatar does not support sharing multiple cards, that is, when the GPU number is greater than 1, the GPUs can only be used exclusively.
         • GPU memory: enter the memory size of a single GPU that the container needs to use. Selectable units: Gi, Mi.
           Note: Iluvatar requires the GPU memory size to be a multiple of 256 Mi.
         • GPU Core Percentage: set the percentage of the computing power of a single GPU that the container needs to use.
         Note: To use an Iluvatar GPU, the Iluvatar software stack library needs to be pre-loaded into the container.
       • When the GPU manufacturer is Alibaba, set the following parameters:
         • GPU Selection Method: configure the GPU selection method. The following three methods are supported: Not specified, Specify GPU and Exclude GPU.
           • Not specified: by default, GPUs that meet the resource configuration are selected and allocated from all GPUs.
           • Specify GPU: GPUs that meet the resource configuration are selected and allocated only from the specified GPU range. If no eligible GPU exists in the range, the allocation fails.
           • Exclude GPU: the excluded GPUs are not selected, and devices that meet the resource configuration are selected and allocated from the remaining GPUs.
         • Specify GPU/Exclude GPU: select the GPUs to be specified/excluded.
           Note: When specifying GPUs, you can select only GPUs in the Normal state. If you do not specify GPUs, devices in the Crashed or Dropout state may be allocated. We recommend specifying GPUs in the Normal state or excluding abnormal devices.
         • Container: fixed to the first worker container. Only the first worker container can use the GPU.
         • GPU Number: set the number of GPUs that the container needs to use.
           Note: A container can use only the GPUs of the node where the pod is located and cannot use GPUs across nodes.
         • GPU memory: set the memory size of a single GPU that the container needs to use. Selectable unit: Gi.
           Note: The GPU memory cannot exceed the maximum memory of a single GPU.
         • GPU Core Percentage: set the percentage of the computing power of a single GPU that the container needs to use.
           Note: By default, the container uses the GPU in a shared way. To use the GPU exclusively, set the GPU memory to the maximum memory of the card and the GPU core percentage to 100%.
     • GPU Scheduling Policy: optional. Set a GPU scheduling policy for the current pod. After enabling this option, configure the following parameters:
       • node scheduling policy: select spread or binpack to determine how pods are distributed across GPU nodes.
       • GPU Card Scheduling Policy: select spread or binpack to determine how GPUs are selected for pods within the target node.
       Note:

       • Configure at least one policy after enabling this option. Any policy left unset uses the cluster default. For supported GPU manufacturers and policy descriptions, see GPU Scheduling Policy.
       • Node selection and affinity rules take precedence over GPU scheduling policies. The spread or binpack policy applies only to nodes that meet these rules.
       • When a pod uses both GPUs and local volumes, local volume requirements take precedence over GPU scheduling policies. The spread or binpack policy applies only to nodes that meet both the GPU resource requirements and the local volume requirements.
   • Node scheduling policy: select whether to set the node scheduling policy. It is disabled by default, in which case the default policy of Kubernetes is followed during node scheduling. If it is enabled, you can customize the scheduling policy, and the following parameters need to be set:
     • Policy type: select the policy type. Two types are supported: select by node name and select by node label.
       • Select by node name: select a node, and the workload pods are scheduled to this node.
       • Select by node label: enter one or more node labels, and the workload pods are scheduled to the nodes that have the specified labels.
     • Nodes/node labels: specify the nodes or the node labels.
   • Pod affinity: optional. Set the affinity among the pods under the current workload, or the affinity between the current workload and the pods of other workloads, to specify whether they are scheduled to the same node.
     • Add Type: two ways of adding affinity are supported: basic and advanced.
       • If you select the basic way, set the following parameters:
         • Workload: select a workload. The current workload or another workload can be selected.
           • Selecting the current workload means that the pods under the current workload are scheduled to the same node.
           • Selecting another workload means that the pods under the current workload and the pods under the specified workload are scheduled to the same node.
       • If you select the advanced way, set the following parameters:
         • Affinity policy: select the affinity policy. Two policies are supported: Required and Preferred.
           • Required: this affinity must be satisfied.
           • Preferred: this affinity is satisfied as much as possible. When it cannot be satisfied, some pods may be scheduled to different nodes.
         • Weight: set the affinity weight. This parameter needs to be set when the affinity policy is Preferred.
         • Namespace: select a namespace. After the selection, you can set the affinity between the pods of the current workload and the pods under this namespace.
         • Namespace selector: you can also select namespaces with the namespace selector, which supports selecting by label or by label expression.
           • Matching label: enter the label key and value, and the system automatically selects the namespaces that contain this label. If multiple labels are entered, a namespace is selected only when it contains all these labels.
           • Matching label expression: enter the key, value and operator of the label expression, and the system automatically selects the namespaces that match this label expression. If multiple label expressions are entered, a namespace is selected only when it matches all these label expressions.
           Note: If you neither select a namespace manually nor match namespaces with the namespace selector, the system selects the namespace of the current workload by default.
         • Pod selector: used to select pods. The pods under the current namespace are scheduled to the same node as the pods selected here. Selecting by label or by label expression is supported.
           • Matching label: enter the label key and value, and the system automatically selects the pods that contain this label. If multiple labels are entered, a pod is selected only when it contains all these labels.
           • Matching label expression: enter the key, value and operator of the label expression, and the system automatically selects the pods that match this label expression. If multiple label expressions are entered, a pod is selected only when it matches all these label expressions.
             Note: If no selection is made manually, the current pod is scheduled to the same node as any pod under the selected namespace.
   • Pod anti-affinity: optional. Set the anti-affinity among the pods under the current workload, or the anti-affinity between the current workload and the pods of other workloads, to specify whether they are scheduled to different nodes.
   • Add Type: two ways of adding affinity are supported: basic and advanced.
     • If you select the basic way, set the following parameters:
       • Workload: select a workload. The current workload or another workload can be selected.
         • Selecting the current workload means that the pods under the current workload are scheduled to different nodes.
         • Selecting another workload means that the pods under the current workload and the pods under the specified workload are scheduled to different nodes.
     • If you select the advanced way, set the following parameters:
       • Affinity policy: select the affinity policy. Two policies are supported: Required and Preferred.
         • Required: this anti-affinity must be satisfied.
         • Preferred: this anti-affinity is satisfied as much as possible. When it cannot be satisfied, some pods may be scheduled to the same node.
       • Weight: set the anti-affinity weight. This parameter needs to be set when the affinity policy is Preferred.
       • Namespace: select a namespace. After the selection, you can set the anti-affinity between the pods of the current workload and the pods under this namespace.
       • Namespace selector: you can also select namespaces with the namespace selector, which supports selecting by label or by label expression.
         • Matching label: enter the label key and value, and the system automatically selects the namespaces that contain this label. If multiple labels are entered, a namespace is selected only when it contains all these labels.
         • Matching label expression: enter the key, value and operator of the label expression, and the system automatically selects the namespaces that match this label expression. If multiple label expressions are entered, a namespace is selected only when it matches all these label expressions.
         Note: If you neither select a namespace manually nor match namespaces with the namespace selector, the system selects the namespace of the current workload by default.
       • Pod selector: used to select pods. The pods under the current namespace are scheduled to different nodes from the pods selected here. Selecting by label or by label expression is supported.
         • Matching label: enter the label key and value, and the system automatically selects the pods that contain this label. If multiple labels are entered, a pod is selected only when it contains all these labels.
         • Matching label expression: enter the key, value and operator of the label expression, and the system automatically selects the pods that match this label expression. If multiple label expressions are entered, a pod is selected only when it matches all these label expressions.
           Note: If no selection is made manually, the current pod is not scheduled to the same node as any pod under the selected namespace.
   • Toleration: optional. Set the toleration policy of the workload pods for node taints. After it is set, the pods are allowed to be scheduled to nodes that have taints.
     • Key: enter the key of the taint to be tolerated. If it is left blank, all taint keys are matched by default.
     • Action: select the taint matching method. If you select Equal, the value and the effect of the taint need to be matched further. If you select Exist, the effect of the taint needs to be matched further.
     • Value: enter the value of the taint to be tolerated. This parameter needs to be set only when Action is Equal.
     • Effect: enter the taint effect to be tolerated. Enter the effect that is consistent with the actual configuration of the taint. A taint may be configured with the following effects:
       • NoSchedule: the system does not schedule pods to this node, unless a pod is configured with a toleration policy that matches this taint and taint effect. The pods that have already been scheduled to this node are not evicted.
       • PreferNoSchedule: the system tries to avoid scheduling pods to this node, unless a pod is configured with a toleration policy that matches this taint and taint effect. This effect cannot completely prevent pods from being scheduled to this node.
       • NoExecute: the system does not schedule pods to this node, and evicts the existing pods on this node after the configured toleration seconds expire, unless a pod is configured with a toleration policy that matches this taint and taint effect.
     • Toleration seconds: this parameter needs to be set when the toleration effect is NoExecute. The existing pods on the tainted node are evicted after the toleration seconds expire. Unit: second.
       Note:

       • If it is not set, the taint can be tolerated forever by default, and the existing pods on this node are not evicted.
       • If it is set to 0 or a negative number, the existing pods on this node are evicted immediately.
   • Service Name: the workload name by default, which can be modified to another value. This parameter is supported only when the workload type is StatefulSet. Validation rules: the input must be 1-63 characters in length, can contain only lowercase letters, digits and the special character "-", and must start with a lowercase letter and end with a digit or a lowercase letter.
     Note: The service name refers to serviceName. This field must be configured if a Headless service is to be used, and the name of the Headless service must be consistent with the value of this field.
   • Network Configuration: optional. Set the network used by the workload. The native Kubernetes container network is used by default.
     • Use HostNetwork: optional. Enable hostNetwork, and the pods share the network with the host and occupy host ports.
       Note:

       1. When hostNetwork is enabled, make sure that the number of replicas does not exceed the total number of cluster nodes, to avoid pod startup failures caused by port conflicts.
       2. Network policies do not take effect on pods that use hostNetwork.
     • Network Type: select the network type. Three types are supported: pod network only, pod external network only, and pod network and external network.
       Note:

       • The pod network refers to the native Kubernetes container network and supports access only within the Kubernetes cluster.
       • The pod external network supports direct access to the pod IP address from outside the Kubernetes cluster.
       • When the network type of the workload is pod external network only, services of the LoadBalancer type are not supported.
       • Microservice governance is supported only when the network type of the workload is pod network only.
     • Pod External Network: when the network type is pod external network only, or pod network and external network, select the pod external network segment to be used.
   • Update Policy: optional. Set the policy for workload updates. Different types of workloads require different parameters to be set.
     • When the workload type is Deployment, the parameters are as follows:
       • Update Type: select the update method of the workload. Optional values: RollingUpdate, Recreate.
       • MaxSurge: optional. Set the maximum number or percentage of pod replicas allowed to exceed the desired number during the update, that is, maxSurge. The default value is 25%. Optional units: %, Count. This parameter can be set when the update method is RollingUpdate.
       • MaxUnavailable: optional. Set the maximum number or percentage of unavailable pod replicas allowed during the update, that is, maxUnavailable. The default value is 25%. Optional units: %, Count. This parameter can be set when the update method is RollingUpdate.
         Note: MaxSurge and MaxUnavailable cannot both be set to 0.
       • MinReadySeconds: set the minimum waiting time for a pod to be considered available after it is ready, that is, minReadySeconds. Unit: second.
       • ProgressDeadlineSeconds: the timeout period to wait for the update to proceed before marking the Deployment as failed, that is, progressDeadlineSeconds. The default value is 600 seconds.
         Note: The ProgressDeadlineSeconds must be greater than the MinReadySeconds.
       • Historical Versions to Retain: set the number of historical versions of the workload to retain. The default value is 10. Historical versions of the workload can be viewed on the workload details page.
     • When the workload type is StatefulSet, the parameters are as follows:
       • Update Type: select the update method of the workload. Optional values: RollingUpdate, OnDelete.
       • Partition: that is, partition. Optional. If a partition is set, only the pods with ordinals greater than or equal to the partition are updated when the StatefulSet is updated. This parameter can be set when the update method is RollingUpdate.
         Note: If the partition is set to a value greater than the number of replicas of the StatefulSet, the StatefulSet is not updated.
       • PodManagementPolicy: that is, podManagementPolicy. Optional. It defines the policy for scaling pods during scaling operations. Optional values: OrderedReady, Parallel.
       • Historical Versions to Retain: set the number of historical versions of the workload to retain. The default value is 10. Historical versions of the workload can be viewed on the workload details page.
     • When the workload type is DaemonSet, the parameters are as follows:
       • Update Type: select the update method of the workload. Optional values: RollingUpdate, OnDelete.
       • MaxSurge: set the maximum number or percentage of pod replicas allowed to exceed the desired number during the update, that is, maxSurge. The default value is 0 Count. Optional units: %, Count. This parameter must be set when the update method is RollingUpdate.
       • MaxUnavailable: set the maximum number or percentage of unavailable pod replicas allowed during the update, that is, maxUnavailable. The default value is 1 Count. Optional units: %, Count. This parameter must be set when the update method is RollingUpdate.
         Note: Only one of MaxSurge and MaxUnavailable must be set to 0, and the other cannot be 0.
       • MinReadySeconds: set the minimum waiting time for a pod to be considered available after it is ready, that is, minReadySeconds. Unit: second.
       • Historical Versions to Retain: set the number of historical versions of the workload to retain. The default value is 10. Historical versions of the workload can be viewed on the workload details page.
5. Confirming information

   View the workload to be created. You can jump back to modify it.

In the ZStack Zaku main menu, click Container Orchestration > Application Management > Workload to enter the Workload page.

Workloads support the following operations:

Operation	Description
Create workload	Create a new workload.
Modify workload	Update the workload configuration using a form.
Update image	Update the container image of the workload.
Update Yaml	Update the workload configuration using Yaml.
Restart workload	Restart the workload. Note: After the restart, the system creates new pods for the workload according to the update policy and deletes the current pods. This process may interrupt your business, so proceed with caution. If the workload is of the Deployment type and has an exclusive disk PVC mounted, restart it by manually deleting the pods under it.
Change the number of replicas	Manually adjust the number of replicas of the workload. Note: Only workloads of the Deployment and StatefulSet types support changing the number of replicas. If auto scaling is enabled for the workload, a manually changed number of replicas may soon be overridden by the auto scaling policy. To take over manually, first disable auto scaling on the Auto Scaling page of the workload details.
Auto scaling	Automatically adjust the number of replicas of the workload according to scaling rules. When the workload auto-scaling component is not deployed, auto scaling based on two trigger metrics, CPU target utilization rate and memory target utilization rate, is supported. After the workload auto-scaling component is deployed, three types of scaling rules are supported: resource metrics, scheduled policies and Prometheus metrics. For details, see Auto Scaling. Note: Only workloads of the Deployment and StatefulSet types support auto scaling.
Workload details	Go to the workload details page to view the basic information, pods, version history and events of the workload, as well as other related resources such as services and PVCs.
Roll back workload	Roll back the workload to a specified version. The system rebuilds the workload according to the configuration of the version rolled back to. Note: To perform this operation, go to the workload details page and click History Version > Action > Rollback.
Delete workload	Delete the workload from the cluster.
Export workload information	Export workload information to a CSV file. You can export the current page or all pages.

Auto scaling automatically adjusts the number of replicas of a workload according to scaling rules. It applies to scenarios where the business load fluctuates with traffic or where peak and off-peak hours are fixed. After the workload auto-scaling component is deployed in a cluster, the Auto Scaling tab is displayed on the workload details page, where automatic scaling of the workload can be managed in a unified way through three types of scaling rules: resource metrics, scheduled policies and Prometheus metrics.

Note:

• The Auto Scaling tab is displayed only for self-built clusters in which the workload auto-scaling component has been deployed successfully. It is not displayed when the component is not deployed or not ready, and it is not displayed for integrated clusters.
• Only workloads of the Deployment and StatefulSet types support auto scaling.
• Each workload supports only one auto scaling configuration. When an auto scaling configuration already exists, the Create Auto Scaling button is greyed out.
• If auto scaling had already been configured for a workload through the platform before the workload auto-scaling component was deployed in the cluster, the system prompts for migration confirmation the first time you enter the Auto Scaling tab or click the Auto Scaling button. After you confirm, the system retains the original range of replicas and scaling rules and upgrades the configuration. After the migration is complete, the configuration can be managed in a unified way on the Auto Scaling tab.

Managing Auto Scaling

On the Auto Scaling tab of the workload details page, you can view the status, type, range of replicas, current number of replicas and last scaling time of the auto scaling configuration. The status of auto scaling can be Enabled, Synchronizing, Disabled, Abnormal, Conflict or Unknown.

Auto scaling supports the following operations:

Operation	Description
Create auto scaling	Create an auto scaling configuration for the current workload. Note: Each workload supports only one auto scaling configuration. When an auto scaling configuration already exists, it cannot be created again.
Modify auto scaling	Modify the auto scaling configuration. All fields except the name, namespace and type can be modified, and the field validation logic is the same as for creating auto scaling. Note: After all added scaling rules are deleted, the modification cannot be submitted.
Update Yaml	Update the auto scaling configuration using Yaml.
Enable	Enable auto scaling. After it is enabled, the system automatically adjusts the number of replicas according to the configured scaling rules, and the number of replicas may change the next time a scaling rule is triggered.
Disable	Disable auto scaling. After it is disabled, the system stops adjusting the number of replicas automatically according to the scaling rules and keeps running with the current actual number of replicas. The configured scaling rules are not deleted and can be enabled again later.
Delete auto scaling	Delete the auto scaling configuration. After the deletion, the number of replicas of the workload is no longer adjusted automatically. Note: When a workload is deleted, its auto scaling configuration is deleted at the same time.

A job processes short-lived workloads in batches and ensures that one or more pods used for batch processing terminate successfully. Jobs include one-time jobs and scheduled jobs.

In the ZStack Zaku main menu, click Container Orchestration > Application Management > Job to enter the Job page. Click Create Job and the Create Job page is displayed.

In the ZStack Zaku main menu, click Container Orchestration > Application Management > Job to enter the Job page.

Jobs support the following operations:

Operation	Description
Create job	Create a new job.
Update Yaml	Update the job using Yaml. Note: Only scheduled jobs (CronJob) support updates.
Enable job	Enable a disabled job. Note: Only scheduled jobs (CronJob) support being enabled.
Disable job	Disable an enabled job. Note: Only scheduled jobs (CronJob) support being disabled.
Job details	Go to the job details page to view the job overview, execution records, pod information and other related resources such as PVCs.
Delete job	Delete the job from the cluster.

A pod is the smallest unit of cluster scheduling and management. Containers in the same pod share the same network and storage. Usually only one container runs in a pod, but when multiple containers need to work together and share resources, multiple containers may run in one pod.

In ZStack Zaku, pods actually run your applications and are managed by workloads or jobs. In practice, you create the corresponding pods while creating a workload or a job, and rarely create pods directly.

In the ZStack Zaku main menu, click Container Orchestration > Application Management > Pod to enter the Pod page.

Pods support the following operations:

Operation	Description
View Yaml	View the Yaml of the pod.
Open web terminal	Enter the container terminal.
View monitoring	Jump to the pod monitoring page of the monitoring panel, with the cluster, namespace and pod of the current pod automatically selected.
View logs	Jump to the container logs, which can be exported and saved locally.
Pod details	Go to the pod details page to view the basic information, requested resources, monitoring data, container list and events of the pod, as well as other related resources such as volumes.
Save container as an image	Generate an image based on the current container and upload it to a repository. Note: To perform this operation, go to the pod details page and click Container > Action > Save as an Image. Only running images support this operation.
Delete pod	Delete the pod. A pod created directly is deleted permanently. After a pod created by a workload or a job is deleted, a new pod is created automatically. In this case, the delete operation is equivalent to restarting the pod.
Export pod information	Export pod information to a CSV file. You can export the current page or all pages.