Upgrading a Workload

You can upgrade a workload after you create it. Currently, rolling upgrade and in-place upgrade are supported.
  • 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, choose Workloads > Deployments. On the page displayed on the right, click the name of the workload you want to upgrade. Then, click Upgrade in the upper right corner of the workload details page.
  2. Modify pod specifications.

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

    Currently, three types of pods are provided, including general-computing (used in general-computing namespaces), RDMA-accelerated, and GPU-accelerated (used in GPU-accelerated namespaces).

    GPU-accelerated pods support the following GPUs: NVIDIA Tesla V100 32GB and NVIDIA Tesla V100 16GB.
    • Specifications of NVIDIA Tesla V100 32GB are as follows:
      • NVIDIA Tesla V100 32GB x 1, 4 CPU cores, 32 GB memory
      • NVIDIA Tesla V100 32GB x 2, 8 CPU cores, 64 GB memory
      • NVIDIA Tesla V100 32GB x 4, 16 CPU cores, 128 GB memory
      • NVIDIA Tesla V100 32GB x 8, 32 CPU cores, 256 GB memory
    • Specifications of NVIDIA Tesla V100 16GB are as follows:
      • NVIDIA Tesla V100 16GB x 1, 4 CPU cores, 32 GB memory
      • NVIDIA Tesla V100 16GB x 2, 8 CPU cores, 64 GB memory
      • NVIDIA Tesla V100 16GB x 4, 16 CPU cores, 128 GB memory
      • NVIDIA Tesla V100 16GB x 8, 32 CPU cores, 256 GB memory
    If the pod type is not GPU-accelerated, the container specifications you select must meet the following requirements:
    • The total number of CPU cores in a pod can be a value in the range of 0.25-32, 48, or 64. The total number of CPU cores in a container is an integer multiple of 0.25.
    • The total memory size (in GB) of a pod is an integer from 1 to 512.
    • The ratio of CPU cores to memory size in a pod ranges from 1:2 to 1:8.
    • A pod can have a maximum of five containers. The minimum configuration of a container is 0.25 cores and 0.2 GB. The maximum configuration of a container is the same as that of a pod.

  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 and CPU and memory specifications (the minimum configuration of a single container is 0.25 cores and 0.2 GB). You can also enable the collection of standard output files. If you enable file collection, you will be billed for Application Operations Management (AOM) according to the log storage space you use.

      AOM provides each account 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 Pricing Details.

      Only one container in a pod can use GPUs. If there are multiple containers in your pod, you can enable the GPU option and specify the container that can use GPUs.

      You can also configure the following advanced settings for a container:

      • Storage: You can mount persistent volumes to containers. Currently, EVS, SFS, and SFS Turbo volumes are supported. Click the EVS Volumes, SFS 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, SFS Volumes, or SFS Turbo Volumes.

        Currently, SFS Turbo volumes are unavailable in region CN East-Shanghai1.

      • 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 Upgrading a Deployment in Deployment.