用华为云CCE部署一个最小Web服务：从镜像到可访问的完整流程

写在前面

本文的目标，是把一个最小的 Web 服务完整地走通：先把它做成容器镜像，再放到华为云云容器引擎 CCE 里运行，最后通过 Service 让外部能够访问。读完之后，你应该能说清楚 Pod、Deployment、Service 各自负责什么，以及一个请求从浏览器到容器经历了哪些环节。

需要提前说明两点：第一，本文是流程与概念说明，文中出现的镜像名、端口、集群名均为示意，具体选项以控制台当时的实际界面为准；第二，CCE 集群、节点、负载均衡和弹性公网 IP 都可能产生费用，动手前请先确认计费方式，实验结束后务必按文末的步骤清理。

一、整体思路：一张图看懂最小部署

最小部署并不需要一开始就引入复杂的微服务架构，核心只有四步：

1. 准备应用：一个能返回页面的最小 Web 程序。
2. 做成镜像：把程序和运行环境打包成容器镜像。
3. 在 CCE 里运行：用 Deployment 描述要跑几个副本、用哪个镜像、暴露哪个端口。
4. 对外提供访问：用 Service 把 Pod 的端口稳定地暴露出来，再结合负载均衡或节点端口完成访问。

理解这条主线之后，再去看控制台上的众多配置项，就不容易迷路：大部分配置都是在给这四步补细节，例如资源限制、健康检查、访问方式和安全策略。

二、准备镜像：先让应用可以在本地容器里跑起来

1. 写一个最小应用

最小应用不需要数据库，也不依赖外部服务。常见的选择有两种：

• 静态页面：一个 index.html，由 Nginx 之类的 Web 服务器返回。
• 简单接口：一个只返回问候语和健康检查结果的 HTTP 服务，例如返回问候语，并提供 /healthz 路径用于健康检查。

对第一次实验来说，静态页面更直观；如果想顺带练习健康检查，可以在应用里额外提供一个健康检查接口。

2. 写 Dockerfile

以静态页面为例，Dockerfile 的思路通常是：

FROM nginx:alpine
COPY index.html /usr/share/nginx/html/index.html
EXPOSE 80

这里的含义是：以一个轻量的 Nginx 镜像为基础，把本地页面复制到 Nginx 默认的静态目录，并声明容器监听 80 端口。EXPOSE 更多是文档和约定的作用，真正决定访问的还是后续工作负载和 Service 的端口配置。

3. 构建并推送镜像

一般流程是：本地构建镜像、给镜像打标签、登录镜像仓库、推送镜像。在华为云的场景下，镜像可以推送到容器镜像服务 SWR，推送前通常需要先创建组织和镜像仓库，并按仓库页面给出的登录命令完成登录。

推送完成后，建议先在仓库里确认镜像和标签确实存在，再继续下一步。很多部署失败，根因其实是镜像名或标签写错，而不是 CCE 本身的问题。

三、创建集群：只为最小实验选择够用的配置

在 CCE 控制台创建集群时，重点关注以下几项：

• 区域与可用区：选择与后续访问、其他资源距离较近的区域；实验场景不需要一开始就跨多个可用区做高可用。
• 集群版本与网络模型：按控制台推荐或业务需要选择，理解网络模型会影响 Pod 与 Service 的通信方式，选定后一般不建议随意变更。
• 节点配置：最小实验先用较小的节点规格和较少的节点数，够跑一个副本即可；节点是主要的计费项之一，规格越大、数量越多，费用越高。
• 安全与访问：妥善保管集群访问凭证，不要把高权限凭证写进公开代码或镜像里。

集群创建需要一定时间，等到集群状态正常后再创建工作负载，避免在集群尚未就绪时反复排查应用问题。

四、创建工作负载：让 CCE 帮你把容器跑起来

1. 为什么用 Deployment 而不是直接跑 Pod

Pod 是 CCE 里最小的运行单元，但直接创建 Pod 后，如果 Pod 异常退出，通常不会自动按期望恢复。Deployment 在 Pod 之上多了一层管理：它会维持你声明的副本数，支持滚动更新和回滚。对最小实验来说，先理解 Deployment，比直接操作 Pod 更贴近实际用法。

2. 关键配置项

创建无状态工作负载时，通常需要填写：

• 工作负载名称：见名知义即可，例如 web-demo。
• 容器镜像：填写上一步推送到 SWR 的完整镜像地址和标签，标签建议用明确的版本号，而不是长期用含义模糊的标签做实验记录。
• 副本数：最小实验先填 1，跑通后再尝试扩到 2，观察 Service 如何把流量分发到多个 Pod。
• 容器端口：与应用实际监听的端口一致，例如静态页面常用 80。
• 资源请求与限制：请求值用于调度，限制值用于防止单个容器无节制占用节点资源；实验时给一个偏小但够用的值即可。
• 健康检查：存活探针用于判断容器是否需要重启，就绪探针用于判断 Pod 是否可以接收流量；路径要与应用实际提供的接口一致，例如 /healthz。

3. 先确认 Pod 正常，再谈访问

工作负载创建后，先看 Pod 是否进入运行状态，再看容器日志有没有报错。如果 Pod 反复重启，优先检查镜像是否拉取成功、端口是否一致、健康检查路径是否存在；如果镜像拉取失败，优先核对镜像地址、标签和仓库访问权限。

五、创建 Service 与访问：把端口稳定地暴露出来

1. Service 解决什么问题

Pod 的 IP 会随着重建而变化，直接记住 Pod IP 并不可靠。Service 提供了一个稳定的入口：它通过标签选择器关联到一组 Pod，并把请求转发给其中健康的 Pod。即使 Pod 被重建，只要标签不变，Service 的入口就不变。

2. 三种常见访问方式的区别

ClusterIP 仅集群内部访问，是默认类型，适合服务之间互相调用，不直接对外暴露。NodePort 适合最小实验和临时验证，通过节点端口对外访问，简单但端口范围和安全性需要留意。LoadBalancer 通过负载均衡对外提供入口，适合需要稳定对外地址的场景，也会产生相应费用。

最小实验可以先用 NodePort 或负载均衡验证访问链路是否通畅，再根据实际需要决定是否长期保留对外入口。

3. 访问验证与排查清单

创建 Service 后，按下面顺序验证：

1. 确认 Service 已关联到 Pod，且后端端点不为空。
2. 用浏览器或 curl 访问对应的地址和端口，看是否返回预期页面。
3. 如果访问不通，依次检查：Pod 是否正常、Service 端口映射是否正确、安全组是否放行了对应端口、负载均衡或节点端口是否配置正确。
4. 如果页面能打开但内容不是预期版本，优先检查镜像标签是否指向了最新推送的版本，以及是否需要重新创建或更新工作负载。

安全提醒：实验用的对外端口不要长期暴露，更不要把管理类接口直接对外开放；验证完成后，应及时收紧安全组或删除对外入口。

六、资源清理：实验结束最容易被忽略的一步

清理的顺序建议是自上而下：

1. 先删除 Service 和工作负载，确认 Pod 已停止。
2. 再删除集群和节点，避免只删应用却留下计费的集群资源。
3. 检查是否残留负载均衡、弹性公网 IP、云硬盘等关联资源。
4. 如不再需要，可清理实验用的镜像仓库和镜像标签。
5. 最后到费用或账单页面确认没有意外的持续计费项。

只删除页面上的应用，而忘记删除集群和负载均衡，是新手实验中最常见的费用残留来源。

七、常见问题

问：镜像拉取失败怎么办？先核对镜像仓库地址、镜像名和标签是否完全一致，再确认仓库的访问权限和网络连通性。标签写错一个字符，也可能导致拉取失败。

问：Pod 一直重启怎么办？优先看容器日志和事件信息，区分是应用启动失败、端口监听失败，还是健康检查路径不存在。不要只看重启次数，日志里的第一条错误往往更有价值。

问：Service 创建了但访问不通怎么办？按访问链路倒推：Pod 是否健康、Service 是否关联到 Pod、端口映射是否正确、安全组和负载均衡是否放行。逐段定位，比一次性改多个配置更有效。

总结：最小部署的检查清单

• 应用可以在容器里返回预期页面。
• 镜像已推送到仓库，名称和标签可复核。
• 集群状态正常，节点规格与实验规模匹配。
• Deployment 副本数、镜像、端口、健康检查配置一致。
• Service 已关联 Pod，访问链路验证通过。
• 实验结束后，Service、工作负载、集群及关联资源已清理。

把这份清单跑通一次，之后再引入配置项、持久存储、自动扩缩容或 Ingress，都会有清晰的落点：它们都是在最小部署的基础上，为某一环节补能力，而不是一开始就要全部配齐。