应用程序升级面临最大挑战是新旧业务切换，将软件从测试的最后阶段带到生产环境，同时要保证系统不间断提供服务。长期以来，业务升级渐渐形成了几个发布策略：蓝绿发布、金丝雀发布和滚动发布等灰度发布策略，目的是尽可能避免因发布导致的流量丢失或服务不可用问题。
蓝绿发布
项目逻辑上分为AB组，在项目系统时，首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。当A组升级完毕，负载均衡重新接入A组，再把B组从负载列表中摘除，进行新版本的部署。A组重新提供服务。
在k8s中也是经常使用的蓝绿发布，应用版本 1 与版本 2 的后端 pod 都部署在环境中，通过控制流量切换来决定发布哪个版本。与滚动发布相比，蓝绿发布策略下的应用终态，是可以同时存在版本 1 和版本 2 两种 pod 的，我们可以通过 service 流量的切换来决定当前服务使用哪个版本的后端。
特点
- 基础设施无改动，增大升级稳定性。
- 发布策略简单；
- 用户无感知，平滑过渡；
- 升级/回滚速度快。
缺点
- 如果出问题，影响范围较大；
- 需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发；
- 短时间内浪费一定资源成本；
蓝绿发布在早期物理服务器时代，还是比较昂贵的，由于云计算普及，成本也大大降低。使得蓝绿发布变的更加适合使用
实例
1、通过go-demo-v1.yaml，go-demo-v2.yaml，service.yaml部署应用
go-demo-v1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo-v1
spec:
replicas: 4
selector:
matchLabels:
app: go-demo
version: v1
template:
metadata:
labels:
app: go-demo
version: v1
spec:
containers:
- name: go-demo
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
imagePullPolicy: Always
ports:
- containerPort: 8080
go-demo-v2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo-v2
spec:
replicas: 4
selector:
matchLabels:
app: go-demo
version: v2
template:
metadata:
labels:
app: go-demo
version: v2
spec:
containers:
- name: go-demo
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
imagePullPolicy: Always
ports:
- containerPort: 8080
service.yaml
apiVersion: v1
kind: Service
metadata:
name: go-demo
spec:
ports:
- port: 80
targetPort: 8080
name: go-demo
selector:
app: go-demo
version: v1
type: ClusterIP
2、部署以上 3 个资源
$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service.yaml
3、访问服务可以看到目前只访问到版本 1 的服务
$ while sleep 0.1; do curl http://172.19.8.137; done
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
4、修改 service.yaml 的 spec.selector 下 version=v2
apiVersion: v1
kind: Service
metadata:
name: go-demo
spec:
ports:
- port: 80
targetPort: 8080
name: go-demo
selector:
app: go-demo
version: v2
type: ClusterIP
5、重新部署
$ kubectl apply -f service.yaml
6、重新访问服务可以看到很快切换到了版本 2 上
$ [root@iZbp13u3z7d2tqx0cs6ovqZ blue-green]# while sleep 0.1; do curl http://172.19.8.137; done
Version: v2
Version: v2
Version: v2
我们刚才说到滚动升级有一个过程需要时间，即使回滚，它也需要一定的时间才能回滚完毕，在新版本应用有缺陷的情况下，蓝绿发布的策略可以快速在 v1 和 v2 两个版本之前切流量，所以这个切换流量的时间跟滚动升级相比就缩短了很多了，但蓝绿发布的缺点跟滚动发布相同的就是这个缺陷会影响到整体用户，服务要么百分百切换到版本 2 上，要么百分百切换到版本 1 上，这是个非 0 即 100 的操作，即使蓝绿发布策略可以大大缩短故障恢复时间，但在某些场景下也是不可接受的。 而且集群环境中同时存在两个版本的 pod 副本，资源占用的话相比滚动发布是 2 倍的。
金丝雀发布
金丝雀发布只升级部分服务，即让一部分用户继续用老版本，一部分用户开始用新版本，如果用户对新版本没什么意见，那么逐步扩大范围，把所有用户都迁移到新版本上面来。
金丝雀部署是应用版本 1 和版本 2 同时部署在环境中，并且用户请求有可能会路由到版本 1 的后端，也可能会路由到版本 2 的后端，从而达到让一部分新用户访问到版本 2 的应用。 这种发布策略下，我们可以通过调整流量百分比来逐步控制应用向新的版本切换，它与蓝绿部署相比，不仅继承了蓝绿部署的优点，而且占用资源优于蓝绿部署所需要的 2 倍资源，在新版本有缺陷的情况下只影响少部分用户，把损失降到最低。
特点
- 保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控；
- 新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小，相对用户体验也少；
- 用户无感知，平滑过渡。
- 继承了蓝绿部署的优点，而且占用资源优于蓝绿部署所需要的 2 倍资源
缺点
- 发布周期相对来说要慢很多
- 自动化要求高
实例
通过 pod 的数量来控制流量比例。
1、go-demo-v1.yaml 设定副本数为 9
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo-v1
spec:
replicas: 9
selector:
matchLabels:
app: go-demo
version: v1
template:
metadata:
labels:
app: go-demo
version: v1
spec:
containers:
- name: go-demo
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
imagePullPolicy: Always
ports:
- containerPort: 8080
2、go-demo-v2.yaml 设定副本数为 1
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo-v2
spec:
replicas: 1
selector:
matchLabels:
app: go-demo
version: v2
template:
metadata:
labels:
app: go-demo
version: v2
spec:
containers:
- name: go-demo
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
imagePullPolicy: Always
ports:
- containerPort: 8080
3、通过service.yaml启动服务
apiVersion: v1
kind: Service
metadata:
name: go-demo
spec:
ports:
- port: 80
targetPort: 8080
name: go-demo
selector:
app: go-demo
type: ClusterIP
4、部署以上 3 个资源
$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service.yaml
5、访问服务可以看到基本上是 10% 的流量切换到版本 2 上
$ while sleep 0.1; do curl http://172.19.8.248; done
Version: v1
Version: v2
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
使用 nginx ingress controller 来控制流量切换，这个方式要更精准。
1、go-demo-v1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo-v1
spec:
replicas: 3
selector:
matchLabels:
app: go-demo
version: v1
template:
metadata:
labels:
app: go-demo
version: v1
spec:
containers:
- name: go-demo
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
imagePullPolicy: Always
ports:
- containerPort: 8080
2、go-demo-v2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo-v2
spec:
replicas: 1
selector:
matchLabels:
app: go-demo
version: v2
template:
metadata:
labels:
app: go-demo
version: v2
spec:
containers:
- name: go-demo
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
imagePullPolicy: Always
ports:
- containerPort: 8080
3、service-v1.yaml
apiVersion: v1
kind: Service
metadata:
name: go-demo-v1
spec:
ports:
- port: 80
targetPort: 8080
name: go-demo
selector:
app: go-demo
version: v1
type: ClusterIP
4、service-v2.yaml
apiVersion: v1
kind: Service
metadata:
name: go-demo-v2
spec:
ports:
- port: 80
targetPort: 8080
name: go-demo
selector:
app: go-demo
version: v2
type: ClusterIP
5、ingress.yaml， 设置 nginx.ingress.kubernetes.io/service-weight: | go-demo-v1: 100, go-demo-v2: 0， 版本1 - 100% 流量， 版本2 - 0% 流量
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/service-weight: |
go-demo-v1: 100, go-demo-v2: 0
name: go-demo
labels:
app: go-demo
spec:
rules:
- host: go-demo.example.com
http:
paths:
- path: /
backend:
serviceName: go-demo-v1
servicePort: 80
- path: /
backend:
serviceName: go-demo-v2
servicePort: 80
6、部署以上 4 个资源
$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service-v1.yaml -f service-v2.yaml -f nginx.yaml
7、访问服务可以看到流量 100% 到版本 1 上
$ while sleep 0.1; do curl http://go-demo.example.com; done
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
8、更新 ingress.yaml， 设置流量比为 50:50
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/service-weight: |
go-demo-v1: 50, go-demo-v2: 50
name: go-demo
labels:
app: go-demo
spec:
rules:
- host: go-demo.example.com
http:
paths:
- path: /
backend:
serviceName: go-demo-v1
servicePort: 80
- path: /
backend:
serviceName: go-demo-v2
servicePort: 80
9、访问服务可以看到流量 50% 到版本 1 上， 50% 到版本 2 上
$ while sleep 0.1; do curl http://go-demo.example.com; done
Version: v2
Version: v1
Version: v1
Version: v1
Version: v2
Version: v2
Version: v1
Version: v1
Version: v2
Version: v2
这种比滚动升级更加容易控制，也是使用比较多的方式。
滚动发布
滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。
特点
- 比较简单，用户无感知，平滑过渡
缺点
- 部署时间慢，取决于每阶段更新时间；
- 发布策略较复杂，不易回滚
- 无法控制
实例
1、通过go-demo-v1.yaml部署应用
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-demo
spec:
replicas: 3
selector:
matchLabels:
app: go-demo
template:
metadata:
labels:
app: go-demo
spec:
containers:
- name: go-demo
image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
imagePullPolicy: Always
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: go-demo
spec:
ports:
- port: 80
targetPort: 8080
name: go-demo
selector:
app: go-demo
type: ClusterIP
2、部署版本v1
$ kubectl apply -f go-demo-v1.yaml
3、查看 pod 运行状态
$ kubectl get po
NAME READY STATUS RESTARTS AGE
go-demo-78bc65c564-2rhxp 1/1 Running 0 19s
go-demo-78bc65c564-574z6 1/1 Running 0 19s
go-demo-78bc65c564-sgl2s 1/1 Running 0 19s
4、访问应用服务
$ while sleep 0.1; do curl http://172.19.15.25; done
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
5、更新 go-demo-v1.yaml 为 go-demo-v2.yaml 并更新镜像 tag
...
registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
...
6、部署版本 v2
$ kubectl apply -f go-demo-v2.yaml
7、可以查看 pod 会被新版本 pod 逐个替换
$kubectl get po -w
NAME READY STATUS RESTARTS AGE
application-demo-8594ff4967-85jsg 1/1 Running 0 3m24s
application-demo-8594ff4967-d4sv8 1/1 Terminating 0 3m22s
application-demo-8594ff4967-w6lpz 0/1 Terminating 0 3m20s
application-demo-b98d94554-4mwqd 1/1 Running 0 3s
application-demo-b98d94554-ng9wx 0/1 ContainerCreating 0 1s
application-demo-b98d94554-pmc5g 1/1 Running 0 4s
8、访问服务会发现在应用滚动升级过程中，版本 v1 和 v2 都会被访问到，这个时间的长短取决于应用的启动速度
$ while sleep 0.1; do curl http://172.19.15.25; done
Version: v1
Version: v2
Version: v1
Version: v1
Version: v2
Version: v1
Version: v1
Version: v2
可见k8s默认使用的就是滚动升级的方式，直接使用apply就行，但是这种方式不可控，不能定制化，所以很多发布场景需要开发对应的控制器，比如阿里的kurise项目。
小结
综上所述，三种方式均可以做到平滑式升级，在升级过程中服务仍然保持服务的连续性，升级对外界是无感知的。那生产上选择哪种部署方法最合适呢？这取决于哪种方法最适合你的业务和技术需求。如果你们运维自动化能力储备不够，肯定是越简单越好，建议蓝绿发布，如果业务对用户依赖很强，建议灰度发布。如果是K8S平台，滚动更新是现成的方案，建议先直接使用。
蓝绿发布：两套环境交替升级，旧版本保留一定时间便于回滚。
灰度发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本。
滚动发布：按批次停止老版本实例，启动新版本实例。