华为云 CCE 云原生实践：Web 应用容器化部署与弹性伸缩

华为云 CCE 云原生实践：Web 应用容器化部署与弹性伸缩

一、为什么选 CCE

很多团队在做云化改造时，都会面临一个选择：业务继续跑在 ECS 虚机上，还是迁移到容器？以我们一个典型的电商 Web 应用为例，高峰期 QPS 是低峰期的十几倍，传统做法是提前囤一批 ECS 应对峰值，大部分时间这些机器是闲置的。用 CCE（Cloud Container Engine，云容器引擎）之后，资源利用率能提升不少，扩缩容也从"人肉加班"变成了分钟级自动完成。

CCE 是华为云提供的 Kubernetes 托管服务，控制面由华为云代管，用户只需要关注节点和上面的工作负载，不需要自己维护 etcd、kube-apiserver 这些组件，省心程度比较高。

二、集群与节点规划

1. 集群规格：新建标准版集群时，我一般选 3 个 master 节点的高可用配置（托管版可直接选"托管 master"），版本选当前推荐的稳定版。

节点规格：演示环境用 2 台 2U4G 的弹性云服务器足够。生产环境建议节点至少 3 台、跨 3 个可用区，避免单可用区故障导致节点全部不可用。网络：VPC 网段和子网规划好之后，容器网络类型建议选择 VPC 下的弹性负载均衡兼容模式或默认 Overlay 模式，注意容器网段不要和 VPC 网段冲突。

一个容易踩的坑：节点规格要能装下 kubelet 的预留资源。4G 内存的节点上如果跑内存大户的 sidecar，可能出现 Pod 因资源不足一直 Pending，建议先用 kubectl describe node 看 Allocatable 是否够用。

三、应用镜像与部署

1. 镜像构建：把 Web 应用打成 Docker 镜像，推送到华为云 SWR（软镜像仓库）。SWR 支持私有仓库和版本管理，部署时直接引用 swr.cn-north-4.myhuaweicloud.com/xxx/web:v1 这样的地址即可。

Deployment：副本数设为 2，容器端口、健康检查（liveness/readiness）配好。健康检查路径建议选一个无副作用的接口，比如 /healthz，返回 200 即可。Service：创建 ClusterIP 类型的 Service 暴露内部访问；对外访问再创建 ELB 类型的 Service 绑定弹性负载均衡器，注意端口映射的 前端端口:后端端口 顺序别写反。

apiVersion: apps/v1 kind: Deployment metadata:   name: web spec:   replicas: 2   selector:     matchLabels:       app: web   template:     metadata:       labels:         app: web     spec:       containers:       - name: web         image: swr.cn-north-4.myhuaweicloud.com/demo/web:v1         ports:         - containerPort: 8080         readinessProbe:           httpGet:             path: /healthz             port: 8080           initialDelaySeconds: 5           periodSeconds: 10         livenessProbe:           httpGet:             path: /healthz             port: 8080           initialDelaySeconds: 15           periodSeconds: 20

四、弹性伸缩：HPA 按负载自动扩缩

CCE 支持 Kubernetes 原生的 HPA（Horizontal Pod Autoscaler）。先给 Deployment 打标签 app.kubernetes.io/name: web，然后创建 HPA：

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata:   name: web-hpa spec:   scaleTargetRef:     apiVersion: apps/v1     kind: Deployment     name: web   minReplicas: 2   maxReplicas: 8   metrics:   - type: Resource     resource:       name: cpu       target:         type: Utilization         averageUtilization: 60

CPU 使用率超过 60% 就加副本，低于 60% 逐步回收，上限 8 副本。压测时可以明显看到：请求上来 1 分钟左右副本就开始扩容，流量回落后又自动缩回基线。

五、升级与发布策略

- 滚动更新：默认 maxSurge=25%、maxUnavailable=25%，发布新版本镜像 tag 时 Pod 逐个替换，服务不中断。

- 回滚：kubectl rollout undo deployment/web 一条命令回到上一版本，这是容器化相对 ECS 部署最大的安全感来源。

- 金丝雀：流量灰度可以结合 ELB 的监听/转发策略，或者上 CCE 的流量治理能力做更细的灰度，按 header 或百分比切流。

六、踩坑小结

1. 节点资源预留没算好，Pod 调度不上——先 describe node 看 Allocatable。
2. ELB Service 端口映射写反，外部访问 502——记住是"前端端口:后端端口"。
3. 镜像拉取失败：SWR 授权（imagePullSecrets）没配，或节点没有对应 region 的内网访问，建议用同 region SWR 走内网拉取，又快又省流量。
4. 健康检查路径返回 302 而不是 200，readiness 一直失败，Pod 不接流量——探针只看状态码，重定向算失败。

七、总结

CCE 把 Kubernetes 的运维复杂度收走了，团队可以把精力放在应用本身：镜像 + 声明式配置 + HPA + 滚动发布，这一套下来，弹性能力和发布安全性都有质的提升。如果你还在 ECS 上手工部署，建议先用一个边缘业务（内部工具、测试环境）试点容器化，跑顺之后再推广到核心链路。