应用交付与实战¶
会部署一个 Pod，和能交付一套系统，是两件事。这一部分把 Helm、CI/CD、Ingress、存储、可观测性串成一条完整链路，再用三个真实案例检验你是否能把它们组合起来。
你将学到¶
- 一个应用从镜像到集群的完整交付路径
- Helm 如何把「一堆 YAML」变成可版本化、可回滚的制品
- Jenkins 与 GitLab 在 Kubernetes 上的两种落地方式
- 三个综合案例的部署顺序、依赖与验收标准
- 交付环节最常见的失败点与排查入口
交付的五个阶段¶
flowchart LR
A[代码提交] --> B[构建镜像]
B --> C[推送仓库]
C --> D[渲染清单]
D --> E[部署到集群]
E --> F[验证与观测]
F -->|失败| G[回滚]
G --> E图：一条最小交付链路。每一段都可以手工执行，也可以交给流水线。
| 阶段 | 关键问题 | 本站对应章节 |
|---|---|---|
| 构建 | 镜像是否可复现、是否最小化 | Jenkins、GitLab |
| 打包 | 不同环境如何复用同一份清单 | Helm |
| 部署 | 用何种策略发布、失败如何回滚 | 工作负载 |
| 暴露 | 域名、TLS、灰度 | 负载均衡 |
| 观测 | 部署后如何确认真的健康 | Prometheus |
三条实战路线¶
三个案例的复杂度递增，建议按顺序做：
路线一：WordPress（单应用、全对象）¶
适合第一次把 Namespace、Secret、Service、StatefulSet、PVC、Deployment、Ingress 串起来。完成后你应该能回答：
- 为什么 MySQL 用 StatefulSet，而 WordPress 用 Deployment？
- 为什么 MySQL 需要 headless Service？
- 删除 WordPress Pod 后，为什么数据还在？
路线二：微服务商城（多组件、依赖顺序）¶
Nacos、Redis、RabbitMQ、MongoDB、MinIO、ElasticStack、SkyWalking 依次上线，最后部署 mall 应用。重点不是「装起来」，而是理解：
- 基础服务的启动顺序与健康检查；
- 注册中心 / 配置中心挂了，应用会表现成什么样；
- 如何用 SkyWalking 把一次请求串起来。
进入：微服务商城
路线三：私有云（基础设施 + 平台 + 应用）¶
从 OpenStack Heat 模板创建虚拟机，到 kubeadm 集群、Flannel、ingress-nginx、Kuboard、基础服务、商城应用。这是最接近「从零交付一个私有云」的路径。
进入：私有云案例
工具链定位¶
| 工具 | 解决什么 | 不该拿它做什么 |
|---|---|---|
| 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。流水线只是把这些命令固化，手工都没跑通就自动化，只会把错误藏得更深。
一个最小可用的交付检查清单¶
每次发布前逐项确认：
- 镜像使用不可变 tag（commit sha / digest），不是
latest - 资源配置了 requests/limits，并设置了合理的探针
- 用
helm template或kubectl diff预览过变更 - 有
rollout status与失败回滚命令 - 数据库变更可向前兼容，回滚不会丢数据
- Ingress / Service 的端口与后端一致
- 发布后检查错误率、延迟、Pod 重启次数
- 知道这次发布如何回滚，以及回滚需要多久
实验环境假设¶
交付章节的案例默认你已经有：
- 一个至少 3 节点的 Kubernetes v1.31 集群；
- 可用的默认 StorageClass（NFS CSI 或 OpenEBS）；
- ingress-nginx 与 MetalLB（或云 LB）；
- Helm 3.16+、
kubectl、git； - 能访问镜像仓库（或已配置镜像加速）。
如果缺其中一项，先回到 平台能力总览 补齐，不要在案例里临时修基础设施。
常见失败点¶
| 失败点 | 典型现象 | 先去哪里看 |
|---|---|---|
| 镜像拉取失败 | 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 事件 |
小结¶
- 交付不是「apply 一下」，而是构建、打包、部署、暴露、观测、回滚的闭环。
- Helm 解决复用与版本化，CI/CD 解决一致性，案例解决「组合能力」。
- 三个案例不必全做，但至少完整做完一个，并亲手制造一次失败再恢复。