- What's New
- Function Overview
- Service Overview
- Billing
- Getting Started
- User Guide
- Best Practices
-
Developer Guide
- Overview
- Using Native kubectl (Recommended)
- Namespace and Network
- Pod
- Label
- Deployment
- EIPPool
- EIP
- Pod Resource Monitoring Metric
- Collecting Pod Logs
- Managing Network Access Through Service and Ingress
- Using PersistentVolumeClaim to Apply for Persistent Storage
- ConfigMap and Secret
- Creating a Workload Using Job and Cron Job
- YAML Syntax
-
API Reference
- Before You Start
- Calling APIs
- Getting Started
- Proprietary APIs
-
Kubernetes APIs
- ConfigMap
- Pod
- StorageClass
- Service
-
Deployment
- Querying All Deployments
- Deleting All Deployments in a Namespace
- Querying Deployments in a Namespace
- Creating a Deployment
- Deleting a Deployment
- Querying a Deployment
- Updating a Deployment
- Replacing a Deployment
- Querying the Scaling Operation of a Specified Deployment
- Updating the Scaling Operation of a Specified Deployment
- Replacing the Scaling Operation of a Specified Deployment
- Querying the Status of a Deployment
- Ingress
- OpenAPIv2
- VolcanoJob
- Namespace
- ClusterRole
- Secret
- Endpoint
- ResourceQuota
- CronJob
-
API groups
- Querying API Versions
- Querying All APIs of v1
- Querying an APIGroupList
- Querying APIGroup (/apis/apps)
- Querying APIs of apps/v1
- Querying an APIGroup (/apis/batch)
- Querying an APIGroup (/apis/batch.volcano.sh)
- Querying All APIs of batch.volcano.sh/v1alpha1
- Querying All APIs of batch/v1
- Querying All APIs of batch/v1beta1
- Querying an APIGroup (/apis/crd.yangtse.cni)
- Querying All APIs of crd.yangtse.cni/v1
- Querying an APIGroup (/apis/extensions)
- Querying All APIs of extensions/v1beta1
- Querying an APIGroup (/apis/metrics.k8s.io)
- Querying All APIs of metrics.k8s.io/v1beta1
- Querying an APIGroup (/apis/networking.cci.io)
- Querying All APIs of networking.cci.io/v1beta1
- Querying an APIGroup (/apis/rbac.authorization.k8s.io)
- Querying All APIs of rbac.authorization.k8s.io/v1
- Event
- PersistentVolumeClaim
- RoleBinding
- StatefulSet
- Job
- ReplicaSet
- Data Structure
- Permissions Policies and Supported Actions
- Appendix
- Out-of-Date APIs
- Change History
-
FAQs
- Product Consulting
-
Basic Concept FAQs
- What Is CCI?
- What Are the Differences Between Cloud Container Instance and Cloud Container Engine?
- What Is an Environment Variable?
- What Is a Service?
- What Is Mcore?
- What Are the Relationships Between Images, Containers, and Workloads?
- What Are Kata Containers?
- Can kubectl Be Used to Manage Container Instances?
- What Are Core-Hours in CCI Resource Packages?
- Workload Abnormalities
-
Container Workload FAQs
- Why Service Performance Does Not Meet the Expectation?
- How Do I Set the Quantity of Instances (Pods)?
- How Do I Check My Resource Quotas?
- How Do I Set Probes for a Workload?
- How Do I Configure an Auto Scaling Policy?
- What Do I Do If the Workload Created from the sample Image Fails to Run?
- How Do I View Pods After I Call the API to Delete a Deployment?
- Why an Error Is Reported When a GPU-Related Operation Is Performed on the Container Entered by Using exec?
- Can I Start a Container in Privileged Mode When Running the systemctl Command in a Container in a CCI Cluster?
- Why Does the Intel oneAPI Toolkit Fail to Run VASP Tasks Occasionally?
- Why Are Pods Evicted?
- Why Is the Workload Web-Terminal Not Displayed on the Console?
- Why Are Fees Continuously Deducted After I Delete a Workload?
-
Image Repository FAQs
- Can I Export Public Images?
- How Do I Create a Container Image?
- How Do I Upload Images?
- Does CCI Provide Base Container Images for Download?
- Does CCI Administrator Have the Permission to Upload Image Packages?
- What Permissions Are Required for Uploading Image Packages for CCI?
- What Do I Do If Authentication Is Required During Image Push?
-
Network Management FAQs
- How Do I View the VPC CIDR Block?
- Does CCI Support Load Balancing?
- How Do I Configure the DNS Service on CCI?
- Does CCI Support InfiniBand (IB) Networks?
- How Do I Access a Container from a Public Network?
- How Do I Access a Public Network from a Container?
- What Do I Do If Access to a Workload from a Public Network Fails?
- What Do I Do If Error 504 Is Reported When I Access a Workload?
- What Do I Do If the Connection Timed Out?
- Storage Management FAQs
- Log Collection
- Account
- SDK Reference
- Videos
- General Reference
Show all
Copied.
Scaling a Workload
This section describes two workload scaling methods: auto scaling and manual scaling.
- Auto scaling: Supports metric-based, scheduled, and periodic policies. When the configuration is complete, pods can be automatically added or deleted based on resource changes or a specified schedule.
- Manual scaling: Increases or decreases the number of pods immediately after the configuration is complete.
If a pod mounted with an EVS volume is deleted, the EVS disk will not be deleted. If a new pod with the same name is created, the new pod cannot be mounted to any EVS volume.
Auto Scaling
Currently, auto scaling is supported only for Deployments.
An appropriate auto scaling policy eliminates the need to manually adjust resources in response to service changes and traffic peaks, thus helping you reduce the workforce and resources required. CCI supports the following types of auto scaling policies:
Metric-based: Scales the workload based on vCPU/memory usage. You can specify a CPU/memory usage threshold. If the usage is higher or lower than the threshold, instances can be automatically added or deleted.
Scheduled: Scales the workload at a specified time. A scheduled scaling policy is ideal for scenarios such as flash sales and anniversary promotions.
Periodic: Scales the workload on a daily, weekly, or monthly basis. A periodic scaling policy is ideal for applications that have periodic traffic changes.
- Configure a metric-based auto scaling policy.
- Log in to the CCI console. In the navigation pane on the left, choose Workloads > Deployments. On the page displayed, locate the Deployment and click its name.
- In the Scaling area of the Deployment details page, click Auto Scaling and then click Add Scaling Policy.
Figure 1 Adding a metric-based auto scaling policy
Table 1 Parameters of a metric-based auto scaling policy Parameter
Description
Policy Name
Enter a name for the policy.
Policy Type
Select Metric-based policy.
Trigger Condition
Select CPU usage or Memory usage.
If you set the trigger condition to average memory usage > 70%, the scaling policy will be triggered when the average memory usage exceeds 70%.
Duration
Statistical period. Select a value from the drop-down list.
If you set this parameter to 60, metric statistics will be collected every 60 seconds.
Consecutive Times
If you set this parameter to 3, the configured action will be triggered when the threshold is reached for 3 consecutive statistical periods.
Policy Action
Specify the action to be executed when the policy is triggered. You can specify an action to add or reduce the number of instances.
- Click OK.
The policy is added to the policy list, and its status is Enabled.Figure 2 Policy enabled
When the trigger condition is met, the auto scaling policy will be executed.
- Configure a scheduled auto scaling policy.
- In the Scaling area, click Auto Scaling and then click Add Scaling Policy.
Figure 3 Adding a scheduled auto scaling policy
Table 2 Parameters of a scheduled auto scaling policy Parameter
Description
Policy Name
Enter a name for the policy.
Policy Type
Select Scheduled Policy.
Triggered
Specify the time when you want the policy to be triggered.
Policy Action
Specify the action to be executed when the policy is triggered. You can specify an action to add or reduce the number of instances.
- Click OK.
The policy is added to the policy list, and its status is Enabled.
- In the Scaling area, click Auto Scaling and then click Add Scaling Policy.
- Configure a periodic auto scaling policy.
- In the Scaling area, click Auto Scaling and then click Add Scaling Policy.
Figure 4 Adding a periodic auto scaling policy
Table 3 Parameters of a periodic auto scaling policy Parameter
Description
Policy Name
Enter a name for the policy.
Policy Type
Select Periodic Policy.
Select Time
Select the time range, frequency, and time when you want the policy to be triggered.
Policy Action
Specify the action to be executed when the policy is triggered.
- Click OK.
The policy is added to the policy list, and its status is Enabled.
- In the Scaling area, click Auto Scaling and then click Add Scaling Policy.
Manual Scaling
- Log in to the CCI console. In the navigation pane on the left, choose Workloads > Deployments. On the page displayed, locate the Deployment and click its name.
- Under Manual Scaling in the Scaling area, click
and modify the number of instances (for example, change the value to 3), and then click Save. The scaling takes effect immediately.
CCI provides a time window for running pre-stop processing commands before an application is deleted. If a command process is still running when the time window expires, the application will be forcibly deleted.
Figure 5 Changing the number of instances - In the pod list, you can see the new pods being created. When the status of all added pods changes to Running, the scaling is completed successfully.
Figure 6 Pod list after a manual scaling
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot