Help Center/ Cloud Container Engine/ Getting Started/ Deploying an Nginx Deployment in a CCE Cluster

Updated on 2025-06-24 GMT+08:00

View PDF

Deploying an Nginx Deployment in a CCE Cluster

Deployments are a type of workload in Kubernetes. They are ideal for stateless applications, such as web and application servers, which do not require data consistency or durability. The pods in a Deployment are independent, identical, and replaceable. If a pod fails, traffic is automatically redirected to healthy pods, ensuring service continuity. You can also adjust the number of pods to dynamically adapt to service demands in real time. For instance, you may need to add pods during peak hours to handle traffic surges.

This section uses Nginx, a lightweight web server, as an example to describe how to deploy a Deployment in a CCE cluster.

Click to enlarge

Procedure

Step	Description
Preparations	Sign up for a HUAWEI ID.
Step 1: Enable CCE and Perform Authorization	Obtain the required permissions for your account when you use CCE in the deployment region for the first time.
Step 2: Create a Cluster	Create a CCE cluster to provide Kubernetes services.
Step 3: Create a Node Pool and Nodes	Create nodes in the cluster to run containerized applications.
Step 4: Create a Workload and Access It	Create a workload in the cluster to run your containers and create a Service to enable public access.
Follow-up Operations: Release Resources	Release resources promptly if the cluster is no longer needed to avoid extra charges.

Preparations

Before you start, sign up for a HUAWEI ID. For details, see Signing Up for a HUAWEI ID and Enabling Huawei Cloud Services.

Step 1: Enable CCE and Perform Authorization

When you first log in to the CCE console, CCE automatically requests permissions to access related cloud services (compute, storage, networking, and monitoring) in the region where the cluster is deployed. If you have authorized CCE in the deployment region, skip this step.

Log in to the CCE console using your HUAWEI ID.
Click in the upper left corner and select a region.
If this is your first time logging in to the CCE console in the selected region, the Authorization Statement dialog box will appear. Read it carefully and click OK.

After you agree to delegate permissions, CCE uses IAM to create an agency named cce_admin_trust. This agency is granted Tenant Administrator permissions for the resources of other cloud services (excluding IAM). These permissions are required for CCE to access dependent cloud services and are only valid for the current region. You can view the authorization records in each region by navigating to the IAM console, choosing Agencies in the navigation pane, and clicking cce_admin_trust. For more details, see Cloud Service Agency.

To ensure CCE can run normally, do not delete or modify the cce_admin_trust agency, as CCE requires Tenant Administrator permissions.

CCE has redesigned the cce_admin_trust agency permission to enhance security by taking into account the dependency on other cloud services. The new permission no longer includes the Tenant Administrator permission. This function is only available in certain regions. If the clusters under your account are of v1.21 or later versions, a message indicating a permission change will be displayed on the console, and you will need to re-grant the permission. After you re-grant the permission, the cce_admin_trust agency will be updated to include the cloud service permissions that CCE depends on, while the Tenant Administrator permission will be removed from the agency.

When you create the cce_admin_trust agency, a custom policy named CCE admin policies will be automatically created. Do not delete this policy.

Step 2: Create a Cluster

Configure basic cluster parameters.

This example describes only mandatory parameters. You can keep default settings for most other parameters. For details, see Buying a CCE Standard/Turbo Cluster.

Click to enlarge

Parameter	Example	Description
Type	CCE Standard Cluster	CCE supports multiple cluster types to meet diverse needs, including highly reliable, highly secure, commercial containers. You can select CCE Standard Cluster or CCE Turbo Cluster as required. CCE standard clusters provide highly reliable, highly secure, commercial containers. CCE Turbo clusters use high-performance cloud native networks and support cloud native hybrid scheduling. These clusters offer improved resource utilization and are suitable for a wider range of scenarios. For more details, see Comparison Between Cluster Types.
Billing Mode	Pay-per-use	Select a billing mode for the cluster. Yearly/Monthly: a prepaid billing mode. Resources are billed based on how long you will need the resources for. This mode is more cost-effective when resource usage periods are predictable. If you choose this option, select the desired duration and decide whether to enable automatic renewal (monthly or yearly). Monthly subscriptions renew automatically every month, and yearly subscriptions renew automatically every year. Pay-per-use: a postpaid billing mode. Resources are billed based on actual usage duration. This mode is suitable for flexible scenarios where you may need to provision or delete resources at any time. For more details, see Billing Modes.
Cluster Name	cce-test	Enter a name for the cluster.
Enterprise Project	default	Enterprise projects facilitate project-level management and grouping of cloud resources and users. For details, see Enterprise Center. This parameter is only displayed for enterprise users who have enabled enterprise projects.
Cluster Version	v1.29 (recommended)	Select the latest Kubernetes commercial release to benefit from new, reliable, and production-ready features. CCE offers multiple Kubernetes versions.
Cluster Scale	Nodes: 50	This parameter controls the maximum number of worker nodes the cluster can manage. Configure it as needed. After the cluster is created, it can be scaled out, but it cannot be scaled in.
Master Nodes	3 Masters	Select the number of master nodes, also known as control plane nodes. These nodes are hosted on CCE and run Kubernetes components like kube-apiserver, kube-controller-manager, and kube-scheduler. 3 Masters: Three master nodes will be created to ensure high availability. Single: Only one master node will be created in your cluster. This setting cannot be changed after the cluster is created.

Configure network parameters.

Click to enlarge

Parameter	Example	Description
VPC	vpc-001	Select a VPC for the cluster. If no VPC is available, click Create VPC to create one. After creating the VPC, click the refresh icon. For details, see Creating a VPC with Subnet.
Default Node Subnet	subnet-001	Select a subnet. Nodes in the cluster will be assigned IP addresses from this subnet.
Network Model	VPC network	Select VPC network or Tunnel network. The default value is VPC network. For details about the differences between container network models, see Container Networks.
Container CIDR Block	Manually set (10.0.0.0/16)	Specify the container CIDR block. The CIDR block determines how many containers you can deploy in the cluster. You can select Manually set or Auto select.
Pod IP Addresses Reserved for Each Node	128	Specify the number of allocatable container IP addresses (the alpha.cce/fixPoolMask parameter) on each node. This determines the maximum number of pods that can be created on each node. For more details, see Number of Allocatable Container IP Addresses on a Node.
Service CIDR Block	10.247.0.0/16	Configure the cluster-wide IP address range. This controls how many Services can be created. This setting cannot be changed later.

Click Next: Select Add-on. On the page displayed, select the add-ons to be installed during cluster creation.

This example only includes mandatory add-ons, which are installed automatically.
Click Next: Configure Add-on. No setup is needed for the default add-ons.
Click Next: Confirm Settings, check the displayed cluster resource list, and click Submit.

Wait for the cluster to be created. It takes approximately 5 to 10 minutes.

The newly created cluster in the Running state with zero nodes will be displayed on the Clusters page.

Figure 1 Cluster created

Step 3: Create a Node Pool and Nodes

Log in to the CCE console and click the cluster name to access the cluster console.
In the navigation pane, choose Nodes. On the Node Pools tab, click Create Node Pool in the upper right corner.

Configure the node pool parameters.

This example describes only mandatory parameters. You can keep default settings for most other parameters. For details, see Creating a Node Pool.

Click to enlarge

Parameter	Example	Description
Node Type	Elastic Cloud Server (VM)	Select a node type based on service requirements. The available node flavors will then be displayed in the Specifications area for you to choose from.
Specifications	4 vCPUs \| 8 GiB	Select a node flavor that best fits your service needs. For optimal cluster component performance, you are advised to choose a node with at least 4 vCPUs and 8 GiB of memory.
Container Engine	containerd	Select a container engine based on service requirements. For details about the differences between container engines, see Container Engines.
OS	Huawei Cloud EulerOS 2.0	Select an OS for the nodes.
Login Mode	A custom password	Password: Set and confirm a password for node login. The default username is root. Keep the password secure. It cannot be retrieved if forgotten. Key Pair: Select a key pair for node login and confirm that you have the key file. Without this file, you will not be able to log in. Key pairs are used for identity authentication when you remotely access nodes. If you do not have a key pair, click Create Key Pair. For details, see Creating a Key Pair on the Management Console.

Configure parameters in Storage Settings and Network Settings. In this example, keep the default settings. Select I have confirmed that the security group rules have been correctly configured for nodes to communicate with each other. and click Next: Confirm.
Review the node specifications, read and confirm the instructions on the page, and click Submit.
Locate the newly created node pool and click Scaling. The node pool initially contains zero nodes.
Set the number of nodes to add to 2. This will create two more nodes in the node pool.
Wait for the nodes to be created. It takes approximately 5 to 10 minutes.

Step 4: Create a Workload and Access It

You can deploy a workload using the console or kubectl. In this example, an Nginx image is used to create a workload.

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.

Click to enlarge

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.

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.

Click to enlarge

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 2 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 3 Obtaining the external access address
In the address bar of a browser, enter <external-access-address:service-port> to access the workload. The value of service-port is the same as the service port specified in 4. In this example, it is 8080.

Figure 4 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.
1. 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.
2. Install kubectl.
```
chmod +x kubectl
mv -f kubectl /usr/local/bin
```
Configure a credential for kubectl to access the Kubernetes cluster.
1. Log in to the CCE console and click the cluster name to access the cluster console. Choose Overview in the navigation pane.
2. On the page displayed, locate the Connection Information area, click Configure next to kubectl, and view the kubectl connection information.
3. 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.
4. 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.
5. 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
```
6. 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 the following 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

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 box of a browser. **.**.**.** specifies the EIP of the load balancer, and 8080 indicates the access port.

Figure 5 Accessing Nginx using the LoadBalancer Service