doc-exports/docs/cce/umn/cce_10_0047.html

Creating a Deployment

Scenario

Deployments are workloads (for example, Nginx) that do not store any data or status. You can create Deployments on the CCE console or by running kubectl commands.

Prerequisites

• Before creating a containerized workload, you must have an available cluster. For details on how to create a cluster, see Creating a CCE Cluster.
• To enable public access to a workload, ensure that an EIP or load balancer has been bound to at least one node in the cluster.
  

  If a pod has multiple containers, ensure that the ports used by the containers do not conflict with each other. Otherwise, creating the Deployment will fail.

Using the CCE Console

1. Log in to the CCE console.
2. Click the cluster name to access the cluster details page, choose Workloads in the navigation pane, and click the Create Workload in the upper right corner.
3. Set basic information about the workload.
   Basic Info

   • Workload Type: Select Deployment. For details about workload types, see Overview.
   • Workload Name: Enter the name of the workload. Enter 1 to 63 characters starting with a lowercase letter and ending with a letter or digit. Only lowercase letters, digits, and hyphens (-) are allowed.
   • Namespace: Select the namespace of the workload. The default value is default. You can also click Create Namespace to create one. For details, see Creating a Namespace.
   • Pods: Enter the number of pods.
   • Container Runtime: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see Kata Containers and Common Containers.
   • Time Zone Synchronization: Specify whether to enable time zone synchronization. After time zone synchronization is enabled, the container and node use the same time zone. The time zone synchronization function depends on the local disk mounted to the container. Do not modify or delete the time zone. For details, see Configuring Time Zone Synchronization.
   Container Settings

   • Container Information
     Multiple containers can be configured in a pod. You can click Add Container on the right to configure multiple containers for the pod.

     • Basic Info: See Setting Basic Container Information.
     • Lifecycle: See Setting Container Lifecycle Parameters.
     • Health Check: See Setting Health Check for a Container.
     • Environment Variables: See Setting an Environment Variable.
     • Data Storage: See Overview.
       

       If the workload contains more than one pod, EVS volumes cannot be mounted.

     • Security Context: Set container permissions to protect the system and other containers from being affected. Enter the user ID to set container permissions and prevent systems and other containers from being affected.
     • Logging: See Using ICAgent to Collect Container Logs.
   • Image Access Credential: Select the credential used for accessing the image repository. The default value is default-secret. You can use default-secret to access images in SWR. For details about default-secret, see default-secret.
   • GPU graphics card: All is selected by default. The workload instance will be scheduled to the node with the specified GPU graphics card type.

   Service Settings

   A Service is used for pod access. With a fixed IP address, a Service forwards access traffic to pods and performs load balancing for these pods.

   You can also create a Service after creating a workload. For details about the Service, see Service Overview.

   Advanced Settings

   • Upgrade: See Configuring the Workload Upgrade Policy.
   • Scheduling: See Scheduling Policy (Affinity/Anti-affinity).
   • Labels and Annotations: See Pod Labels and Annotations.
   • Toleration: 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 Tolerations.
   • DNS: See DNS Configuration.

4. Click Create Workload in the lower right corner.

Using kubectl

The following procedure uses Nginx as an example to describe how to create a workload using kubectl.

1. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
2. Create and edit the nginx-deployment.yaml file. nginx-deployment.yaml is an example file name. You can rename it as required.

   vi nginx-deployment.yaml

   The following is an example YAML file. For more information about Deployments, see Kubernetes documentation.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: nginx
     strategy:
       type: RollingUpdate
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - image: nginx    # If you use an image in My Images, obtain the image path from SWR.
           imagePullPolicy: Always
           name: nginx
         imagePullSecrets:
         - name: default-secret

   For details about these parameters, see Table 1.

   Table 1 Deployment YAML parameters

   Parameter	Description	Mandatory/Optional
   apiVersion	API version. NOTE: Set this parameter based on the cluster version. For clusters of v1.17 or later, the apiVersion format of Deployments is apps/v1. For clusters of v1.15 or earlier, the apiVersion format of Deployments is extensions/v1beta1.	Mandatory
   kind	Type of a created object.	Mandatory
   metadata	Metadata of a resource object.	Mandatory
   name	Name of the Deployment.	Mandatory
   Spec	Detailed description of the Deployment.	Mandatory
   replicas	Number of pods.	Mandatory
   selector	Determines container pods that can be managed by the Deployment.	Mandatory
   strategy	Upgrade mode. Possible values: RollingUpdate ReplaceUpdate By default, rolling update is used.	Optional
   template	Detailed description of a created container pod.	Mandatory
   metadata	Metadata.	Mandatory
   labels	metadata.labels: Container labels.	Optional
   spec: containers	image (mandatory): Name of a container image. imagePullPolicy (optional): Policy for obtaining an image. The options include Always (attempting to download images each time), Never (only using local images), and IfNotPresent (using local images if they are available; downloading images if local images are unavailable). The default value is Always. name (mandatory): Container name.	Mandatory
   imagePullSecrets	Name of the secret used during image pulling. If a private image is used, this parameter is mandatory. To pull an image from the Software Repository for Container (SWR), set this parameter to default-secret. To pull an image from a third-party image repository, set this parameter to the name of the created secret.	Optional

3. Create a Deployment.

   kubectl create -f nginx-deployment.yaml

   If the following information is displayed, the Deployment is being created.

   deployment "nginx" created

4. Query the Deployment status.

   kubectl get deployment

   If the following information is displayed, the Deployment is running.

   NAME           READY     UP-TO-DATE   AVAILABLE   AGE 
   nginx          1/1       1            1           4m5s

   Parameter description

   • NAME: Name of the application running in the pod.
   • READY: indicates the number of available workloads. The value is displayed as "the number of available pods/the number of expected pods".
   • UP-TO-DATE: indicates the number of replicas that have been updated.
   • AVAILABLE: indicates the number of available pods.
   • AGE: period the Deployment keeps running

5. If the Deployment will be accessed through a ClusterIP or NodePort Service, add the corresponding Service. For details, see Networking.

Parent topic: Workloads