Updated on 2024-10-29 GMT+08:00

Upgrading a Workload

You can upgrade a workload after you create it. There are two ways to upgrade a workload.
  • Rolling upgrade: Gradually replaces an old pod with a new pod. During the upgrade, service traffic is evenly distributed to the old and new pods to ensure service continuity.
  • In-place upgrade: Deletes an old pod and then creates a new one. Services will be interrupted during the upgrade.

Upgrading a Workload

  1. Log in to the CCI console. In the navigation pane on the left, choose Workloads > Deployments. On the page displayed, click the target workload. In the upper right corner of the workload details page, click Upgrade.
  2. Modify 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 "Constraints on Pod Specifications" in the Notes and Constraints.

  3. Modify container settings.

    1. Click Change Image to select a new image.
      Figure 1 Changing the image
      • My Images: images you have uploaded to SWR
      • Open Source Images: displays public images in the image center.
      • Shared Images: images shared by others through SWR
    2. Select the image version and set the container name, vCPU, and memory. 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.

      AOM provides each account with 500-MB log storage space for free each month. You will be billed for any extra space you use on a pay-per-use basis. For details, see Product Pricing Details.

      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. Click the EVS Volumes or SFS Turbo Volumes tab, and set the volume name, capacity, container path, and disk type. After the workload 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.

      • Health Check: Container health can be checked regularly when the container is running. For details about how to configure health checks, 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.

  4. Click Next and select an upgrade policy.

    Two options are available: Rolling upgrade and In-place upgrade.
    • Rolling upgrade: Gradually replaces an old pod with a new pod. During the upgrade, service traffic is evenly distributed to the old and new pods to ensure service continuity.

      Maximum Number of Unavailable Pods: Maximum number of unavailable pods allowed in a rolling upgrade. If the number is equal to the total number of pods, services may be interrupted. Minimum number of alive pods = Total pods – Maximum number of unavailable pods

    • In-place upgrade: Deletes an old pod and then creates a new one. Services will be interrupted during the upgrade.

  5. Click Next and then Submit.

Upgrading a Workload Using kubectl

For details about how to use kubectl to upgrade a workload, see Upgrade in Deployment.