常见的部署方案：
- 滚动更新：服务不会停止，但是整个pod会有新旧并存的情况。
- 重新创建：先停止旧的pod，然后再创建新的pod，这个过程服务是会间断的。
- 蓝绿部署：无需停机，风险较小。部署v1的应用（一开始的状态）所有外部请求的流量都打到这个版本上。部署版本2的应用版本2的代码与版本1不同(新功能、Bug修复等)。将流量从版本1切换到版本2。如版本2测试正常，就删除版本1正在使用的资源（例如实例），从此正式用版本2。
- 金丝雀部署：金丝雀发布一般先发 1 台，或者一个小比例，例如 2% 的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试（国内常称灰度测试）。以前旷工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试 需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。如果金丝测试通过，则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。
滚动更新：
创建 rollingupdate.yaml 文件：
maxUnavailable：最大无效pod数。
maxSurge：最大激增pod数。
apiVersion: apps/v1
kind: Deployment
metadata:
name: rollingupdate
spec:
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
selector:
matchLabels:
app: rollingupdate
replicas: 4
template:
metadata:
labels:
app: rollingupdate
spec:
containers:
- name: rollingupdate
image: registry.cn-hangzhou.aliyuncs.com/wuzz-docker/test-docker-image:v1.0
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: rollingupdate
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8080
selector:
app: rollingupdate
type: ClusterIP
kubectl apply -f rollingupdate.yaml
kubectl get pods
kubectl get svc
curl svc r-ip/dockerfile
修改rollingupdate.yaml文件，将镜像修改成v2.0
# 在w1上，不断地访问观察输出 while sleep 0.2;do curl cluster-ip/dockerfile;echo "";done # 在w2上，监控pod kubectl get pods -w # 使得更改生效 kubectl apply -f rollingupdate.yaml kubectl get pods
发现新旧pod是会共存的，并且可以访问测试看一下
重新创建：
创建 recreate.yaml 文件
apiVersion: apps/v1
kind: Deployment
metadata:
name: recreate
spec:
strategy:
type: Recreate
selector:
matchLabels:
app: recreate
replicas: 4
template:
metadata:
labels:
app: recreate
spec:
containers:
- name: recreate
image: registry.cn-hangzhou.aliyuncs.com/wuzz-docker/test-docker-image:v1.0
ports:
- containerPort: 8080
livenessProbe:
tcpSocket:
port: 8080
kubectl apply -f recreate.yaml
kubectl get pods
修改recreate.yaml文件 改成 v2.0,执行kubectl apply -f recreate.yaml使其生效。同时在w2上进行观察 kubectl get pods -w 。发现pod是先停止，然后再创建新的
Have a try
kubectl rollout pause deploy/deploy-name #暂停资源 kubectl rollout resume deploy/rollingupdate #回复暂停资源 kubectl rollout undo deploy/rollingupdate --to-revision=2 # 回到上一个版本
蓝绿部署：
创建 bluegreen.yaml ：
#deploy
apiVersion: apps/v1
kind: Deployment
metadata:
name: blue
spec:
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
selector:
matchLabels:
app: bluegreen
replicas: 4
template:
metadata:
labels:
app: bluegreen
version: v1.0
spec:
containers:
- name: bluegreen
image: registry.cn-hangzhou.aliyuncs.com/wuzz-docker/test-docker-image:v1.0
ports:
- containerPort: 8080
kubectl apply -f bluegreen.yaml
kubectl get pods
创建 bluegreen-service.yaml ：
apiVersion: v1
kind: Service
metadata:
name: bluegreen
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8080
selector:
app: bluegreen
version: v1.0
type: ClusterIP
kubectl apply -f bluegreen-service.yaml
kubectl get svc
在w1上不断访问观察 while sleep 0.3;do curl cluster-ip/dockerfile;echo "";done
修改bluegreen.yaml
01-deployment-name:blue ---> green 02-image:v1.0---> v2.0 03-version:v1.0 ---> v2.0
kubectl apply -f bluegreen.yaml
kubectl get pods
同时观察刚才访问的地址有没有变化，可以发现，两个版本就共存了，并且之前访问的地址没有变化
修改bluegreen-service.yaml ：
# 也就是把流量切到2.0的版本中 selector: app: bluegreen version: v2.0
kubectl apply -f bluegreen-service.yaml
kubectl get svc
同时观察刚才访问的地址有没有变化。发现流量已经完全切到了v2.0的版本上
金丝雀部署/灰度发布/AB测试：
修改上述 bluegreen-service.yaml
selector: app: bluegreen version: v2.0 # 把version删除掉，只是根据bluegreen进行选择
kubectl apply -f bluegreen-service.yaml
同时观察刚才访问的地址有没有变化，此时新旧版本能够同时被访问到，AB测试，新功能部署少一些的实例.