有货在Kubernetes容器环境的CD实践(季邦华分享)
分享内容如下：
1.spinnaker介绍与安装踩过的坑。
2.spinnaker在kubernetes的持续部署。
3.线上容器服务的选择与多区容灾。
spinnaker介绍
Spinnaker 是 Netflix 的开源项目，是一个持续交付平台，它定位于将产品快速且持续的部署到多种云平台上。Spinnaker 有两个核心的功能集群管理和部署管理。Spinnaker 通过将发布和各个云平台解耦，来将部署流程流水线化，从而降低平台迁移或多云品台部署应用的复杂度，它本身内部支持 Google、AWS EC2、Microsoft Azure、Kubernetes和 OpenStack 等云平台，并且它可以无缝集成其他持续集成（CI）流程，如 git、Jenkins、Travis CI、Docker registry、cron 调度器等。
应用管理
spinnaker主要用于展示与管理你的云端资源.先要了解一些关键的概念：Applications, clusters, and server groups,通过Load balancers and firewalls 将服务展示给用户。官方给的结构如下：
Application
定义了集群中一组的cluster的集合，也包括了firewalls 与 load balancers，存储了服务所有的部署相关的的信息。
Server Group
定义了一些基础的源比如(VM image, Docker image),以及一些基础的配置信息，一旦部署后，在容器中对应Kubernetes pods的集合。
Cluster
Server Groups的有关联的集合。（Cluster中可以按照dev，prod的去创建不同的服务组），也可以理解为对于一个应用存在多个分支的情况。
Load Balancer
他在实例之间做负载均衡流量。您还可以为负载均衡器启用健康检查，灵活地定义健康标准并指定健康检查端点，有点类似于kubernetes中ingress。
Firewall
防火墙定义了网络流量访问，定义了一些访问的规则，如安全组等等。
页面预览
页面展示如下，还是比较精简的，可以在它的操作页面上看到项目以及应用的详细信息，还可以进行集群的伸缩，回滚，修改以及删除的操作。
下面介绍下spinnaker的部署管理功能
下图中，infrastructure左侧为PIPELINE的设计：主要讲两块内容：pipeline的创建，与部署的策略。
Pipeline
1、较强的 Pipeline 的能力：它的 Pipeline 可以复杂到无以复加，它还有很强的表达式功能(后续的操作中前面的参数均通过表达式获取)。
2、触发的方式：定时任务，人工触发，jenkinsjob，docker images，或者其他的pipeline的步骤。
3、通知方式：email, SMS or HipChat.
4、将所有的操作都融合到pipeline中，比如回滚、金丝雀分析、关联CI等等。
spinnaker安装踩过的坑
很多人都是感觉这个很难安装，其实主要的原因还是墙的问题，只要把这个解决了就会方便很多，官方的文档写的很详细，而且spinnaker的社区也非常的活跃，有问题均可以在上面进行提问。
安装提供的方式：
1、Halyard安装方式(官方推荐安装方式)
>>我采用Halyard安装方式，因为后期我们会集成很多其他的插件，类似于gitlab，ldap，kayenta，甚至多个jenkins，kubernetes服务等等，可配置性较强。
2、Helm搭建Spinnaker平台
3、Development版本安装
>>helm方式若是需要自定义一些个性化的内容会比较复杂，完全依赖于原始镜像，而Development需要对spinnaker非常的熟悉，以及每个版本之间的对应关系均要了解。
Halyard方式安装注意点：
Halyard代理的配置
```
vim /opt/halyard/bin/halyard
DEFAULT_JVM_OPTS='-Dhttp.proxyHost=192.168.102.10 -Dhttps.proxyPort=3128'
```
部署机器配置
由于spinnaker涉及的应用较多，下面会单独的介绍，需要消耗比较大的内存，官方推荐的配置如下：
```
18 GB of RAM
A 4 core CPU
Ubuntu 14.04, 16.04 or 18.0
```
spinnaker安装步骤
1、Halyard下载以及安装
2、选择云提供者：我选择的是Kubernetes Provider V2 (Manifest Based)，需要在部署spinnaker的机器上完成K8S集群的认证，以及权限管理。
3、部署的时候选择安装环境：我选择的是Debian包的方式。
4、选择存储：官方推荐使用minio，我选择的是minio的方式。
5、选择安装的版本：我当时最新的是V1.8.0
6、接下来进行部署工作，初次部署时间较长，会连接代理下载对应的包。
7、全部下载与完成后，查看对应的日志，即可使用localhost:9000访问即可。
完成以上的步骤则可以在kubernetes上面部署对应的应用了。
涉及的组件
下图是spinnaker的各个组件之间的关系。
下面介绍一下每个组件在spinnaker中作用
Deck：面向用户 UI 界面组件，提供直观简介的操作界面，可视化操作发布部署流程。
API： 面向调用 API 组件，我们可以不使用提供的 UI，直接调用 API 操作，由它后台帮我们执行发布等任务。
Gate：是 API 的网关组件，可以理解为代理，所有请求由其代理转发。
Rosco：是构建 beta 镜像的组件，需要配置 Packer 组件使用。
Orca：是核心流程引擎组件，用来管理流程。
Igor：是用来集成其他 CI 系统组件，如 Jenkins 等一个组件。
Echo：是通知系统组件，发送邮件等信息。
Front50：是存储管理组件，需要配置 Redis、Cassandra 等组件使用。
Cloud driver 是它用来适配不同的云平台的组件，比如 Kubernetes，Google、AWS EC2、Microsoft Azure 等。
Fiat 是鉴权的组件，配置权限管理，支持 OAuth、SAML、LDAP、GitHub teams、Azure groups、 Google Groups 等。
spinnaker在kubernetes的持续部署
一个优美的PIPELINE部署示例
如下pipeline设计就是开发将版本合到某一个分支后，通过jenkins镜像构建，发布测试环境，进而自动化以及人工验证，在由人工判断是否需要发布到线上以及回滚，若是选择发布到线上则发布到prod环境，从而进行prod自动化的CI。若是选择回滚则回滚到上个版本，从而进行dev自动化的CI。
我们针对如上的pipeline的每个stage进行分析：
Stage-configuration具有如下的配置
Automated Triggers
设置触发的方式，定义全局变量，执行报告的通知方式，是pipeline的起点
这里我们可以指定多种触发的方式：定时任务corn，git，jenkins，docker Registry，travis,pipeline,webhook等
Parameters
此处定义的全局变量会在整个PIPELINE中使用${ parameters[‘branch’]}得到,这样大大的简化了我们设计pipeline的通用性
Notifications
这里通知支持：SMS，EMAIL，HIPCHAT等等的方式。
运行完成后展示如下，我们可以查看相关的build的信息，以及此stage执行的相关信息，点击build可以跳到对应的jenkins的job查看相关的任务信息。
Stage-jenkins这个就很厉害了，完美的与jenkins结合，
调用jenkins来执行相关的任务，其中jenkins的服务信息存在放hal的配置文件中（如下展示），spinnaker可自动以同步jenkins的job以及参数等等的信息，运行后能够看到对应的JOB ID以及状态：
Stage-deploy
由于我们配置spinnaker的时候采用的是Kubernetes Provider V2方式，我们的发布均采用yaml的方式来实现，可以将文件存放在github中或者直接在页面上进行配置，同时yaml中文件支持了很多的参数化，这样大大的方便了我们日常的使用。
halyard关联KUBERNETES的配置信息
由于我们采用的云服务是KUBERNETES，配置的时候需要将部署spinnaker的机器对KUBERNETES集群做认证。
spinnaker发布信息展示：
此处Manifest Source支持参数化形式，类似于我们写入的yaml部署文件，但是这里支持参数化的方式。
Stage-Webhook
webhook我们可以做一些简单的环境验证以及去调用其他的服务的功能，它自身也提供了一些结果的验证功能，支持多种请求的方式。
Stage-Manual Judgment
用于人工的逻辑判断，增加pipeline的控制性(比如发布到线上需要测试人员认证以及领导审批)，内容支持多种语法表达的方式。
Stage-Check Preconditions
上边 Manual Judgment Stage 配置了两个 Judgment Inputs 判断项，接下来我们建两个 Check Preconditions Stage 来分别对这两种判断项做条件检测，条件检测成功，则执行对应的后续 Stage 流程。比如上面的操作，若是选择发布到prod，则执行发布到线上的分支，若是选择执行回滚的操作则进行回滚相关的分支。
如下图中我选择了rollback，则prod分支判断为失败，会阻塞后面的stage运行
Stage-Undo Rollout (Manifest)
若是我们发布发现出现问题，也可以设计回滚的stage，spinnaker的回滚极其的方便，在我们的日常部署中，每个版本都会存在对应的部署记录。回滚的pipeline描述中我们需要选择对应的deployment的回滚信息，以及回滚的版本数量。
运行结果的示例：
Stage-Canary Analysis
金丝雀部署方式：在我们发布新版本时引入部分流量到canary的服务中，kayenta会读取spinnaker中配置的prometheus中收集的指标，比如内存，CPU，接口超时时间，失败率等等通过kayenta中NetflixACAJudge来进行分析与判断，将分析的结果存于S3中，最终会给出这段时间的最终结果。
运行结果的设计与展示
1、我们需要对应用开启canary的配置。
2、创建出baseline与canary的deployment由同一个service指向这两个deployment。
3、我们这里采用读取prometheus的指标，需要在hal中增加prometheus配置。Metric可以直接匹配prometheus的指标。
每次分析的执行记录：
结果展示如下，由于我们设置的目标是75，所以pipeline的结果判定为失败。
线上容器服务的选择与多区容灾
我们是腾讯云的客户，采用腾讯云容器服务主要看重以下几个方面:
1、Kubernetes在自搭建的集群中，要实现Overlay网络，在腾讯云的环境里，它本身就是软件定义网络VPC，所以它在网络上的实现可以做到在容器环境里和原生的VM网络一样的快，没有任何的性能牺牲。
2、应用型负载均衡器和Kubernetes里的ingress相关联，对于需要外部访问的服务能够快速的创建。
3、腾讯云的云储存可以被Kubernetes管理，便于持久化的操作。
4、腾讯云的部署以及告警也对外提供了服务与接口，可以更好的查看与监控相关的node与pod的情况。
5、腾讯云日志服务很好的与容器进行融合，能够方便的收集与检索日志。
为了容灾我们使用了北京二区与北京三区两个集群，若是需要灰度验证时，则将线上北京三区的权重修改为0，这样通过灰度负载均衡器即可到达新版本应用。日常使用中二区与三区均同时提供挂服务。设计的思路以及模型如下：
Q: 运行结果的示例：
A: 所有应用总览：
pipeline执行结果展示
具体某个应用的展示：