CCE容器编排入门：从第一个Pod到可用的Deployment

容器把应用和运行环境打包在一起，解决了“在我机器上能跑”的问题，但当容器数量从一个变成几十个、上百个时，新的问题随之而来：容器挂了谁来重启？流量来了谁来扩容？版本升级时怎样做到不中断服务？容器编排就是回答这些问题的技术，而华为云容器引擎CCE，正是基于Kubernetes提供的托管容器编排服务。本文从最基础的概念讲起，带你用可运行的YAML和kubectl命令，从第一个Pod走到一个真正可用的Deployment。

一、为什么需要容器编排

如果只用单机Docker，你需要自己记住每个容器跑在哪台机器上、暴露了哪个端口、挂了之后手动重启。业务量一上来，这种手工运维很快就会失控。Kubernetes把一组机器抽象成一个集群，把应用抽象成声明式的期望状态：你告诉集群“我要3个副本、监听80端口、镜像是nginx:1.25”，控制平面就会持续把实际状态向期望状态收敛。副本少了就补，节点故障了就把容器调度到健康节点，升级时先起新版本再逐步替换旧版本。CCE在此基础上托管了控制平面，并提供节点池、弹性伸缩、网络和存储集成，让你把精力放在应用本身，而不是集群运维上。

二、三个必须先理解的核心概念

Pod是Kubernetes中最小的部署单元，通常包含一个主业务容器，必要时再加一个辅助容器，例如日志采集边车。同一个Pod内的容器共享网络命名空间和存储卷，可以通过localhost直接通信。Pod本身是短暂的，不建议直接长期依赖某一个Pod的IP地址。

Deployment是管理无状态应用最常用的控制器，它负责维护Pod副本数、滚动升级和回滚。你修改镜像版本或副本数，Deployment会按策略逐步替换旧Pod，而不是一次性全部停机。

Service则为一组Pod提供稳定的访问入口。Pod的IP会随着重建而变化，但Service的ClusterIP和DNS名称保持不变，业务之间通过Service名称互相访问，就不用再硬编码Pod地址。

三、第一个Pod：先跑起来，再谈编排

把下面内容保存为pod.yaml，这是一个最简单的单容器Pod：

apiVersion: v1
kind: Pod
metadata:
  name: hello-pod
  labels:
    app: hello
spec:
  containers:
    - name: nginx
      image: nginx:1.25
      ports:
        - containerPort: 80

在CCE集群的kubectl环境中执行：

kubectl apply -f pod.yaml
kubectl get pods -o wide
kubectl describe pod hello-pod
kubectl logs hello-pod
kubectl delete -f pod.yaml

get pods能看到Running状态，说明容器已经正常启动；describe可以查看调度节点、拉取镜像和事件；logs用于确认应用自身是否报错。直接创建Pod适合学习和调试，但生产环境不要停留在这一步，因为Pod被删除后不会自动重建，也没有升级策略。

四、真正可用的Deployment：副本、扩缩容与滚动升级

把下面内容保存为deployment.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 5

常用操作如下：

kubectl apply -f deployment.yaml
kubectl get deployments
kubectl get pods -l app=hello
kubectl scale deployment hello-deploy --replicas=5
kubectl set image deployment/hello-deploy nginx=nginx:1.27
kubectl rollout status deployment/hello-deploy
kubectl rollout undo deployment/hello-deploy

这里有几个关键点。第一，selector.matchLabels必须与Pod模板的labels一致，否则Deployment找不到自己管理的Pod。第二，resources.requests用于调度，limits用于防止单个容器把节点资源吃光，两者都写是良好的生产习惯。第三，readinessProbe决定Pod何时可以接收流量，应用还没准备好就不要让Service把请求打过去。第四，升级失败时rollout undo可以快速回滚，这比手动重新部署旧镜像更可靠。

五、给应用一个稳定入口：Service

把下面内容保存为service.yaml：

apiVersion: v1
kind: Service
metadata:
  name: hello-service
spec:
  type: ClusterIP
  selector:
    app: hello
  ports:
    - port: 80
      targetPort: 80

kubectl apply -f service.yaml
kubectl get svc hello-service
kubectl describe svc hello-service

集群内部的其他应用可以通过http://hello-service访问这个服务。对外暴露时，再根据需要选择NodePort、负载均衡型Service或Ingress，不要一开始就把所有服务都直接暴露到公网。

六、在CCE上落地的六条实践建议

第一，用命名空间隔离环境，例如dev、test、prod分开，避免测试操作影响生产。第二，给不同业务建不同的节点池，计算密集和内存密集的负载不要混在一个节点池里抢资源。第三，镜像使用固定版本标签，不要在生产环境用latest，否则回滚和问题定位都会变得困难。第四，敏感信息不要写进镜像和YAML明文，用Secret和ConfigMap分别管理密码与配置。第五，提前配好日志采集和监控告警，容器出问题时先看事件和日志，而不是盲目重启。第六，定期演练扩缩容和升级回滚，真正需要的时候才不会手忙脚乱。

七、常见排错路径

Pod一直处于Pending，先看节点资源和调度条件；处于CrashLoopBackOff，先看kubectl logs和启动命令；Service访问不通，先核对selector标签和端口映射，再看Pod是否通过了就绪检查。把get pods、describe pod、logs和get events这四个命令练熟，八成以上的入门问题都能定位。

八、总结

容器编排的学习路径其实很清晰：先理解Pod，再用Deployment管理副本和升级，再用Service提供稳定访问，最后把资源限制、健康检查、配置管理和可观测性补齐。完成上面的YAML和命令后，你已经有了一个可以在CCE上持续运行、可以扩容、可以升级回滚的最小可用服务。下一步可以继续尝试Ingress对外暴露、HPA基于负载自动扩缩容，以及用Helm把这套YAML模板化，复用到多个环境中。