Cattle not Pets = 无状态基础设施
解决什么问题：服务器维护成本高，故障恢复慢—— 不维护具体服务器 = 标准化资源 + 应用无状态。
业务问题
真实场景
场景 1：宠物模式
传统运维：
- 每台服务器有名字（web01, web02, db-prod-01）
- 有历史（"这台机器 2018 年装的 SSL 证书"）
- 精心维护（手动 SSH 上去修）
- 死了 = 灾难
- 不可替代（需要同样环境）
问题：
- 维护成本高
- 故障恢复慢
- 不一致（"我机器上能跑"）场景 2：牲畜模式
CaaS 模式：
- 机器无名（k8s-pod-abc123）
- 无历史（每次重启都是新机器）
- 不维护（坏了就替换）
- 死了 = 重新拉一个
- 完全可替代（标准化镜像）Cattle vs Pets 对比
| 维度 | Pets（宠物） | Cattle（牲畜） |
|---|---|---|
| 名字 | 有 | 无 |
| 历史 | 累积 | 每次重置 |
| 维护 | 精心 | 不维护 |
| 失败处理 | 修复 | 替换 |
| 可替代 | 难 | 完全 |
| 运维模型 | SSH 登录 | API 调度 |
| 资源利用率 | 低 | 高 |
应用的要求
应用必须：
- 无状态（不依赖本地存储）
- 容忍重启（快速启动）
- 幂等（多次运行同结果）
- 可观测（外部看状态）
不满足的应用：
- 依赖本地文件
- 启动慢（> 1 分钟）
- 状态在内存
- 不能被外部探测Google 的演化路径
Borg（内部）→ Omega（Borg 2）→ Kubernetes（开源）
能力：
- 资源调度（CPU / 内存 / 网络）
- 任务编排（启动 / 停止 / 扩缩容）
- 故障恢复（自动重启失败实例）
- 滚动升级（无停机）工程实践
决策 1：何时从 Pets 迁移到 Cattle
判断：
- 服务器数量 > 10 → 考虑 CaaS
- 故障恢复时间 > 1h → 必须 CaaS
- 利用率 < 30% → CaaS 能省钱决策 2：如何改造应用
步骤：
1. 状态外置（Redis / DB / 对象存储）
2. 配置外置（环境变量 / ConfigMap）
3. 启动优化（懒加载 / 预热）
4. 健康检查（/health 端点）
5. 优雅退出（处理 SIGTERM）与 L 层对位
关键洞察
- Pets = 维护负担——不可扩展。
- Cattle = 标准化 + 自动化——可扩展。
- 应用无状态是前提——不是 CaaS 让你无状态。
- 故障自愈 = 不需要运维英雄。
- 与 cybernetics 同构——Ch 21 多级分散 = 牲畜模式。