在项目迭代的过程中，不可避免需要上线进行部署。
目前项目部署的方式有很多种：像重新部署，蓝绿部署，金丝雀部署(灰度部署)，滚动更新。本文简单介绍下这些常见的部署方案以及使用k8s怎么进行对应部署
重新部署
定义:先停止旧服务，然后启动新服务，这是最简单的一种部署方式
缺点:在整个过程中会出现一段时间的服务不可用
先准备两个自己的镜像，访问接口为/dockerfile,返回的数据不一样:
-/chenpp/springboot-image:v2.0 返回hello,docker
-/chenpp/springboot-image:v3.0 返回hello,k8s <br/>
详细步骤参考这篇docker学习笔记(二)创建自己的镜像
#recreate.yamlapiVersion: apps/v1kind: Deploymentmetadata:name: recreatespec:strategy:type: Recreateselector:matchLabels:app: recreatereplicas: 4template:metadata:labels:app: recreatespec:containers:- name: recreateimage: -/chenpp/springboot-image:v2.0ports:- containerPort: 8080livenessProbe:tcpSocket:port: 8080
修改yaml里的镜像版本为v3.0，再次执行apply -f
通过对pod状态的持续观察可以发现k8s是先停止旧的，然后再创建新的pod
蓝绿部署
定义:蓝绿部署就是不停止旧版本，直接部署新版本然后进行测试，测试验证OK后，将流量全部切换到新版本，同时将旧版本也升级到新版本(或者可以将旧版本直接停掉)
优点: 无需停机，风险较小
缺点: 切换是全量的，如果版本2有问题，则对用户体验有直接影响,需要双倍机器资源。
部署过程：
部署v1的应用（初始状态）所有外部请求的流量都会打到这个版本上部署版本2的应用版本2的代码与版本1不同如果版本2测试正常，就可以将流量切换到版本2稳定运行一段时间，没问题就删除版本1正在使用的资源（例如实例），从此正式使用版本2
#bluegreem.yamlapiVersion: apps/v1kind: Deploymentmetadata:name: bluespec:strategy:rollingUpdate:maxSurge: 25%maxUnavailable: 25%type: RollingUpdateselector:matchLabels:app: bluegreenreplicas: 4template:metadata:labels:app: bluegreenversion: v2.0spec:containers:- name: bluegreenimage: -/chenpp/springboot-image:v2.0ports:- containerPort: 8080
apiVersion: v1kind: Servicemetadata:name: bluegreenspec:ports:- port: 80protocol: TCPtargetPort: 8080selector:app: bluegreenversion: v2.0type: ClusterIP
修改bluegreen.yaml
deployment-name: blue ---> green
image: v2.0---> v3.0
version: v2.0 ---> v3.0
查看Pod可以发现两个一开始green,blue 两种pod共存(一共有八个pod)，访问之前的ClusterIP地址，返回结果没有变化
修改service的内容(把流量切到3.0的版本中)
version: v2.0 ---> v3.0
访问之前的地址发现流量已经完全切到了v3.0的版本上
金丝雀部署(灰度部署)
定义 :灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。
AB Test就是一种灰度发布方式，让部分用户继续使用A版本，一部分用户开始用B版本，如果用户对新版本没有什么意见反馈，那么逐步扩大范围，把所有用户都迁移到新版本上面来(A/B Test主要是用来测试应用功能表现,例如可用性、受欢迎程度、可见性等)。
灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，而我们平常所说的金丝雀部署就是灰度发布的一种方式。
部署过程:
准备好部署各个阶段的工件从负载均衡列表中移除掉“金丝雀”服务器。升级“金丝雀”应用（排掉原有流量并进行部署）。对应用进行自动化测试。将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
优点: 用户体验影响小，灰度发布过程出现问题只影响部分用户。
具体步骤跟上述差不多，只不过上面的service在切换的时候直接根据版本来切换，所以流量会全部切换过去，想要实现灰度部署的结果只需要把service的selector里的version标签去掉就好(两个版本的app标签都是一样的，镜像不一样，但是不影响service筛选需要负载的pod)
可以按照各自版本的设置不同的replicas，流量会按照比例进行分配
持续访问service,可以看到请求被分发到不同的版本(如果不想增加pod数量，可以修改下每个版本pod的replicas数目)
滚动更新
定义:一般是取出一个或者多个服务器停止服务，更新版本后重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。
这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的25%进行升级。
apiVersion: apps/v1kind: Deploymentmetadata:name: rollingupdatespec:strategy:rollingUpdate:maxSurge: 25% #滚动升级时先启动的pod数量maxUnavailable: 25% #滚动升级时允许的最大unavailable的pod数量type: RollingUpdateselector:matchLabels:app: rollingupdatereplicas: 4template:metadata:labels:app: rollingupdatespec:containers:- name: rollingupdateimage: -/chenpp/springboot-image:v2.0ports:- containerPort: 8080 ---apiVersion: v1kind: Servicemetadata:name: rollingupdatespec:ports:- port: 80protocol: TCPtargetPort: 8080selector:app: rollingupdatetype: ClusterIP
在worder1上，不断地访问观察输出结果
while sleep 0.2;do curl 10.102.115.66/dockerfile;echo "";done
在master上，监控podkubectl get pods -w
修改yaml中image的版本为v3.0,滚动更新
整个部署过程中Service不会停止，但是会有新旧pod并存的情况。
参考文章:/t/344341
