本节介绍如何使用spinnaker的持续发布k8s的应用

1.首先使用spinnaker创建一个nginxdemo 的应用，再在nginxdemo应用里面创建 Pipeline。进入nginxdemo 详情页面，点击 “PIPELINES”，目前是没有任何信息的，点击 “+ Create”，弹框中选择类型为 Pipeline，输入流程名称，这里我命名为 nginxdemo-pipe。因为第一次创建，下边 “Copy From” 选择没出来，后续在创建时，我们也可以通过 “Copy From” 方式选择已存在的 Pipeline，非常方便就复制了一个一样配置的流程。创建完毕后，就会出现详细配置 Pipeline State 的页面了

2.配置 Configuration 项

刚开始这里只有一个 Configuration 选项，可以配置 Automated Triggers、Parameters、Notifications 等，这里说下 Automated Triggers 和 Parameters 这两个非常有用，我们可以将此视为 Pipeline 启动前的一些初始化配置，比如启动需要的参数配置、自动触发配置等，为后续各阶段提供必要的信息。
Automated Triggers 自动触发，它提供 7 种类型的触发方式：

• CRON：调度触发，可以执行一个 cron 调度任务来定时任务触发该流程。
• Git：当执行 Git push 操作时，触发该流程
• Jenkins：监听 Jenkins 的某一个 Job
• Travis：监听 Travis 的某一个 Job
• Pipeline：监听另一个 Pipeline 执行
• Pub/Sub：当接受到 pubsub 消息时触发
• Docker Registry：当 image 更新时触发。

基本能满足我们日常持续集成或交付的需求，当然每一个类型都需要配置相应的参数，比如 Cron 类型，需要配置执行频率、启动时间等。下图我们选择Docker Registry作为触发类型

流程图

流程说明:
1.用户向Gitlab提交代码，代码中包含Dockerfile
2.将代码提交到远程仓库
3.Gitlab提交触发Jenkins自动构建
4.Jenkins的CI流水线自动编译代码并打包成docker镜像推送到Harbor镜像仓库
5.更新Ingress的配置，根据新部署的应用的名称，在ingress的配置文件中增加一条路由信息(不是新业务不用更改此配置)
6.Jenkins构建完成可触发Spinnaker的自动发布流程，或者手动触发spinnaker发布。
7.Spinnaker会根据发布流程更新kubernetes YAML配置文件
8.Spinnaker调用kubernetes的API，部署应用

1.概念

Spinnaker 是 Netflix 的开源项目，是一个持续交付平台，它定位于将产品快速且持续的部署到多种云平台上。Spinnaker 通过将发布和各个云平台解耦，来将部署流程流水线化，从而降低平台迁移或多云品台部署应用的复杂度，它本身内部支持 Google、AWS EC2、Microsoft Azure、Kubernetes和OpenStack 等云平台，并且它可以无缝集成其他持续集成（CI）流程，如 git、Jenkins、Travis CI、Docker registry、cron 调度器等。简而言之，Spinnaker是致力于提供在多种平台上实现开箱即用的集群管理和部署功能的平台。

2.功能

2.1：集群管理主要用于管理云上的资源，它分为以下几个块

• Server Group：服务组，是资源管理单位，识别可部署组件和基础配置设置，它并且关联了一个负载均衡器和安全组，当部署完毕后，服务组就相当于一组运行中的软件实例集合，如（VM 实例，Kubernetes pods）。
• Cluster：集群，由用户定义的，对服务组的逻辑分组。
• Applications：应用，是对集群的逻辑分组。
• Load Balancer：负载均衡，用于将外部网络流量重定向到服务组中的机器实例，还可以指定一系列规则，用来对服务组中的机器实例做健康监测。
• Security Group：安全组，定义了网络访问权限，由IP、端口和通信协议组成的防火墙

2.2：部署管理功能用于创建一个持续交付流程，它可分为管道和阶段两大部分

• 管道 部署管理的核心是管道，在Spinnaker的定义中，管道由一系列的阶段（stages）组成。管道可以人工触发，也可以配置为自动触发，比如由 Jenkins Job 完成时、Docker Images 上传到仓库时，CRON 定时器、其他管道中的某一阶段。同时，管道可以配置参数和通知，可以在管道一些阶段上执行时发送邮件消息。Spinnaker 已经内置了一些阶段，如执行自定义脚本、触发 Jenkins 任务等。
• 阶段 阶段在 Spinnaker 中，可以作为管道的一个自动构建模块的功能组成。我们可以随意在管道中定义各个阶段执行顺序。Spinnaker 提供了很多阶段供我们选择使用，比如执行发布（Deploy）、执行自定义脚本 (script)、触发 Jenkins 任务 (jenkins)等，功能很强大。
• 部署策略 Spinnaker 支持精细的部署策略，比如 红/黑（蓝/绿）部署，多阶段环境部署，滚动红/黑策略，canary 发布等。用户可以为每个环境使用不同部署策略，比如，测试环境可以使用红/黑策略，生产环境使用滚动红/黑策略，它封装好了必须的步骤，用户不需要复杂操作，就可以实现企业级上线。

3.Spinnaker 架构所依赖的各个组件

升级步骤

前文：harbor1.9新功能众多，包括tag 保留和配额、可与 CI/CD 工具集成的 Webhook 通知、数据复制、Syslog 集成以及 CVE 例外策略等安全功能。harbor在1.8版本改变较大，因此需要分两步进行升级，升级到v1.8.0，再升级到v1.9.0。

准备工作：
1.下载harbor1.8.0和1.9.0版本的离线安装包

wget https://storage.googleapis.com/harbor-releases/release-1.8.0/harbor-offline-installer-v1.8.0.tgz

wget https://storage.googleapis.com/harbor-releases/release-1.9.0/harbor-offline-installer-v1.9.0.tgz

2.创建文件备份的目录

mkdir /data_backup1

mkdir /data_backup2

3.从docker hub拉取镜像

docker pull goharbor/harbor-migrator:v1.8.0

docker pull goharbor/harbor-migrator:v1.9.0

一、harbor1.7.5升级到1.8.0
1.关闭harbor

cd /usr/local/harbor

docker-compose down

2.数据备份

1.私有仓库版本

镜像仓库版本：

• Harbor v1.7.5
• Clair v2.0.7（漏洞库{+}https://github.com/coreos/clair+）

2.部署步骤

• 内网组件资源要事先准备好

2.1.安装docker 服务

yum -y install http://192.168.3.146/docker-ce-cli-18.09.0-3.el7.x86_64.rpm http://192.168.3.146/docker-ce-18.09.3-3.el7.x86_64.rpm http://192.168.3.146/containerd.io-1.2.4-3.1.el7.x86_64.rpm

2.2.安装docker-docker-compose

wget http://192.168.3.146/docker-compose

mv docker-compose /usr/local/bin/docker-compose && chmod 755 /usr/local/bin/docker-compose

2.3.部署harbor

cd /usr/local/src && wget http://192.168.3.146/harbor-offline-installer-v1.7.5.tgz && tar -zxvf harbor-offline-installer-v1.7.5.tgz && mv harbor /usr/local/

修改harbor 配置文件 /usr/local/harbor/harbor.cfg，一般修改hostname为harbor的访问域名，ui_url_protocol为访问协议，设置成http，harbor_admin_password 设置harbor的admin账号默认密码，其他邮箱，认证模式可以部署完系统之后在系统配置页面修改。

执行安装命令:cd /usr/local/harbor && sh install.sh –with-clair

harbor启动命令:docker-compose -f docker-compose.clair.yml -f docker-compose.yml start

2.4.配置复制管理(记得做主从复制harbor的机器仓库的域名都要指向主harbor那一台，要不做镜像复制同步就有问题)

3.总结

• 记得做主从复制harbor的机器仓库的域名都要指向主harbor那一台，要不做镜像复制同步就有问题

1.高可用集群概述

部署k8s的高可用集群，要做到无单电，主要是依靠负载均衡和k8s集群自身的高可用性。对于k8s的api，它本身是无状态的，自身不具备高可用，但是如果要它提供高可用的服务，做到其他节点和组件能无时无刻都可以访问它，需要在k8s api前面加一层tcp负载均衡器。一般k8s集群至少三个master节点，所以tcp转发层需要对这三台k8s api节点做负载均衡。这里有人可能问了，为什么需要tcp负载均衡，不做http负载均衡？原因就是k8s api的通信是https加密的，负载均衡器做https解析会比较麻烦，而且做tcp负载均衡效率也会高一些，也会比较方便，高版本的nginx就直接支持tcp转发。还有就是这三台master节点的服务器怎么放呢？这个要看个人的资源环境，比如你只是单机房的，那只能把master节点部署在一个机房里面了，然后三台服务器之间加个vip，使用keepalived做vip漂移，达到k8s api的高可用，如果你是同城三机房的，可以在每个机房部署一个master节点，然后每个机房部署一个高可用的负载均衡器，负载均衡器把请求转发到三个机房的k8s api上面去。然后对于etcd数据库，他本身自带高可用功能，部署三个以上节点的节点就好了，对于kube-scheduler组件，它们内部会自动选择一个leader节点，默认kubeadm安装情况下–leader-elect参数已经设置为true，保证master集群中只有一个kube-scheduler处于活跃状态，对于kube-controller-manager和kube-scheduler也是类似，默认kubeadm安装情况下–leader-elect参数已经设置为true，保证master集群中只有一个kube-controller-manager处于活跃状态。对于k8s核心组件的功能，下面再说明一下：

kube-apiserver：集群核心,集群API接口、集群各个组件通信的中枢；集群安全控制。

etcd：集群的数据中心，用于存放集群的配置以及状态信息，非常重要，如果数据丢失那么集群将无法恢复；因此高可用集群部署首先就是etcd是高可用集群；

kube-scheduler：集群Pod的调度中心；默认kubeadm安装情况下–leader-elect参数已经设置为true，保证master集群中只有一个kube-scheduler处于活跃状态；

kube-controller-manager：集群状态管理器，当集群状态与期望不同时，kcm会努力让集群恢复期望状态，比如：当一个pod死掉，kcm会努力新建一个pod来恢复对应replicas set期望的状态；默认kubeadm安装情况下–leader-elect参数已经设置为true，保证master集群中只有一个kube-controller-manager处于活跃状态；

kubelet：kubernetes node agent，负责与node上的docker engine打交道；

kube-proxy：每个node上一个，负责service vip到endpoint pod的流量转发，当前主要通过设置iptables规则实现。

2.k8s高可用架构图

这里单机房和多机房的区别就在于单机房整个机房就一个vip，多机房就是每个机房都有一个vip，每个机房都有一个api访问入口。

一、API对象资源

API对象是K8s集群中的管理操作单元。K8s集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作。例如副本集Replica Set对应的API对象是RS。

每个API对象都有3大类属性：元数据metadata、规范spec和状态status。元数据是用来标识API对象的，每个对象都至少有3个元数据：namespace，name和uid；除此以外还有各种各样的标签labels用来标识和匹配不同的对象，例如用户可以用标签env来标识区分不同的服务部署环境，分别用env=dev、env=testing、env=production来标识开发、测试、生产的不同服务。规范描述了用户期望K8s集群中的分布式系统达到的理想状态（Desired State），例如用户可以通过复制控制器Replication Controller设置期望的Pod副本数为3；status描述了系统实际当前达到的状态（Status），例如系统当前实际的Pod副本数为2；那么复本控制器当前的程序逻辑就是自动启动新的Pod，争取达到副本数为3。

K8s中所有的配置都是通过API对象的spec去设置的，也就是用户通过配置系统的理想状态来改变系统，这是k8s重要设计理念之一，即所有的操作都是声明式（Declarative）的而不是命令式（Imperative）的。声明式操作在分布式系统中的好处是稳定，不怕丢操作或运行多次，例如设置副本数为3的操作运行多次也还是一个结果，而给副本数加1的操作就不是声明式的，运行多次结果就错了。

1.Pod

K8s有很多技术概念，同时对应很多API对象，最重要的也是最基础的是微服务Pod。Pod是在K8s集群中运行部署应用或服务的最小单元，它是可以支持多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。Pod对多容器的支持是K8s最基础的设计理念。比如你运行一个操作系统发行版的软件仓库，一个Nginx容器用来发布软件，另一个容器专门用来从源仓库做同步，这两个容器的镜像不太可能是一个团队开发的，但是他们一块儿工作才能提供一个微服务；这种情况下，不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务。

Pod是K8s集群中所有业务类型的基础，可以看作运行在K8s集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。目前K8s中的业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、DaemonSet和StatefulSet，本文后面会一一介绍。

2.复制控制器（Replication Controller，RC）

RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动运行新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可以发挥它高可用的能力，保证永远有1个Pod在运行。RC是K8s较早期的技术概念，只适用于长期伺服型的业务类型，比如控制小机器人提供高可用的Web服务。

1.核心组件

1.1 etcd 保存了整个集群的状态,etcd是Kubernetes提供默认的存储系统，保存所有集群数据，使用时需要为etcd数据提供备份计划

1.2 kube-apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制

1.3 kube-controller-manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等,kube-controller-manager运行管理控制器，它们是集群中处理常规任务的后台线程。逻辑上，每个控制器是一个单独的进程，但为了降低复杂性，它们都被编译成单个二进制文件，并在单个进程中运行.这些控制器包括：

• 节点（Node）控制器
• 副本（Replication）控制器：负责维护系统中每个副本中的pod
• 端点（Endpoints）控制器：填充Endpoints对象（即连接Services＆Pods）
• Service Account和Token控制器：为新的Namespace 创建默认帐户访问API Token

1.4 kube-scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上

1.5 kubelet 负责维持容器的生命周期，同时也负责 Volume（CVI）和网络（CNI）的管理

1.6 Container runtime 负责镜像管理以及 Pod 和容器的真正运行（CRI），默认的容器运行时为 Docker.

1.7 kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡.

1.8 docker服务，用于运行容器.

1.API设计原则

对于云计算系统，系统API实际上处于系统设计的统领地位。Kubernetes集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作。理解掌握的API，就好比抓住了K8s系统的牛鼻子。Kubernetes系统API的设计有以下几条原则：

• 所有API应该是声明式的。声明式的操作，相对于命令式操作，对于重复操作的效果是稳定的，这对于容易出现数据丢失或重复的分布式环境来说是很重要的。另外，声明式操作更容易被用户使用，可以使系统向用户隐藏实现的细节，同时也保留了系统未来持续优化的可能性。此外，声明式的API还隐含了所有的API对象都是名词性质的，例如Service、Volume这些API都是名词，这些名词描述了用户所期望得到的一个目标对象。
• API对象是彼此互补而且可组合的。这实际上鼓励API对象尽量实现面向对象设计时的要求，即“高内聚，松耦合”，对业务相关的概念有一个合适的分解，提高分解出来的对象的可重用性。
• 高层API以操作意图为基础设计。如何能够设计好API，跟如何能用面向对象的方法设计好应用系统有相通的地方，高层设计一定是从业务出发，而不是过早的从技术实现出发。因此，针对Kubernetes的高层API设计，一定是以K8s的业务为基础出发，也就是以系统调度管理容器的操作意图为基础设计。
• 低层API根据高层API的控制需要设计。设计实现低层API的目的，是为了被高层API使用，考虑减少冗余、提高重用性的目的，低层API的设计也要以需求为基础，要尽量抵抗受技术实现影响的诱惑。
• 尽量避免简单封装，不要有在外部API无法显式知道的内部隐藏的机制。简单的封装，实际没有提供新的功能，反而增加了对所封装API的依赖性。内部隐藏的机制也是非常不利于系统维护的设计方式，例如StatefulSet和ReplicaSet，本来就是两种Pod集合，那么Kubernetes就用不同API对象来定义它们，而不会说只用同一个ReplicaSet，内部通过特殊的算法再来区分这个ReplicaSet是有状态的还是无状态。
• API操作复杂度与对象数量成正比。这一条主要是从系统性能角度考虑，要保证整个系统随着系统规模的扩大，性能不会迅速变慢到无法使用，那么最低的限定就是API的操作复杂度不能超过O(N)，N是对象的数量，否则系统就不具备水平伸缩性了。
• API对象状态不能依赖于网络连接状态。由于众所周知，在分布式环境下，网络连接断开是经常发生的事情，因此要保证API对象状态能应对网络的不稳定，API对象的状态就不能依赖于网络连接状态。
  尽量避免让操作机制依赖于全局状态，因为在分布式系统中要保证全局状态的同步是非常困难的。

1.概念

Kubernetes是一个容器编排系统，也就是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。Kubernetes 最初源于谷歌内部的 Borg，提供了面向应用的容器集群部署和管理系统。Kubernetes 的目标旨在消除编排物理 / 虚拟计算，网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。Kubernetes 也提供稳定、兼容的基础（平台），用于构建定制化的 workflows 和更高级的自动化任务。 Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。 Kubernetes 还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。

2.特点

• 可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）

• 可扩展: 模块化, 插件化, 可挂载, 可组合

• 自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展

3.Kubernetes 架构