0 | Spinnaker 官网笔记

Spinnaker官网ConceptsApplication managementto view and manage your cloud resourcesSpinnaker 中的三个概念:Applications、 clusters、 server groups暴露服务给用户:Load bal

Spinnaker官网

Concepts

Application management

  • to view and manage your cloud resources

Spinnaker 中的三个概念:Applicationsclustersserver groups

暴露服务给用户:Load balancers 、firewall

架构图:

Application

Application 由多个 Cluster 组成、Cluster 由 Server Groups 组成。

Application 即所要部署的 Service。

Cluster

Server Group 的逻辑组合。

Server Group

可以理解成 VM images、docker image、source location 实体、配置信息的组合。

通常配备负载均衡、防火墙。

Load Balancer

ingress 协议+端口范围

  • 可选开启健康检查

Firewall

对某IP(段)的端口段的特定通信协议,进行流量控制。

Application deployment

Pipeline

由多个 Stage 组成。pipeline 可以手动/由事件触发,及对 pipeline 运行状态进行反馈。

Stage

简单理解,pipeline 的组成部分。有很多种 stage,像有很多个函数一样。

部署策略

Red/black(Blue/green)

绿色为新版本,蓝色为当前的稳定版本。当进行更新时,直接切到绿色的服务,如果服务不行,那么将请求全部转发到蓝色版本。

Rolling red/black

通过逐个替换为最新实例来完成部署。

Canary

在小范围内使用最新版本,发现异常立即回退到就版本;如果无异常情况,那么继续扩大新版本。

a/b testing

存在多个版本,通过统计,选出最优的版本。

Spinnaker架构

各服务简介

  • Deck : 用 typescript 写的前端页面。
  • Gate : API 网关。Deck 只通过 Gate 来获取服务。类似 nginx 做转发。
  • Orca : spinnaker 的控制中枢。执行定义好的具体事件,控制 stage、task 以及协调其他 spinnaker 服务。
  • Clouddriver : 为 spinnaker 提供与云厂商,如 AWS, GCE, CloudFoundry, Azure,的集成服务。
  • Front50 : 存储 spinnaker 各种数据,如 application, pipeline, projects, notification。在内存中进行缓存。
  • Rosco : 创建容器、镜像。
  • Igor : 为 spinnaker 提供与 CI 和 SCM 集成服务。即通过 CI jobs 来触发 pipeline。
  • Echo : 事件中心。在 pipeline 的某个阶段发送通知。
  • Fiat : 用户鉴权。

  • Kayenta : 自动化金丝雀分析。
  • Halyard : 配置服务。掌管上述服务的生命周期,但是只在 spinnaker 启动、更新、回滚时,与上面的服务进行交互。

服务间依赖

是不是最优的启动序列应该是这样:

  1. Fiat
  2. Rosco, Clouddriver, Front50, Keyenta
  3. Orca
  4. Echo
  5. Igor
  6. Gate
  7. Deck
启动依赖

涂色块表示:该列所表示的服务 依赖 该行所表示的服务。如:Deck 依赖 Gate。

服务端口

Service Port
Clouddriver 7002
Deck 9000
Echo 8089
Fiat 7003
Front50 8080
Gate 8084
Halyard 8064
Igor 8088
Kayenta 8090
Orca 8083
Rosco 8087

Spinnaker执行时序

Deploy 时序

Deploy 时序

Setup

Halyard 是一个工具集,会帮助拉取 spinnaker 各代码的源代码、启动脚本、日志目录、pid 文件等。

Kubernetes

网络策略

默认接受所有到该pod的流量。

Read more

容器镜像(4):镜像的常用工具箱

容器镜像(4):镜像的常用工具箱

前几篇在讲多架构镜像时已经用过 skopeo 和 crane 做镜像复制,这篇系统整理这两个工具的完整能力,同时介绍几个日常操作镜像时同样好用的工具。 一、skopeo:不依赖 Daemon 的镜像瑞士军刀 skopeo 的核心价值是绕过 Docker daemon,直接与 Registry API 交互。上一篇用它做镜像复制和离线传输,但它的能力远不止于此。 1.1 安装 # Ubuntu / Debian sudo apt install -y skopeo skopeo --version # skopeo version 1.15.1 1.2 inspect:免拉取检查镜像元数据 docker inspect 需要先把镜像拉到本地,skopeo inspect 直接向 Registry

容器镜像(3):多架构镜像构建

容器镜像(3):多架构镜像构建

一、什么是多架构镜像 1.1 OCI Image Index 上一篇介绍了单平台镜像的结构:一个 Manifest 指向 Config 和若干 Layer blob。多架构镜像在此之上多了一层——OCI Image Index(也叫 Manifest List),是一个轻量的索引文件,把多个单平台 Manifest 组织在一起: $ docker manifest inspect golang:1.22-alpine { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests&

容器镜像(2):containerd 视角下的镜像

容器镜像(2):containerd 视角下的镜像

一、为什么需要了解 containerd 如果你只用 docker run 跑容器,从来不关心底层,那可以不了解 containerd。但如果你在用 Kubernetes,或者想真正理解"容器运行时"是什么,containerd 是绕不开的。 事实上,当你执行 docker run 的时候,containerd 早就在后台悄悄工作了——Docker 从 1.11 版本开始,就把核心运行时剥离出来交给 containerd 负责。 1.1 Docker 的架构演变 早期的 Docker(1.10 及之前)是一个"大一统"的单体程序:一个 dockerd