华为云 CCE 容器引擎实战：从 Deployment 到 HPA 的一套组合拳

把容器跑起来不难，难的是让它"自动扩、自动缩、自动恢复"。容器编排的价值，不在部署那一刻，而在长期运维的每一天。

一、从"手动跑容器"到"声明式编排"

用 Docker 手动跑容器的时代，改个配置要登机器、重启进程，机器挂了还得人工拉起。一旦实例多起来，运维就成了救火。CCE（云容器引擎）基于 Kubernetes，把这一切变成声明式：你只描述"我想要什么状态"，系统负责把它变成现实，并持续保持。

相比自建 Kubernetes，CCE 把控制面运维、证书轮换、etcd 备份这些苦活都托管了，你只需关心工作负载本身。

二、Deployment：声明式发布

一个最小的无状态应用，用 Deployment 描述即可：

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
          resources:
            requests:
              cpu: 200m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi

几个关键点：镜像来自 SWR 镜像仓库；requests/limits 一定要配，它既影响调度，也是后面 HPA 计算利用率的前提。

三、Service：让副本对外成"一个入口"

Pod 的 IP 会随重建变化，不能直接对外。用 Service 提供稳定入口：

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

type: LoadBalancer 会自动创建负载均衡（ELB），selector 必须和 Pod 的 label 对上，否则流量打不到后端——这是新手最常踩的坑之一。

四、滚动更新与回滚

改镜像版本时，Kubernetes 默认滚动更新：先拉起新 Pod，就绪后再下线旧 Pod，做到不停机。通过 maxSurge、maxUnavailable 控制节奏。升级出问题时一条 kubectl rollout undo 就能回滚到上一版本，比手工回退从容得多。如果不想一次性全量，还可以配合灰度发布，先放一小部分流量验证，再逐步放开。

五、HPA：按负载自动扩缩容

固定副本数要么浪费、要么扛不住。HorizontalPodAutoscaler 让副本数跟着指标走：

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

含义很直白：CPU 平均利用率超过 70% 就扩，最低 2 副本、最高 10 副本。

实际生产中，纯 CPU 指标对 IO 密集型服务并不够用，可结合内存、QPS 或自定义指标，但要先确认指标采集链路已经打通。

六、实战避坑清单

1. 必须配 requests：没配 CPU requests 的 Pod，HPA 无法计算利用率，会一直"未知"不扩缩。
2. 别用 latest 标签：镜像标签固定为版本号，否则滚动更新可能拉到意料之外的镜像。
3. label 要对齐：Service 的 selector 与 Pod 的 labels 必须完全一致，这俩对不上是最常见的"访问不通"。
4. 就绪探针要好：配好 readinessProbe，否则新 Pod 还没起来就被接流量，滚动更新期间报错率飙升。
5. 健康检查对 LB：LoadBalancer 的健康检查端口要和容器实际端口一致，否则后端一直被判定异常。
6. 资源规划留余量：limits 调太低会 OOMKilled，调太高又浪费；先用压测数据说话。
7. 先测再上：新集群先跑小流量验证滚动更新与 HPA 行为，确认无误再承载核心业务。

七、小结

CCE 的精髓，是把运维从"救火"变成"声明"：Deployment 描述期望状态、Service 提供稳定入口、滚动更新保证平滑、HPA 让容量跟随负载。把这几块拼齐，一个应用才算真正"云原生化"。容器编排不是炫技，它换来的是故障时少熬的那几个夜，以及平时能按时下班的那份踏实。