实践是推广一个产品或技术的最好的方式，特别在IT行业让产品管理产品本事，就是一种很好的推广方式，例如Docker in Docker、k8s in k8s，这些已经被大家普遍接受。所以我觉得spinnaker要想很好的推广开来，也需要类似的应用方案，我把它称为Spinnaker On Spinnaker。

 

架构图如下：

最上面部分是主spinnaker，或者叫master spinnaker，这个spinnaker用来管理每条业务线真正使用的spinnaker。Master spinnaker中只对接一个容器云，利用spinnaker管理k8s的方式来为业务线发布和更新子spinnaker系统。

 

中间部分就是部署子spinnaker的那套容器云，我们采用代码配置分离的方式来管理它们，这样管理的优点会在下文中做解释。这套容器云要做的事情就很简单了，根据预先准备的每个spinnaker微服务镜像，挂载业务线自己的配置，然后启动对应服务。我这里举例场景中有3条业务线在用spinnaker，Odin、Tinker和Loki。

 

最下面部分就是业务线中真正操作使用spinnaker的团队了，每个子spinnaker需要一个项目管理员负责自己spinnaker的权限管理、pipeline配置等，但是他不可更改云平台认证相关的信息，剩下的团队成员就是一线的研发、测试和运维同学了，他们享受着spinnaker自动化带来的福利。

 

Spinnaker On Spinnaker设计的优点：

1 职责分担

  设想如果没有这种内嵌设计，Spinnaker的管理员除开维护Spinnaker本身的应用的配置，还需要维护到所有产品线的所有资源和所有pipeline，这对于管理员来说是灾难性的，因为他不具备一线人员对产品和运维上的理解能力，他不可能搞得清负载均衡的名称、实例上要打哪些tag这些细如牛毛的琐事。

  现在引入Spinnaker On Spinnaker的设计，Spinnaker的master管理员只需要配置每个子spinnaker的账号信息，偶尔更新一下spinnaker版本、接入新子项目即可；而每个子项目的spinnaker具有自己产品线除云账号以外的所有配置权力，他们是跟着业务线走的，所以他们具备spinnaker master不具备的业务知识。

 

2 账户隔离

  2.1 资源隔离

  每条产品线使用自己的云资源账号，在master spinnaker中给这个子spinnaker配置好账号后，子spinnaker的admin就可以看到自己账号云平台下的所有资源。假如没有内嵌设计，很难做到账号级别的资源隔离，一旦有维护不到的application就会导致所有spinnaker用户都可以访问和修改这些资源，作为生产级别的产品这是不能容忍的。

  2.2 服务隔离

  每个子spinnaker需要扩容或者重启服务，master spinnaker直接就对他们做操作，因为他们的服务是隔离的。假如没有内嵌设计，spinnaker的使用者被绑定在一套服务中，其中一个要求重启，所有人都将受到影响。

 

3 高可用性

我们来直接模拟故障吧。

子spinnaker本身就是由容器云，理论上容器云中的资源可以通过重启容器等方式快速恢复的，所以我们先不考虑子spinnaker出现故障的场景，而且spinnaker除开云平台鉴权信息存在本地，pipeline和配置信息存在S3等云存储上，剩下的都是直接在云平台中采集的资源，所以不存在数据丢失的场景。

那么最大的单点故障就是在master spinnaker上了，假如没有内嵌设计，spinnaker挂了后所有产品线都将瘫痪，云资源虽然不受影响，但不能进行自动化的软件本发布了。有了内嵌设计，master spinnaker就算挂了，也是失去了对承载子spinnaker的容器云的控制，不能添加和修改子spinnaker的而已，不会影响现有子spinnaker的正常使用。

 

以上设计只是一个雏形，理论上是不存在问题的，同时也欢迎大家指出其中的不足。当然，所有的理论能否落地是需要一批志同道合的同事们一起努力才能实现的，目前在spinnaker推广和使用中略显孤独。