1. 为什么会有 Spinnaker：复杂发布需要“舞台调度”
Spinnaker 被设计用来解决这样的问题：当你同时面对多云、多环境、不同应用的依赖、 以及各种发布策略（例如逐步推进、等待、人工审批、自动回滚）时，仅靠单一 CI/CD 工具往往无法把流程优雅地建模。 它把复杂发布当作可编排的工作流（workflow）：你可以选择触发方式、拆分 stage、设置并行与依赖、记录每次执行的证据。
2. 四个核心对象：Application / Pipeline / Stage / Execution
你可以用一句话记住 Spinnaker 的对象关系：一个 Application 拥有 Pipeline； Pipeline 由多个 Stage 组成；每次运行 pipeline 的具体过程叫Execution。 它们分别回答：你部署的是谁（Application）、流程长什么样（Pipeline）、每一步做什么（Stage）、每一次运行发生了什么（Execution）。
3. 触发器（Trigger）与执行（Execution）是两件事
触发器回答“什么时候开始”：例如定时、手动点击、来自 CI 的 webhook、或对 artifact 的新版本检测。 执行则回答“开始后发生了什么”：每次 stage 的输入输出、状态变化、重试次数、跳过逻辑、以及失败时如何处理。 如果你把 Spinnaker 当成“发布日历”，那执行就是日历背后的账本：可回放、可审计、可讨论。
4. 流水线（Pipeline）是 Stage 的编排，而不是“一个按钮”
Pipeline 通常包含一个或多个阶段序列。每个阶段可以是部署、构建、等待、人工判断或自动分析。 更重要的是：stage 之间可以并行（parallel branch），也可以通过依赖关系（dependencies）串联。 这使得复杂发布能被工程化：你可以把策略写成 stage graph，把风险控制写成 gating / retry rules。
5. 用 JSON 想象 Spinnaker Pipeline：把策略写进配置
Spinnaker 的 pipeline 定义通常以 JSON 形式存储并由系统解析。 你无需在本章实现全部细节，但要读出“配置表达了流程”这一点：触发、stage 列表、每个 stage 的关键参数，以及失败时的处理。 当你把策略写成配置，你就能做复用、审计和回滚。
// Illustrative (simplified) pipeline config structure
{
"name": "payments-pipeline",
"application": "payments",
"stages": [
{ "type": "bakeManifest", "name": "Bake" },
{ "type": "deploy", "name": "Deploy Canaries", "clusters": ["prod"], "traffic": "10%" },
{ "type": "manualJudgment", "name": "Approve?", "timeoutMinutes": 30 },
{ "type": "rollback", "name": "Rollback on Fail" }
],
"triggers": [
{ "type": "webhook", "artifact": "docker-image" }
]
}6. 治理与集成：Spinnaker 的“多账户世界”
在多云环境中，Spinnaker 需要把不同云的访问凭据与权限隔离起来。 它会通过账户（accounts）/命名空间/角色等机制，让不同团队对不同云资源拥有最小权限。 同时它还要处理 artifact（比如镜像或制品）、网络与负载均衡、以及发布时的校验与回调。 因此你可以把 Spinnaker 看成“发布的操作系统”，把云平台的差异统一抽象成 stage 类型和插件接口。
7. 本章清单
- 理解 Spinnaker 为何存在：复杂多云 CD 需要可编排的工作流调度。
- 能准确说出四个核心对象的关系：Application → Pipeline → Stage → Execution。
- 能区分 Trigger 与 Execution：前者回答“何时开始”，后者回答“发生了什么”。
- 掌握 Pipeline 的图模型：串行与并行分支、join、失败处理。
- 能读懂简化 pipeline 配置结构：stage 列表、触发器、以及策略表达。
- 知道多账户分区与最小权限如何在 stage 层落实，并为治理提供审计证据。
- 预告下一章：第 58 章深入 Spinnaker 的发布策略（canary analysis 与自动判定）。