DevOpsKubernetesInfrastructureCloud Native
临时基础设施 - 为什么短生命周期是好事
收录于 2026/5/27 23:39:53
什么是 Ephemeral（临时）基础设施？
比喻：
- 公寓 → 长期居住，自己维护，坏了自己修
- 酒店房间 → 短暂停留，离开后打扫干净，恢复初始状态
Ephemeral 基础设施 = 把服务器、容器当作酒店房间，而不是公寓。
临时资源示例
| 类型 | 说明 |
|---|---|
| Kubernetes Pods | 随时可能被杀死替换，存活数小时到数周 |
| CI/CD Runners | 每个任务一个新环境，任务结束即销毁 |
| Lambda Functions | 执行完就消失（或回收） |
| Auto-scaling Instances | 流量高峰出现，低谷消失，是"牲口"不是"宠物" |
为什么短生命周期更好？
1. 强制无状态设计
坏（有状态）：
Pod 内存存储用户会话 → Pod 崩溃 → 所有会话丢失 → 用户登出
好（无状态）：
Pod 会话存 Redis → Pod 崩溃 → 新 Pod 启动 → 用户保持登录
临时基础设施强迫你做正确的事。
2. 自动自愈
| 传统方式 | 临时方式 |
|---|---|
| 服务器崩溃 → SSH 登录 → 调试数小时 → 也许修好 | Pod 崩溃 → K8s 检测 → 启动新 Pod → 秒级完成 |
不需要"修复"，直接替换。
3. 消除配置漂移
- 传统服务器：三年前有人"临时"装了个包，现在没人知道为什么
- 临时基础设施：每次都从相同镜像启动，无累积变化，无神秘配置
4. 扩展变得简单
- 需要更多容量？启动更多 Pod
- 需要减少？杀掉一些 Pod
- 扩展只是一个数字
数据怎么办？
Pod 是临时的，数据不是：
volumes: - name: data persistentVolumeClaim: claimName: my-pvc # 数据在这里，不在 Pod 里
- Pod 可随时杀死重建
- 数据在 PersistentVolume，持久存在
Pod 被替换的场景
- 滚动更新（部署新版本）
- 节点维护（排空节点）
- 资源压力（内存不足）
- 健康检查失败
- 缩容
这在生产环境 constantly 发生，而且这正是你想要的。
数据库怎么办？
数据库天生有状态，不能直接杀掉重建。
但可以应用临时原则：
| 组件 | 策略 |
|---|---|
| Database Pod | 临时 → PersistentVolume 持久 |
| 托管数据库 | RDS/Cloud SQL，抽象掉服务器 |
| 只读副本 | 可以是临时的 |
Ephemeral vs Immutable
| 概念 | 定义 | 示例 |
|---|---|---|
| Ephemeral | 设计上短生命周期 | CI runner 存在 2 分钟 |
| Immutable | 创建后不可修改 | Docker 镜像、版本化配置文件 |
不同概念，但实践中通常一起出现：
- Pod 只存活几小时 → 为什么还要修改它？
- 自然推动你构建新镜像并重新部署
实践对比：Web 应用
传统（长生命周期）：
部署 EC2 → 安装应用 → 配置 → 运行数月 → 打补丁 → SSH 调试 → "别碰它，能跑"
临时方式：
构建 Docker 镜像 → 推送到 Registry → K8s 拉取镜像启动 Pod →
部署新版本时旧 Pod 死，新 Pod 生 → 出问题？重启 Pod → 无需 SSH
代价
| 代价 | 说明 |
|---|---|
| 启动时间 | 应用启动需 5 分钟？问题。需优化启动速度 |
| 调试更难 | Pod 崩溃后无法 SSH，需提前做好日志和可观测性 |
| 有状态负载复杂 | 数据库等需要更仔细的设计 |
核心结论
现代系统默认已部分临时化：
- Kubernetes 集群 → 临时 Pod
- CI/CD 流水线 → 临时 Runner
- Serverless 函数 → 天生临时
- Auto-scaling 组 → 临时实例
问题不是"是否使用临时基础设施"，而是"多少应该是临时的"。
作者建议：
让一切都可以是临时的，除了必须有状态的部分（数据库、消息队列等）。即使它们，也让计算临时，只保留存储持久。
与证书撤销的关联
这篇和 X.509 证书撤销文章形成了有趣的呼应——短生命周期证书和临时基础设施都是用"缩短生命周期"来解决信任/稳定性问题。