4.1. 应用交付与实战

会部署一个 Pod，和能交付一套系统，是两件事。这一部分把 Helm、CI/CD、Ingress、存储、可观测性串成一条完整链路，再用三个真实案例检验你是否能把它们组合起来。

层级:: L4 · 实战
难度:: 实战
预计:: 60 分钟
前置:: 核心对象、平台能力

4.1.1. 你将学到

一个应用从镜像到集群的完整交付路径
Helm 如何把「一堆 YAML」变成可版本化、可回滚的制品
Jenkins 与 GitLab 在 Kubernetes 上的两种落地方式
三个综合案例的部署顺序、依赖与验收标准
交付环节最常见的失败点与排查入口

4.1.2. 交付的五个阶段

架构图

图：一条最小交付链路。每一段都可以手工执行，也可以交给流水线。

阶段	关键问题	本站对应章节
构建	镜像是否可复现、是否最小化	Jenkins、GitLab
打包	不同环境如何复用同一份清单	Helm
部署	用何种策略发布、失败如何回滚	工作负载
暴露	域名、TLS、灰度	负载均衡
观测	部署后如何确认真的健康	Prometheus

4.1.3. 三条实战路线

三个案例的复杂度递增，建议按顺序做：

4.1.3.1. 路线一：WordPress（单应用、全对象）

适合第一次把 Namespace、Secret、Service、StatefulSet、PVC、Deployment、Ingress 串起来。完成后你应该能回答：

为什么 MySQL 用 StatefulSet，而 WordPress 用 Deployment？
为什么 MySQL 需要 headless Service？
删除 WordPress Pod 后，为什么数据还在？

进入：WordPress 综合实战

4.1.3.2. 路线二：微服务商城（多组件、依赖顺序）

Nacos、Redis、RabbitMQ、MongoDB、MinIO、ElasticStack、SkyWalking 依次上线，最后部署 mall 应用。重点不是「装起来」，而是理解：

基础服务的启动顺序与健康检查；
注册中心 / 配置中心挂了，应用会表现成什么样；
如何用 SkyWalking 把一次请求串起来。

进入：微服务商城

4.1.3.3. 路线三：私有云（基础设施 + 平台 + 应用）

从 OpenStack Heat 模板创建虚拟机，到 kubeadm 集群、Flannel、ingress-nginx、Kuboard、基础服务、商城应用。这是最接近「从零交付一个私有云」的路径。

进入：私有云案例

4.1.4. 工具链定位

工具	解决什么	不该拿它做什么
Helm	打包、模板化、版本化发布	替代 GitOps 的持续同步
Jenkins	通用 CI/CD 编排、复杂构建	轻量定时任务（用 CronJob）
GitLab	代码托管 + 内置 CI + 容器 registry	小团队的唯一监控系统
Kuboard	可视化排错、RBAC 展示	代替 `kubectl` 做精确操作
Argo CD（未展开）	Git 作为唯一事实源的持续部署	手工 hotfix 的替代品

小技巧

先手工，再自动化

在写 Pipeline 之前，先把整条链路手工跑通：docker build → docker push → helm upgrade --install → kubectl rollout status。流水线只是把这些命令固化，手工都没跑通就自动化，只会把错误藏得更深。

4.1.5. 一个最小可用的交付检查清单

每次发布前逐项确认：

镜像使用不可变 tag（commit sha / digest），不是 latest
资源配置了 requests/limits，并设置了合理的探针
用 helm template 或 kubectl diff 预览过变更
有 rollout status 与失败回滚命令
数据库变更可向前兼容，回滚不会丢数据
Ingress / Service 的端口与后端一致
发布后检查错误率、延迟、Pod 重启次数
知道这次发布如何回滚，以及回滚需要多久

4.1.6. 实验环境假设

交付章节的案例默认你已经有：

一个至少 3 节点的 Kubernetes v1.31 集群；
可用的默认 StorageClass（NFS CSI 或 OpenEBS）；
ingress-nginx 与 MetalLB（或云 LB）；
Helm 3.16+、kubectl、git；
能访问镜像仓库（或已配置镜像加速）。

如果缺其中一项，先回到平台能力总览补齐，不要在案例里临时修基础设施。

4.1.7. 常见失败点

失败点	典型现象	先去哪里看
镜像拉取失败	`ImagePullBackOff`	`kubectl describe pod` 的 Events
存储未绑定	Pod `Pending`，PVC `Pending`	`kubectl describe pvc`
依赖服务未就绪	应用 `CrashLoopBackOff`	应用日志 + 依赖的 Endpoints
资源不足	Pod `Pending`，节点 `DiskPressure`	`kubectl describe node`
Ingress 502	外部访问失败，Pod 正常	`kubectl get endpoints`、Ingress 注解
发布卡住	`rollout status` 超时	`kubectl rollout history`、新 Pod 事件

4.1.8. 小结

交付不是「apply 一下」，而是构建、打包、部署、暴露、观测、回滚的闭环。
Helm 解决复用与版本化，CI/CD 解决一致性，案例解决「组合能力」。
三个案例不必全做，但至少完整做完一个，并亲手制造一次失败再恢复。