Deployments

Basic Concepts

• Deployments: Pods are completely independent of each other and functionally identical. They feature auto scaling and rolling upgrade. Typical examples include Nginx and WordPress. For details on how to create a Deployment, see Creating a Deployment.
• StatefulSets: Pods are not completely independent of each other. They have stable persistent storage and network identifiers, and feature orderly deployment, scale-in, and deletion. For example, MySQL-HA and etcd. For details on how to create a StatefulSet, see Creating a StatefulSet.
• DaemonSets: A DaemonSet runs a pod on each node in a cluster and ensures that there is only one pod. This works well for certain system-level applications, such as log collection and resource monitoring. For details on how to create a DeamonSet, see Creating a DaemonSet.

Relationship Between Workloads and Containers

As shown in Figure 1, a workload controls one or more pods. A pod consists of one or more containers. Each container is created from a container image. Pods of Deployments are exactly the same.

Figure 1 Relationship between workloads and containers

Workload Lifecycle

Creating a Deployment

1. (Optional) If you create a workload using the image pulled from SWR, first upload your image to SWR. For details about how to upload an image, see Image Management. If you create a workload using an open source image, you do not need to upload the image to SWR.
2. On the cluster details page, choose Workloads > Deployments and click Create from Image.
3. Set basic workload parameters as described in Table 2. The parameters marked with an asterisk (*) are mandatory.

   Table 2 Basic workload parameters

   Parameter	Description
   *Workload Name	Name of a workload, which must be unique.
   Cluster Name	Cluster to which the workload belongs. You do not need to set this parameter.
   *Namespace	In a single cluster, data in different namespaces is isolated from each other. This enables applications to share the Services of the same cluster without interfering each other. If no namespace is set, the default namespace is used.
   *Pods	Number of pods in the workload. A workload can have one or more pods. You can set the number of pods. The default value is 2 and can be set to 1. Each workload pod consists of the same containers. Configuring multiple pods for a workload ensures that the workload can still run properly even if a pod is faulty. If only one pod is used, a node or pod exception may cause service exceptions.
   Description	Description of the workload.
   Time Zone Synchronization	If this parameter is enabled, the containers and the node use the same time zone, and disks of the hostPath type will be automatically added and listed in the Data Storage > Local Volumes area. Do not modify or delete the disks.

4. Configure the container settings for the workload.
   Multiple containers can be configured in a pod. You can click Add Container on the right to configure multiple containers for the pod.

   Figure 2 Container settings
   

   • Container Information: Click Add Container on the right to configure multiple containers for the pod.
     • Basic Info: See Table 3.

       Table 3 Basic information parameters

       Parameter	Description
       Container Name	Name the container.
       Image Name	Click Select Image and select the image used by the container. My Images: images in the image repository of the current region. If no image is available, click Upload Image to upload an image. Open Source Images: official images in the open source image repository. Shared Images: private images shared by another account. For details, see Sharing Private Images.
       Image Tag	Select the image tag to be deployed.
       Pull Policy	Image update or pull policy. If you select Always, the image is pulled from the image repository each time. If you do not select Always, the existing image of the node is preferentially used. If the image does not exist in the node, it is pulled from the image repository.
       CPU Quota	Request: minimum number of CPU cores required by a container. The default value is 0.25 cores. Limit: maximum number of CPU cores available for a container. Do not leave Limit unspecified. Otherwise, intensive use of container resources will occur and your workload may exhibit unexpected behavior.
       Memory Quota	Request: minimum amount of memory required by a container. The default value is 512 MiB. Limit: maximum amount of memory available for a container. When memory usage exceeds the specified memory limit, the container will be terminated. For details about Request and Limit of CPU or memory, see Setting Container Specifications.
       Init Container	Select whether to use the container as an init container. An init container is a special container that runs before app containers in a pod. For details, see Init Containers.
       Privileged Container	Programs in a privileged container have certain privileges. If Privileged Container is enabled, the container is assigned privileges. For example, privileged containers can manipulate network devices on the host machine and modify kernel parameters.

     • Lifecycle: The lifecycle callback functions can be called in specific phases of the container. For example, if you want the container to perform a certain operation before stopping, set the corresponding function. Currently, lifecycle callback functions, such as startup, post-start, and pre-stop are provided. For details, see Setting Container Lifecycle Parameters.
     • Health Check: Set health check parameters to periodically check the health status of the container during container running. For details, see Setting Health Check for a Container.
     • Environment Variable: Environment variables affect the way a running container will behave. Configuration items set by environment variables will not change if the pod lifecycle ends. For details, see Setting Environment Variables.
     • Data Storage: Store container data using Local Volumes and PersistentVolumeClaims (PVCs). You are advised to use PVCs to store workload pod data on a cloud volume. If you store pod data on a local volume and a fault occurs on the node, the data cannot be restored. For details about container storage, see Container Storage.
     • Security Context: Set container permissions to protect the system and other containers from being affected. Enter a user ID and the container will run with the user permissions you specify.

   • Image Access Credential: Select the credential for accessing the image repository. This credential is used only for accessing a private image repository. If the selected image is a public image, you do not need to select a secret. For details on how to create a secret, see Creating a Secret.

5. (Optional) Click in the Service Settings area to configure a Service for the workload.

   If your workload will be reachable to other workloads or public networks, add a Service to define the workload access type. The workload access type determines the network attributes of the workload. Workloads with different access types can provide different network capabilities. For details, see Services.

   You can also create a Service after creating a workload. For details, see ClusterIP and NodePort.

   • Service Name: Name of the Service to be added. It is customizable and must be unique.
   • Service Type
     • ClusterIP: The Service is only reachable from within the cluster.
     • NodePort: The Service can be accessed from any node in the cluster.
     • LoadBalancer: The workload is accessed from the public network using a load balancer.
   • Service Affinity (for NodePort and LoadBalancer only)
     • Cluster-level: The IP addresses and access ports of all nodes in a cluster can be used to access the workloads associated with the Service. However, performance loss is introduced due to hops, and source IP addresses cannot be obtained.
     • Node-level: Only the IP address and access port of the node where the workload is located can be used to access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained.
   • Port
     • Protocol: Select TCP or UDP.
     • Service Port: Port mapped to the container port at the cluster-internal IP address. The application can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
     • Container Port: Port on which the workload listens, defined in the container image. For example, the Nginx application listens on port 80 (container port).
     • Node Port (for NodePort only): Port to which the container port will be mapped when the node private IP address is used for accessing the application. The port number range is 30000–32767. You are advised to select Auto.
       • Auto: The system automatically assigns a port number.
       • Custom: Specify a fixed node port. The port number range is 30000–32767. Ensure that the port is unique in a cluster.
   • Annotation: The key-value pair format is supported. Configure annotations based on your service and vendor requirements and then click Add.

6. (Optional) Click Expand to set advanced settings for the workload.
   • Upgrade: upgrade mode of the Deployment, including Replace upgrade and Rolling upgrade. For details, see Configuring a Workload Upgrade Policy.
     • Rolling upgrade: An old pod is gradually replaced with a new pod. During the upgrade, service traffic is evenly distributed to the old and new pods to ensure service continuity.
     • Replace upgrade: Old pods are deleted before new pods are created. Services will be interrupted during a replace upgrade.
   • Scheduling: You can set affinity and anti-affinity to implement planned scheduling for pods. For details, see Scheduling Policy (Affinity/Anti-affinity).
   • Labels and Annotations: You can click Confirm to add a label or annotation for the pod. The key of the new label or annotation cannot be the same as that of an existing one.
   • Toleration: When the node where the workload pods are located is unavailable for the specified amount of time, the pods will be rescheduled to other available nodes. By default, the toleration time window is 300s.
     • Using both taints and tolerations allows (not forcibly) the pod to be scheduled to a node with the matching taints, and controls the pod eviction policies after the node where the pod is located is tainted. For details, see Example Tutorial.
     • Click under Taints and Tolerations to add a policy. For details about related parameters, see Tolerance Policies.

7. After the configuration is complete, click Create Workload. You can view the Deployment status in the Deployment list.

   If the Deployment is in the Running status, the Deployment is successfully created.

Related Operations