简介
你已经来到这门入门课程的最后一个挑战。前面的实验带你学习了 Pod、Deployment、Service、扩缩容、故障排查和回滚。现在，你需要在没有逐条命令指导的情况下，将这些知识整合到一次小型发布任务中。
环境中有一个运行正常的初始版本，名称为 web-app。你的任务是发布下一个固定版本的 NGINX 镜像，同时保留 3 个可用副本和稳定的 Service。最终集群状态必须与保存的清单保持一致，这样发布在挑战结束后仍然可以重复部署。
发布下一个 NGINX 版本
环境启动： 本实验会为你启动一个完整的 Kubernetes 集群。配置控制平面、节点和网络组件通常需要 2～3 分钟。请耐心等待环境加载完成后再开始操作。
当前情况
平台团队已在 /home/labex/project/final-release/web-app.yaml 中准备好一个初始版本。目前，它通过名为 web-app 的 Service，将运行 nginx:1.26-alpine 的 3 个副本对外提供服务。
操作范围
- 使用现有的
web-appDeployment、Service、清单文件和release-check客户端。 - 不要重命名资源、修改选择器，也不要替换已批准的滚动更新配置。
- 使用固定版本的目标镜像；
latest等浮动标签不属于本次接受的发布内容。
你的目标
通过现有 Deployment 发布 nginx:1.27-alpine，并让运行中的集群、Service 访问路径和保存的清单保持健康且可重复部署。
验收标准
- Deployment
web-app的期望副本数必须正好为 3。 - 其中的
nginx容器必须使用固定镜像nginx:1.27-alpine。 - 滚动更新配置必须保持为
maxUnavailable: 0和maxSurge: 1。 - 变更原因注解必须描述 NGINX 1.27 版本发布。
- Service
web-app仍然选择该 Deployment 的 Pod，并且拥有 3 个已就绪后端。 - 3 个更新后的副本都必须处于就绪且可用状态，并且集群内向
http://web-app发起的 HTTP 请求必须成功。 /home/labex/project/final-release/web-app.yaml必须包含最终镜像和发布配置，以便再次应用该文件时能够保留已验收的状态。
使用 Kubernetes 的检查和发布命令判断发布何时完成。如果更新仍在进行，请等待它完成，不要只根据第一次 kubectl get 的输出做判断。
提示
可以重点观察 Deployment 的 READY、UP-TO-DATE 和 AVAILABLE 列，检查 Pod 使用的镜像、发布历史以及 Service 的 EndpointSlice 地址。
总结
你已经独立完成了本课程：通过 Kubernetes Deployment 发布固定版本的 NGINX 镜像。你保留了明确的可用性配置，等待所有更新后的副本就绪，让 Service 继续连接到 3 个已就绪后端，验证了集群内请求，并将已验收状态持久化到 YAML 文件中。
这些检查构成了一套可复用的入门工作流程：声明期望状态、应用配置、观察控制器进度、验证工作负载及其访问路径，并让清单文件与集群保持同步。
