Checklist for Deploying Containerized Applications in the Cloud
Overview
Security, efficiency, stability, and high availability are core requirements for all cloud practitioners. Cloud Container Instance (CCI) provides a serverless container runtime so you can run containers without managing underlying servers. Although CCI frees you from infrastructure O&M, the system availability, data reliability, and O&M stability of your services still require refined configuration. This section outlines the check items for deploying applications on CCI from evaluation items, impact descriptions, and references. It aims to help you avoid cloud migration obstacles and reduce the risk of application exceptions caused by improper configuration.
Check Items
| Check Item | Type | Impact Description | FAQ & Example |
|---|---|---|---|
| Network capacity planning When creating a namespace, plan the associated VPC subnet CIDR block in advance to ensure that there are enough IP addresses. | Network planning | IP addresses of CCI containers are directly allocated from the associated VPC subnet. If the subnet CIDR block is too small, service scale-out will fail during peak hours because there are not enough IP addresses. | |
| Networking and interconnection planning Sort out the Internet or private network communication requirements in advance and properly configure NAT gateways or EIPs. | Network planning | If network access capabilities are not correctly configured, containers cannot pull external data, and Internet users will be unable to access your services. | Configuring Public Network Access for Pods (Using NAT Gateway) |
| VPC endpoint configuration for accessing OBS and SWR VPC endpoints are required for accessing cloud services that use the network segment starting with 100. | Deployment | To pull images from a public image repository of SWE Basic Edition, you need a VPC endpoint for accessing SWR and a VPC endpoint for accessing OBS in the VPC where the workload is deployed. | |
| Security isolation configuration Configure proper security group rules for namespaces or specific pods. | Deployment | Improper inbound or outbound security group rules can block containers from accessing external databases and may cause service connectivity failures. | Configuring Custom Security Groups for Network Interfaces of Pods |
| High availability and anti-affinity deployment Avoid running a single pod. Use at least two replicas to eliminate single points of failure. | Reliability | CCI supports cross-AZ scheduling by default. However, if you run only a single pod, any underlying hardware fluctuation can interrupt your services. | - |
| Resource requests and limits When creating a workload, configure vCPU and memory specifications based on the stress test results. | Deployment | Improper resource evaluation can cause memory overflows (OOM). In addition, CCI's automatic specifications upgrade may allocate unnecessarily high specifications, increasing costs. | |
| Container health check configuration Configure liveness and readiness probes for applications. | Reliability | Without probes, the system cannot detect service process deadlocks, and traffic will continue to be routed to abnormal pods. | |
| Graceful exit (PreStop) configuration Set a PreStop hook in the application lifecycle to reserve processing time. | Reliability | If the grace period and PreStop hook are not configured, the container will be forcibly killed during an application upgrade or scale-in, causing service interruptions. | |
| Traffic entry and access mode selection Select private or public network access based on your requirements. | Deployment | Improper selection may expose private network services to the public network, causing security risks. | |
| ELB health check configuration When using a dedicated load balancer, ensure that the listener and backend health check configurations are correct. | Reliability | If health checks are not configured, ELB may forward traffic to pods that are not ready. |
| Check Item | Type | Impact Description | FAQ & Example |
|---|---|---|---|
| Persistent storage of core data Core data generated by application containers must be mounted to cloud storage to ensure persistence. | Reliability | CCI pods are transient and stateless. After a pod is restarted, data in the local temporary directory is permanently deleted. |
| Check Item | Type | Impact Description | FAQ & Example |
|---|---|---|---|
| High-risk operation prevention (platform-associated resources) Do not delete underlying resources without permissions. Pay attention to the arrears status. | Deployment | Some resource permissions are restricted if your account is in arrears. Deleting associated resources may cause load exceptions. | |
| Do not delete service agencies Do not delete the agencies automatically created by CCI on the IAM console. | Deployment | Deleting such an agency will make core functions of CCI, such as pod startup, invalid immediately, and resource billing abnormal. | - |
| Comprehensive monitoring and logging Use LTS and AOM to build a cloud-native monitoring system. | Monitoring | If log collection and metric monitoring are not configured, root causes of service exceptions cannot be traced. | Viewing Metrics on the AOM Console, Configuring Alarm Rules on the LTS Console, and Reporting Logs to LTS |
What is your overall rating for this page?
Thank 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