# 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