容器编排环境下应用生命周期管理核心是“何时停、如何稳停、能否快恢”，Kubernetes通过声明式配置、探针机制、优雅终止和自动清理实现发布、运行、下线、回收闭环。
容器编排环境下的应用生命周期管理，核心不是“能不能停”，而是“什么时候停、怎么停得稳、停完还能不能快速恢复”。Kubernetes 等编排平台把单个容器的启停升级为面向服务的发布、扩缩、滚动更新、健康检查和自动清理闭环，自动化不是锦上添花，而是生产环境的刚性要求。
发布阶段：用声明式配置替代手动部署
应用上线不再靠人执行 docker run 或 kubectl create，而是通过 YAML 文件定义期望状态。镜像版本、副本数、环境变量、资源配置都固化在 Git 仓库中，CI/CD 流水线触发后由控制器自动比对并同步集群状态。
- 使用 Deployment 而非裸 Pod，获得滚动更新、回滚、版本追踪能力
- 镜像标签建议用语义化版本（如
v1.2.0），避免使用latest，确保可追溯 - 配合 ConfigMap 和 Secret 分离配置与代码，发布时仅需更新 Deployment 中的镜像字段
运行阶段：靠探针和策略维持服务稳定性
容器启动成功 ≠ 服务就绪。编排系统需要知道“应用是否真正可用”，这依赖于 Liveness 和 Readiness 探针的协同判断。
- Readiness Probe 决定是否将流量导入该实例；失败时自动从 Service 的 Endpoint 中剔除
- Liveness Probe 判定进程是否存活；连续失败后由 kubelet 重启容器，而非等待进程僵死
- 探针类型优先选 HTTP GET（轻量）或 exec（适合无网络服务），超时和阈值需结合应用冷启动时间设定
停止与下线：优雅终止是服务可靠的关键环节
强制 kill 容器会中断请求、丢数据、破坏事务一致性。真正的自动化下线必须尊重应用自身的退出逻辑。
- 容器内主进程应监听 SIGTERM 信号，在收到后完成连接关闭、缓存刷新、日志刷盘等清理动作
- Kubernetes 默认给予 30 秒 terminationGracePeriodSeconds，长任务类应用需显式延长
- 滚动更新时，新 Pod 就绪后再逐批终止旧 Pod；蓝绿或金丝雀发布则需配合 Service 和 Ingress 的权重切换
清理与回收：避免资源泄漏的自动兜底机制
停止不等于结束。残留的 Pod、Event、ConfigMap、PV/PVC 若无人干预，会持续占用命名空间和底层存储。
- 设置 ttlSecondsAfterFinished 自动清理 Job 类型资源
- 对临时测试环境，用 Namespace + ResourceQuota + LimitRange 实现配额硬约束
- 定期运行
kubectl get pods --all-namespaces --field-selector status.phase=Failed -o name | xargs -r kubectl delete清理失败 Pod（建议封装为 CronJob）
