Spinnaker 是 Netflix 开源的多云持续交付（Continuous Delivery）平台，专为在 AWS、Kubernetes、GCE 等多套基础设施上安全地自动化发布而设计。当团队从”能部署”演进到”可控地持续部署”时，Spinnaker 用声明式流水线把构建、审批、灰度与回滚串成一条可审计的发布链路，弥补了单纯 CI 工具在”部署治理”上的短板。
一、为什么需要 Spinnaker：CI 之后的部署鸿沟
GitHub Actions、GitLab CI 这类工具擅长”构建出产物”，但把产物安全地推到生产往往需要人工点击、跨云账号授权和发布策略控制。Spinnaker 的定位正是 CD 层：它接管”部署后”的一切——多环境推进、手动门禁、金丝雀分析、一键回滚。它与 GitHub Actions 搭建 CI/CD 流水线 是互补关系：前者出包，后者发版。
二、核心概念：Pipeline、Stage 与 Cluster
理解四个概念即可上手：
- Application：一组相关服务的集合，是权限与视图的边界。
- Pipeline：一条发布流水线，由多个 Stage 顺序或并行组成。
- Stage：流水线的原子步骤，如”部署到测试集群””等待人工审批””运行金丝雀”。
- Server Group / Cluster：某一应用在某云上的版本化实例组，回滚就是切换活跃 Server Group。
三、架构组件：各司其职的微服务
Spinnaker 本身由多个微服务构成，了解它们有助于排障：
| 组件 | 职责 |
|---|---|
| Deck | 前端 UI |
| Gate | API 网关，所有请求入口 |
| Orca | 流水线编排引擎，调度 Stage |
| Clouddriver | 对接各云厂商 / K8s，缓存资源状态 |
| Rosco | 构建机器镜像（VM 场景） |
| Front50 | 持久化 Pipeline / Application 元数据 |
四、本地快速部署：用 Halyard 安装
生产推荐 Halyard 作为安装器。最小化的单机（仅 K8s 云账号）安装如下：
# 进入 Halyard 容器
docker exec -it halyard bash
# 1. 选择部署类型（分布式，适合上 K8s）
hal config deploy edit --type distributed --account-name spinnaker
# 2. 添加 Kubernetes 云账号
hal config provider kubernetes account add spin-prod \
--provider-version v2 \
--context $(kubectl config current-context) \
--service-account true
hal config provider kubernetes enable
# 3. 选择存储（本机 Minimal 仅用于试用）
echo "redis" > ~/.hal/default/storage/storage.yml
hal config storage edit --type redis
# 4. 应用并部署
hal deploy apply部署完成后，通过 ~/.kube/config 指向的目标集群查看 spinnaker 命名空间即可验证。若需对外暴露 UI，可参考 Nginx 反向代理完整配置 做一层 HTTPS 反代。
五、编写第一条流水线：从镜像到 K8s 部署
一条典型的”构建后自动部署到预发”流水线包含三个 Stage。下面用 Spinnaker 的 Pipeline JSON 片段说明关键结构：
{
"stages": [
{
"type": "deployManifest",
"name": "Deploy to staging",
"manifest": {
"apiVersion": "apps/v1",
"kind": "Deployment",
"metadata": { "name": "demo-api", "namespace": "staging" },
"spec": {
"replicas": 2,
"template": {
"spec": {
"containers": [
{ "name": "demo-api", "image": "registry.demo.io/demo-api:{{trigger.tag}}" }
]
}
}
}
}
},
{
"type": "manualJudgment",
"name": "Approve to prod",
"instructions": "确认预发无异常后再推进生产"
},
{
"type": "deployManifest",
"name": "Deploy to prod",
"manifestArtifact": { "reference": "https://git.demo.io/manifests/prod.yaml" }
}
]
}其中 {{trigger.tag}} 是触发器传入的镜像标签，支持 Git Tag、Jenkins、Docker Registry 等多种触发源，可与 Docker 容器编排 流水线无缝衔接。
六、多云平台：一份 Pipeline 发往 AWS 与 K8s
Spinnaker 的强项是”同一份发布逻辑跨云执行”。你可以在一条 Pipeline 里并行两个 deployManifest Stage，分别指向 AWS EKS 与自建 K8s 账号，实现双云同版本发布；异常时各自回滚，互不影响。对多区域容灾而言，这比手写多套脚本可靠得多。
七、金丝雀发布与自动化策略
Spinnaker 原生支持 Kayenta 金丝雀分析：先放 10% 流量到新版本，对比错误率、延迟、QPS 等指标，达标才继续。配合 Prometheus + Grafana 监控面板 的指标源，能把”凭感觉发布”变成”看数据推进”。常用策略：
- Red/Black（蓝绿）：新集群起好，流量整体切过去，旧集群保留以便回滚。
- Canary：按比例灰度，靠指标分析决定扩量或中止。
- Pipeline Stage 回滚：出现异常时一键 disable 新 Server Group。
八、Spinnaker 与 Argo CD / Flux CD 怎么选
| 维度 | Spinnaker | Argo CD | Flux CD |
|---|---|---|---|
| 核心范式 | 声明式 Pipeline（命令式发布） | GitOps 同步 | GitOps 同步 |
| 多云支持 | 原生强（AWS/GCE/K8s） | 仅 K8s | 仅 K8s |
| 发布策略 | 蓝绿/金丝雀/门禁 | 渐进式需插件 | 渐进式需插件 |
| 运维复杂度 | 高（多微服务） | 中 | 低 |
| 适用场景 | 多云平台、强发布治理 | K8s GitOps | 轻量 K8s GitOps |
如果你的世界只有 Kubernetes，ArgoCD 用 GitOps 实现 K8s 持续部署 或 Flux CD 更轻；若横跨多家云、需要统一的发布门禁与审批流，Spinnaker 仍是无可替代的选择。
九、生产落地清单与常见排障
| 问题 | 根因 | 处理 |
|---|---|---|
| Pipeline 卡在 running | Orca 与 Redis 连接中断 | 检查 redis 存活与 orca 日志 |
| K8s 账号读不到资源 | serviceAccount 权限不足 | 补齐 ClusterRole 的 get/list/watch |
| 部署无反应 | Clouddriver 缓存未刷新 | 触发 Force Cache Refresh |
| UI 打不开 | Gate 未暴露 | 核对反代与 8084 端口 |
十、用 Webhook 把 CI 与 Spinnaker 串起来
Spinnaker 不取代 CI，而是承接它的产物。最干净的做法是让 CI 在构建镜像并推送到仓库后，通过 Webhook 触发 Spinnaker Pipeline。下面用一条 curl 调用 Gate 的 API 触发，可在 GitHub Actions 的最后一个 Job 里直接执行：
# 用 Pipeline ID 触发，并传入镜像 tag 作为参数
curl -X POST "https://gate.demo.io/api/v1/pipelines/spinnaker-demo-api" \
-H "Authorization: Bearer $SPINNAKER_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"parameters": { "tag": "'"$IMAGE_TAG"'" },
"application": "demo-api"
}'这样构建与发布解耦：开发只关心代码合入，Spinnaker 负责把”某个 tag”按既定策略安全地推到各云。触发源也可以是 Git Tag、Docker Registry 推送事件或定时，灵活度足够覆盖绝大多数发布场景。
十一、Kayenta 金丝雀分析配置示例
金丝雀的关键不是”放 10% 流量”，而是”用指标判断该不该继续”。Spinnaker 集成 Kayenta，把新版本与基线版本在相同时间窗内的指标做对比，给出 pass/fail。一个简化的判断配置如下：
{
"canaryConfig": {
"metrics": [
{ "name": "error_rate", "query": "rate(http_5xx[5m])", "direction": "lowerIsBetter", "threshold": 0.01 },
{ "name": "p99_latency", "query": "histogram_quantile(0.99, http_duration)", "direction": "lowerIsBetter", "threshold": 0.3 }
],
"judge": { "minimumBatchSize": 20, "passThreshold": 90 }
}
}| 指标 | 方向 | 阈值 |
|---|---|---|
| 错误率 | 越低越好 | < 1% |
| P99 延迟 | 越低越好 | < 300ms |
| 通过率 | 越高越好 | ≥ 90% |
指标源可接 Prometheus、Datadog 等。判断不通过时 Pipeline 自动中止并保留旧版本，把”人为拍板”替换为”数据裁决”，发布事故率显著下降。
十二、何时该上 Spinnaker，何时不该
Spinnaker 不是银弹，引入前先对号入座，避免为”看起来高级”而背上运维负担：
| 你的现状 | 建议 |
|---|---|
| 只在单一 K8s 集群，团队小 | 先用 Argo CD / Flux CD，别碰 Spinnaker |
| 横跨 AWS + 自建 K8s，需统一发布门禁 | Spinnaker 正解 |
| 发布需合规审批、留痕审计 | Spinnaker 的 manualJudgment + 审计天然契合 |
| 人力紧张、不愿养多套微服务 | 谨慎，先用托管 CD 或脚本 |
一句话：当”部署”本身成为需要治理的对象——多环境、多账号、多合规要求——Spinnaker 的价值才真正显现；否则轻量方案更划算。
十三、小结
Spinnaker 把”多云持续交付”从一堆脚本升级为可视化、可审计、可治理的发布平台。它适合已有成熟 CI、正在追求安全可控发布的团队；起步成本高，但换来的是跨云统一的发布纪律与一键回滚能力。小团队若只在 K8s 内，可先从 Argo CD / Flux CD 起步，等业务跨云再引入 Spinnaker 也不迟。
