Pulling an Image to Deploy an Application in a CCE Cluster
You can use an image to quickly deploy a single-pod workload that can be accessed over the Internet. This section describes how to use an image to quickly deploy Nginx in a CCE cluster.
Prerequisites
- This is your first time to enable CCE and perform authorization.
- For details, see .
- You have created a cluster.
- For details, see .
- Create a node pool and nodes in the cluster.
- For details, see .
- The cluster contains at least one node with 4 CPU cores and 8 GiB of memory.
- An EIP has been bound to a node in the cluster.
Creating and Accessing a Workload
You can use the CCE console or kubectl to deploy a workload. In this example, an NGINX image is used.
- In the navigation pane, choose Workloads. In the right pane, click Create Workload in the upper right corner.
- Configure the basic information for the workload. In this example, configure the parameters shown in the table and keep the default settings for other parameters. For more details, see Creating a Deployment.
Parameter
Example
Description
Workload Type
Deployment
A workload is an application running on Kubernetes. Various built-in workload types are available, each designed for different functions and scenarios. For more details, see Workload Overview.
Workload Name
nginx
Enter a workload name.
Namespace
default
In Kubernetes, a namespace is a conceptual grouping of resources or objects, providing isolation from other namespaces.
After a cluster is created, a namespace named default is generated by default. You can use this namespace directly.
Pods
1
Specify the number of pods for the workload.
- Configure container parameters.
Configure the parameters shown in the table and keep the default settings for other parameters.

Parameter
Example
Description
Image Name
nginx (latest version)
Click Select Image. In the displayed dialog box, click the Open Source Images tab and select a public image.
CPU Quota
Request: 0.25 cores
Limit: 0.25 cores
- Request: the number of CPU cores pre-allocated to containers. The default value is 0.25 cores.
- Limit: the maximum number of CPU cores that containers can use. The default value is the same as the Request. If Limit exceeds Request, containers can temporarily use more resources in burst scenarios.
For details, see Configuring Container Specifications.
Memory Quota
Request: 512 MiB
Limit: 512 MiB
- Request: the memory pre-allocated to containers. The default value is 512 MiB.
- Limit: the maximum amount of memory that containers can use. The default value is the same as the Request. If Limit exceeds Request, containers can temporarily use more resources in burst scenarios.
For details, see Configuring Container Specifications.
- Configure access settings.
In the Service Settings area, click the plus sign (+) and create a Service for external network access to the workload. This example shows how to create a LoadBalancer Service. Configure the below parameters in the sliding window on the right.

Parameter
Example
Description
Service Name
nginx
Specify the Service name.
Service Type
LoadBalancer
Select a Service type. The Service type refers to the Service access mode. For details about the differences between Service types, see Service Overview.
Load Balancer
- Type: Dedicated
- AZ: at least one AZ, for example, AZ1
- EIP: Auto create
Keep the default settings for other parameters.
Select Use existing if a load balancer is available.
If there is no load balancer available, select Auto create to create one and bind an EIP to it. For details, see Creating a LoadBalancer Service.
Ports
- Protocol: TCP
- Container Port: 80
- Service Port: 8080
- Protocol: applies to the load balancer listener.
- Container Port: The port that the containerized application listens on. This value must be the same as the listening port provided by the application for external access. If the nginx image is used, set this parameter to 80.
- Service Port: The port used by the load balancer to create a listener and provide an entry for external access. You can change this port if necessary.
- Click Create Workload.
Wait until the workload is created. The created workload in the Running state will be displayed on the Deployments tab.
Figure 1 Workload created
- Obtain the external access address of Nginx. Click the name of the nginx workload to go to its details page. On the page displayed, click the Access Mode tab, view the Nginx IP address. The public IP address is the external access address.Figure 2 Obtaining the external access address
- In the address bar of a browser, enter <external-access-address>:service-port to access the application. The value of service-port is the same as the service port specified in 4. In this example, it is 8080. Figure 3 Accessing Nginx
If you use kubectl to access the cluster, prepare an ECS that has been bound with an EIP in the same VPC as the cluster.
- Log in to the target ECS. For details, see Login Overview (Linux).
- Install kubectl on the ECS.
You can check whether kubectl has been installed by running kubectl version. If kubectl has been installed, you can skip this step.
The Linux environment is used as an example to describe how to install and configure kubectl. For more installation methods, see kubectl.
- Download kubectl.
cd /home curl -LO https://dl.k8s.io/release/{v1.29.0}/bin/linux/amd64/kubectl{v1.29.0} specifies the version. You can replace it as required.
- Install kubectl.
chmod +x kubectl mv -f kubectl /usr/local/bin
- Download kubectl.
- Configure a credential for kubectl to access the Kubernetes cluster.
- Log in to the CCE console and click the cluster name to access the cluster console. Choose Overview in the navigation pane.
- On the page displayed, locate the Connection Information area, click Configure next to kubectl, and view the kubectl connection information.
- In the window that slides out from the right, locate the Download the kubeconfig file area, select Intranet access for Current data, and download the corresponding configuration file.
- Log in to the VM where the kubectl client has been installed and copy and paste the configuration file (for example, kubeconfig.yaml) downloaded in the previous step to the /home directory.
- Save the kubectl authentication file to the configuration file in the $HOME/.kube directory.
cd /home mkdir -p $HOME/.kube mv -f kubeconfig.yaml $HOME/.kube/config - Run the kubectl command to see whether the cluster can be accessed.
For example, to view the cluster information, run the following command:
kubectl cluster-info
Information similar to the following is displayed:
Kubernetes master is running at https://*.*.*.*:5443 CoreDNS is running at https://*.*.*.*:5443/api/v1/namespaces/kube-system/services/coredns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
- Create a YAML file named nginx-deployment.yaml. nginx-deployment.yaml is an example file name. You can rename it as required.
vi nginx-deployment.yaml
The file content is as follows:
apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx:alpine name: nginx imagePullSecrets: - name: default-secret - Run the following command to deploy the workload:
kubectl create -f nginx-deployment.yaml
If information similar to the following is displayed, the workload is being created:
deployment "nginx" created
- Run the following command to check the workload status:
kubectl get deployment
If information similar to what is shown here is displayed, the workload has been created:
NAME READY UP-TO-DATE AVAILABLE AGE nginx 1/1 1 1 4m5s
The parameters in the command output are described as follows:
- NAME: specifies the name of a workload.
- READY: indicates the number of available pods/expected pods for the workload.
- UP-TO-DATE: specifies the number of pods that have been updated for the workload.
- AVAILABLE: specifies the number of pods available for the workload.
- AGE: specifies how long the workload has run.
- Create a YAML file named nginx-elb-svc.yaml and change the value of selector to that of matchLabels (app: nginx in this example) in the nginx-deployment.yaml file to associate the Service with the backend application.
vi nginx-elb-svc.yaml
An example is shown below. For details about the parameters in the following example, see Using kubectl to Create a Service (Automatically Creating a Load Balancer).apiVersion: v1 kind: Service metadata: annotations: kubernetes.io/elb.class: union kubernetes.io/elb.autocreate: '{ "type": "public", "bandwidth_name": "cce-bandwidth", "bandwidth_chargemode": "bandwidth", "bandwidth_size": 5, "bandwidth_sharetype": "PER", "eip_type": "5_bgp" }' labels: app: nginx name: nginx spec: ports: - name: service0 port: 8080 protocol: TCP targetPort: 80 selector: app: nginx type: LoadBalancer - Run the following command to create the Service:
kubectl create -f nginx-elb-svc.yaml
If information similar to the following is displayed, the Service has been created:
service/nginx created
- Run the following command to check the Service:
kubectl get svc
If information similar to the following is displayed, the access type has been configured, and the workload is accessible:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.247.0.1 <none> 443/TCP 3d nginx LoadBalancer 10.247.130.196 **.**.**.** 8080:31540/TCP 51s
- Enter the URL (for example, **.**.**.**:8080) in the address bar of a browser. **.**.**.** specifies the EIP of the load balancer, and 8080 indicates the access port. Figure 4 Accessing Nginx using the LoadBalancer Service
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.