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

Checklist for Migrating Containerized Applications to the Cloud

Overview

Cloud Container Engine (CCE) provides highly scalable, high-performance, enterprise-class Kubernetes clusters and supports Docker containers. With CCE, you can easily deploy, manage, and scale out containerized applications.

This checklist describes the system availability, data reliability, and O&M reliability of migrating containerized applications to the cloud. It contains check items, impact, FAQs, and examples, helping you migrate services to CCE and avoid application exceptions or cluster reconstruction caused by improper use.

Check Items

Table 1 System availability

Category	Check Item	Type	Impact
Cluster	When creating a cluster, set High Availability to Yes.	Reliability	A cluster with High Availability set to No is a non-HA cluster with only one master. If the master node is faulty, the entire cluster will be unavailable. Therefore, you are advised to create an HA cluster in the production environment.
	Before creating a cluster, determine the container network model that is suitable to the service scenario.	Network planning	Different container network models apply to different scenarios.
	Before creating a cluster, plan the subnet CIDR block and container network CIDR block properly.	Network planning	If the range of the subnet and container network CIDR blocks is not properly set, the number of available nodes in the cluster will be less than the number of nodes supported by the cluster. Network planning has different constraints on different container network models.
	Before creating a cluster, properly plan CIDR blocks for the related Direct Connect, peering connection, container network, service network, and subnet to avoid IP address conflicts.	Network planning	If CIDR blocks are not properly set and IP address conflicts occur, service access will be affected.
Workload	When creating a workload, set the upper and lower limits of CPU and memory resources.	Deployment	If the upper and lower resource limits are not set for an application, a resource leak of this application will make resources unavailable for other applications deployed on the same node. In addition, applications that do not have upper and lower resource limits cannot be accurately monitored.
	When creating an application, set the number of pods to more than two and set the scheduling policy based on service requirements.	Reliability	A single-pod application will be faulty if the node or pod is faulty.
	Properly set affinity and anti-affinity.	Reliability	If affinity and anti-affinity are both configured for an application that provides Services externally, Services may fail to be accessed after the application is upgraded or restarted.
	When creating a workload, set the health check policy, that is, set the workload liveness probe and the readiness probe.	Reliability	If the two probes are not set, pods cannot detect service exceptions or automatically restart the service to restore it. This results in a situation where the pod status is normal but the service in the pod is abnormal.
	When creating a workload, set the pre-stop processing command (Lifecycle > Pre-Stop) to ensure that the services running in the pods can be completed in advance in the case of application upgrade or pod deletion.	Reliability	If the pre-stop processing command is not configured, the pod will be directly killed and services will be interrupted during application upgrade.
	When creating a Service, select an access mode based on service requirements. Currently, the following types of access modes are supported: intra-cluster access, intra-VPC access, and external access.	Deployment	If the access mode is not properly set, internal and external access may be in disorder and resources may be wasted.

Table 2 Data reliability

Category	Check Item	Type	Impact
Container data persistency	Store application data in the cloud, rather than on a local disk.	Reliability	If a node is faulty and cannot be restored, data on the local disk cannot be restored.
Backup	Back up application data.	Reliability	Data cannot be restored after being lost.

Table 3 O&M reliability

Category	Check Item	Type	Impact
Project	The quotas of ECS, VPC, subnet, EIP, and EVS resources must meet customer requirements.	Deployment	If the quota is insufficient, resources will fail to be created. Specifically, users who have configured automatic capacity expansion must have sufficient resource quotas.
	Do not install private software or modify OS configurations on a cluster node.	Deployment	If private software is installed on a cluster node or OS configurations are modified, exceptions may occur on Kubernetes components on the node, making it unavailable for application deployment.
	Do not modify information about resources created by CCE, such as security groups and EVS disks. Resources created by CCE are labeled cce.	Deployment	CCE cluster functions may be abnormal.
Proactive O&M	Configure alarm monitoring on AOM for the applications you deployed in CCE clusters.	Monitoring	If alarm monitoring is not configured, you cannot receive alarms when applications are faulty and need to manually locate the faults.

Parent topic: Reference