百度网盘链接：https://pan.baidu.com/s/15t_TSH5RRpCFXV-93JHpNw?pwd=8od3 提取码：8od3
10 Deployment控制器
Deployment官方文档：https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
10.1 Deployment概述
Deployment是kubernetes中最常用的资源对象，为ReplicaSet和Pod的创建提供了一种声明式的定义方法，在Deployment对象中描述一个期望的状态，Deployment控制器就会按照一定的控制速率把实际状态改成期望状态，通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器，通过ReplicaSet创建pod，删除Deployment控制器，也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源。
使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性，例如滚动升级、金丝雀发布、蓝绿部署和回滚。
扩展：声明式定义是指直接修改资源清单文件，然后通过kubectl apply -f资源清单yaml文件，就可以更改资源。
Deployment控制器是建立在rs之上的一个控制器，可以管理多个rs，每次更新镜像版本，都会生成一个新的rs，把旧的rs替换掉，多个rs同时存在，但是只有一个rs运行。
rs v1控制三个pod，删除一个pod，在rs v2上重新建立一个，依次类推，直到全部都是由rs v2控制，如果rs v2有问题，还可以回滚，Deployment是建构在rs之上的，多个rs组成一个Deployment，但是只有一个rs处于活跃状态。
10.2 Deployment工作原理
Deployment可以使用声明式定义，直接在命令行通过纯命令的方式完成对应资源版本的内容的修改，也就是通过打补丁的方式进行修改；Deployment能提供滚动式自定义自控制的更新；对Deployment来讲，我们在实现更新时还可以实现控制更新节奏和更新逻辑。
什么叫做更新节奏和更新逻辑呢？
比如说Deployment控制5个pod副本，pod的期望值是5个，但是升级的时候需要额外多几个pod，那我们控制器可以控制在5个pod副本之外还能再增加几个pod副本；比方说能多一个，但是不能少，那么升级的时候就是先增加一个，再删除一个，增加一个删除一个，始终保持pod副本数是5个；还有一种情况，最多允许多一个，最少允许少一个，也就是最多6个，最少4个，第一次加一个，删除两个，第二次加两个，删除两个，依次类推，可以自己控制更新方式，这种滚动更新需要加readinessProbe和livenessProbe探测，确保pod中容器里的应用都正常启动了才删除之前的pod。
启动第一步，刚更新第一批就暂停了也可以；假如目标是5个，允许一个也不能少，允许最多可以10个，那一次加5个即可；这就是我们可以自己控制节奏来控制更新的方法
通过Deployment对象，你可以轻松的做到以下事情：
1.创建ReplicaSet和Pod
2.滚动升级（不停止旧服务的状态下升级）和回滚应用（将应用回滚到之前的版本）
3.平滑地扩容和缩容
4.暂停和继续Deployment
10.3 Deployment资源清单文件编写技巧
[root@master1 ~]# kubectl explain deployment //查看Deployment资源对象由哪几部分组成
KIND: Deployment
VERSION: apps/v1
FIELDS:
apiVersion <string> #该资源使用的api版本
kind <string> #创建的资源是什么？
metadata <Object> #元数据，包括资源的名字和名称空间
spec <Object> #定义容器的
status <Object> #状态，不可以修改
[root@master1 ~]# kubectl explain deployment.spec //查看Deployment下的spec字段
KIND: Deployment
VERSION: apps/v1
RESOURCE: spec <Object>
FIELDS:
minReadySeconds <integer> #Kubernetes在等待设置的时间后才进行升级，如果没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了
paused <boolean> #暂停，当我们更新的时候创建pod先暂停，不是立即更新
progressDeadlineSeconds <integer> #k8s 在升级过程中有可能由于各种原因升级卡住（这个时候还没有明确的升级失败），比如在拉取被墙的镜像，权限不够等错误。那么这个时候就需要有个 deadline ，在 deadline 之内如果还卡着，那么就上报这个情况，这个时候这个 Deployment 状态就被标记为 False，并且注明原因。但是它并不会阻止 Deployment 继续进行卡住后面的操作。完全由用户进行控制。
replicas <integer> #副本数
revisionHistoryLimit <integer> #保留的历史版本，默认是10
selector <Object> -required- #标签选择器，选择它关联的pod
strategy <Object> #更新策略
template <Object> -required #定义的pod模板
[root@master1 ~]# kubectl explain deploy.spec.strategy //查看Deployment下的spec.strategy字段
KIND: Deployment
VERSION: apps/v1
RESOURCE: strategy <Object>
FIELDS:
rollingUpdate <Object>
type <string>
Type of deployment. Can be "Recreate" or "RollingUpdate". Default is RollingUpdate.
#支持两种更新，Recreate和RollingUpdate，Recreate是重建式更新，删除一个更新一个
#RollingUpdate滚动更新，定义滚动更新方式，也就是pod能多几个，少几个
[root@master1 ~]# kubectl explain deploy.spec.strategy.rollingUpdate //查看Deployment下的spec.strategy.rollingUpdate字段
KIND: Deployment
VERSION: apps/v1
RESOURCE: rollingUpdate <Object>
FIELDS:
maxSurge <string> #我们更新的过程当中最多允许超出的指定的目标副本数有几个；它有两种取值方式，第一种直接给定数量，第二种根据百分比，百分比表示原本是5个，最多可以超出20%，那就允许多一个，最多可以超过40%，那就允许多两个。
maxUnavailable <string> #最多允许几个不可用，假设有5个副本，最多一个不可用，就表示最少有4个可用
replicas： 5
maxSurge: 25% 5*25%=1.25 ->5+2=7
maxUnavailable: 25% 5%25%=1.25 -> 5-1=4
[root@master1 ~]# kubectl explain deploy.spec.template //查看Deployment下的spec.template字段
KIND: Deployment
VERSION: apps/v1
RESOURCE: template <Object>
FIELDS:
metadata <Object> #定义模板的名字
spec <Object> #deployment.spec.template为Pod定义的模板，和Pod定义不太一样，template中不包含apiVersion和Kind属性，要求必须有metadata。deployment.spec.template.spec为容器的属性信息，其他定义内容和Pod一致。
10.4 Deployment使用案例
10.4.1 创建一个web站点
deployment是一个三级结构，deployment管理replicaset，replicaset管理pod。
把myapp-blue-v1.tar.gz和myapp-blue-v2.tar.gz上传到node1和node2上，手动解压：
[root@node1 ~]# ctr -n=k8s.io images import myapp-blue-v1.tar.gz
[root@node2 ~]# ctr -n=k8s.io images import myapp-blue-v1.tar.gz
[root@node1 ~]# ctr -n=k8s.io images import myapp-blue-v2.tar.gz
[root@node2 ~]# ctr -n=k8s.io images import myapp-blue-v2.tar.gz
[root@master1 ~]# vim deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-v1
spec:
replicas: 2
selector:
matchLabels:
app: myapp
version: v1
template:
metadata:
labels:
app: myapp
version: v1
spec:
containers:
- name: myapp
image: janakiramm/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
[root@master1 ~]# kubectl apply -f deploy-demo.yaml //更新资源清单文件
[root@master1 ~]# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
myapp-v1 2/2 2 2 60s
[root@master1 ~]# kubectl get rs
AME DESIRED CURRENT READY AGE
myapp-v1-67fd9fc9c8 2 2 2 2m35s
[root@master1 ~]# kubectl get pods -o wide | grep myapp
myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 10.244.187.78 node2
myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 10.244.209.136 node1
[root@master1 ~]# curl 10.244.187.78
…
background-color: blue;
[root@master1 ~]# curl 10.244.209.136
…
background-color: blue;
10.5 Deployment管理pod
10.5.1 通过deployment管理应用，实现扩容，把副本数变成3
[root@master1 ~]# vim deploy-demo.yaml
直接修改replicas数量，变成3
spec:
replicas: 3
修改之后保存退出，执行:
[root@master1 ~]# kubectl apply -f deploy-demo.yaml
注意：apply不同于create，apply可以执行多次；create执行一次，再执行就会报错复。
[root@master1 ~]# kubectl get pods
myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 15m
myapp-v1-67fd9fc9c8-h9js5 1/1 Running 0 11s
myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 17m
[root@master1 ~]# kubectl describe deploy myapp-v1
10.5.2 通过deployment管理应用，实现缩容，把副本数变成2
[root@master1 ~]# vim deploy-demo.yaml
直接修改replicas数量，如下，变成2
spec:
replicas: 2
修改之后保存退出，执行:
[root@master1 ~]# kubectl apply -f deploy-demo.yaml
[root@master1 ~]# kubectl get pods
myapp-v1-67fd9fc9c8-fcprr 1/1 Running 0 18m
myapp-v1-67fd9fc9c8-hw4f9 1/1 Running 0 20m
10.6 通过k8s实现滚动更新
10.6.1 滚动更新简介
滚动更新是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式，一次滚动发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义），例如第一批1台，第二批10%，第三批50%，第四批100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的。
10.6.2 在k8s中实现滚动更新
看下Deployment资源对象的组成：
[root@master1 ~]# kubectl explain deployment
[root@master1 ~]# kubectl explain deployment.spec
|
KIND: Deployment VERSION: apps/v1 RESOURCE: spec <Object> FIELDS: minReadySeconds <integer> paused <boolean> #暂停，当我们更新的时候创建pod先暂停，不是立即更新。 progressDeadlineSeconds <integer> replicas <integer> revisionHistoryLimit <integer> #保留的历史版本数，默认是10个 selector <Object> -required- strategy <Object> #更新策略，支持的滚动更新策略 template <Object> -required- |
[root@master1 ~]# kubectl explain deploy.spec.strategy
|
KIND: Deployment VERSION: apps/v1 RESOURCE: strategy <Object> FIELDS: rollingUpdate <Object> type <string> #支持两种更新，Recreate和RollingUpdate #Recreate是重建式更新，删除一个更新一个 #RollingUpdate 滚动更新，定义滚动更新的更新方式的，也就是pod能多几个，少几个，控制更新力度的。 |
[root@master1 ~]# kubectl explain deploy.spec.strategy.rollingUpdate
|
KIND: Deployment VERSION: apps/v1 RESOURCE: rollingUpdate <Object> FIELDS: maxSurge <string> #我们更新的过程当中最多允许超出的指定的目标副本数有几个；它有两种取值方式，第一种直接给定数量，第二种根据百分比，百分比表示原本是5个，最多可以超出20%，那就允许多一个，最多可以超过40%，那就允许多两个。 maxUnavailable <string> #最多允许几个不可用，假设有5个副本，最多一个不可用，就表示最少有4个可用。 |
10.6.3 测试滚动更新
在终端执行如下：
[root@master1 ~]# kubectl get pods -l app=myapp -w
打开一个新的终端窗口更改镜像版本，按如下操作：
[root@master1 ~]# vim deploy-demo.yaml
把image: janakiramm/myapp:v1 变成image: janakiramm/myapp:v2
保存退出，执行
[root@master1 ~]# kubectl apply -f deploy-demo.yaml
再回到第一个监测的窗口，可以看到信息如下：
NAME READY STATUS RESTARTS AGE
myapp-v1-67fd9fc9c8-tsl92 1/1 Running 0 22m
myapp-v1-67fd9fc9c8-4bv5n 1/1 Running 0 22m
myapp-v1-67fd9fc9c8-cw59c 1/1 Running 0 14m
myapp-v1-75fb478d6c-24tbp 0/1 Pending 0 0s
myapp-v1-75fb478d6c-24tbp 0/1 Pending 0 0s
myapp-v1-75fb478d6c-24tbp 0/1 ContainerCreating 0 0s
myapp-v1-75fb478d6c-24tbp 1/1 Running 0 11s
myapp-v1-67fd9fc9c8-cw59c 1/1 Terminating 0 15m
myapp-v1-75fb478d6c-f52l6 0/1 Pending 0 0s
myapp-v1-75fb478d6c-f52l6 0/1 Pending 0 0s
myapp-v1-75fb478d6c-f52l6 0/1 ContainerCreating 0 0s
myapp-v1-67fd9fc9c8-cw59c 0/1 Terminating 0 15m
myapp-v1-75fb478d6c-f52l6 1/1 Running 0 11s
myapp-v1-67fd9fc9c8-4bv5n 1/1 Terminating 0 23m
myapp-v1-75fb478d6c-jlw28 0/1 Pending 0 0s
myapp-v1-75fb478d6c-jlw28 0/1 Pending 0 0s
myapp-v1-75fb478d6c-jlw28 0/1 ContainerCreating 0 0s
myapp-v1-75fb478d6c-jlw28 1/1 Running 0 1s
pending表示正在进行调度，ContainerCreating表示正在创建一个pod，running表示运行一个pod，running起来一个pod之后再Terminating（停掉）一个pod，以此类推，直到所有pod完成滚动升级。
[root@master1 ~]# kubectl get rs
显示如下：
NAME DESIRED CURRENT READY AGE
myapp-v1-75fb478d6c 3 3 3 2m7s
myapp-v1-67fd9fc9c8 0 0 0 25m
上面可以看到rs有两个，下面那个是升级之前的，已经被停掉，但是可以随时回滚。
[root@master1 ~]# kubectl rollout history deployment myapp-v1 //查看myapp-v1这个控制器的滚动历史
REVISION CHANGE-CAUSE
1 <none>
2 <none>
[root@master1 ~]# kubectl rollout undo deployment/myapp-v1 --to-revision=1 //回滚操作
10.6.4 自定义滚动更新策略
maxSurge和maxUnavailable用来控制滚动更新的更新策略。
数值:
1. maxUnavailable: [0, 副本数]
2. maxSurge: [0, 副本数]
注意：两者不能同时为0。
比例:
1. maxUnavailable: [0%, 100%] 向下取整，比如10个副本，5%的话==0.5个，但计算按照0个；
2. maxSurge: [0%, 100%] 向上取整，比如10个副本，5%的话==0.5个，但计算按照1个；
注意：两者不能同时为0。
建议配置:
1. maxUnavailable == 0
2. maxSurge == 1
这是我们生产环境提供给用户的默认配置。即“一上一下，先上后下”最平滑原则：
1个新版本pod ready后，才销毁旧版本pod。此配置适用场景是平滑更新、保证服务平稳，缺点就是“太慢”了。
总结：
maxUnavailable：和期望的副本数比，不可用副本数最大比例（或最大值），这个值越小，服务越稳定，更新越平滑。
maxSurge：和期望的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快。
自定义策略：
修改更新策略：maxUnavailable=1，maxSurge=1
[root@master1 ~]# kubectl patch deployment myapp-v1 -p '{"spec":{"strategy":{"rollingUpdate": {"maxSurge":1,"maxUnavailable":1}}}}'
[root@master1 ~]# kubectl describe deployment myapp-v1 //查看myapp-v1这个控制器的详细信息
RollingUpdateStrategy: 1 max unavailable, 1 max surge
上面可以看到RollingUpdateStrategy: 1 max unavailable, 1 max surge
这个rollingUpdate更新策略变成了刚才设定的，因为我们设定的pod副本数是3，1和1表示最少不能少于2个pod，最多不能超过4个pod ,这个就是通过控制RollingUpdateStrategy这个字段来设置滚动更新策略的。
把pod更新策略变成Recreate:
[root@master1 ~]# vim deploy-demo.yaml
……
spec:
strategy:
type: Recreate
……
[root@master1 ~]# kubectl apply -f deploy-demo.yaml
打开新的终端，看pod更新过程:
[root@master1 ~]# kubectl get pods -w
总结：recreate这种更新策略，会把之前的所有pod都删除，再创建新的pod，风险很大。
10.7 生产环境如何实现蓝绿部署？
10.7.1 什么是蓝绿部署？
蓝绿部署中，一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的、正在运行的系统，只是系统版本和对外服务情况不同。
开发新版本，要用新版本替换线上的旧版本，在线上的系统之外，搭建了一个使用新版本代码的全新系统。 这时候，一共有两套系统在运行，正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。
蓝色系统不对外提供服务，用来做什么呢？
用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。（注意，两套系统没有耦合的时候才能百分百保证不干扰）
蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统：
切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。
当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。 原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。
10.7.2 蓝绿部署的优势和缺点
优点：
1、更新过程无需停机，风险较少。
2、回滚方便，只需要更改路由或者切换DNS服务器，效率较高。
缺点：
1、成本较高，需要部署两套环境。如果新版本有问题会影响全网用户。
2、需要部署两套机器，费用开销大。
3、在非隔离的机器（Docker、VM）上操作时，可能会导致蓝绿环境被摧毁风险。
4、负载均衡器/反向代理/路由/DNS处理不当，将导致流量没有切换过来情况出现。
10.7.3 通过k8s实现线上业务的蓝绿部署
把myapp-v1.tar.gz和myapp-v2.tar.gz上传到node1和node2上，手动解压：ctr -n=k8s.io images import
Kubernetes不支持内置的蓝绿部署。目前最好的方式是创建新的deployment，然后更新应用程序的service以指向新的deployment部署的应用
创建蓝色部署环境（基于第一版代码做的镜像运行的pod）
[root@master1 ~]# vim blue.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-v1
namespace: blue-green
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: v1
template:
metadata:
labels:
app: myapp
version: v1
spec:
containers:
- name: myapp
image: janakiramm/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
[root@master1 ~]# kubectl create ns blue-green
[root@master1 ~]# kubectl apply -f blue.yaml
[root@master1 ~]# kubectl get pods -n blue-green
myapp-v1-75d7db5cf7-4qnjz 1/1 Running 0 8s
myapp-v1-75d7db5cf7-5sk6j 1/1 Running 0 8s
myapp-v1-75d7db5cf7-wmhs4 1/1 Running 0 8s
[root@master1 ~]# kubectl get pods -n blue-green --show-labels
NAME READY STATUS RESTARTS AGE LABELS
myapp-v1-75d7db5cf7-4qnjz 1/1 Running 0 35s app=myapp,pod-template-hash=75d7db5cf7,version=v1
myapp-v1-75d7db5cf7-5sk6j 1/1 Running 0 35s app=myapp,pod-template-hash=75d7db5cf7,version=v1
myapp-v1-75d7db5cf7-wmhs4 1/1 Running 0 5s app=myapp,pod-template-hash=75d7db5cf7,version=v1
[root@master1 ~]# vim service_lanlv.yaml //修改前端service
apiVersion: v1
kind: Service
metadata:
name: myapp-lan-lv
namespace: blue-green
labels:
app: myapp
spec:
type: NodePort
ports:
- port: 80
nodePort: 30062
name: http
selector:
app: myapp
version: v1
[root@master1 ~]# kubectl apply -f service_lanlv.yaml
[root@master1 ~]# kubectl get svc -n blue-green
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myapp-lan-lv NodePort 10.107.213.1 <none> 80:30062/TCP 36s
在浏览器访问http://k8s-master节点ip:30062，例如：http://192.168.40.180:30062，显示如下：
创建绿色部署环境（新上线的环境，要替代蓝色环境）
[root@master1 ~]# vim green.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-v2
namespace: blue-green
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: v2
template:
metadata:
labels:
app: myapp
version: v2
spec:
containers:
- name: myapp
image: janakiramm/myapp:v2
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
然后可以使用kubectl命令创建部署。
[root@master1 ~]# kubectl apply -f lan.yaml
[root@master1 ~]# kubectl get pods -n blue-green
NAME READY STATUS RESTARTS AGE
myapp-v1-75d7db5cf7-4qnjz 1/1 Running 0 13m
myapp-v1-75d7db5cf7-5sk6j 1/1 Running 0 13m
myapp-v1-75d7db5cf7-wmhs4 1/1 Running 0 13m
myapp-v2-85cc897d89-hp5j2 1/1 Running 0 10s
myapp-v2-85cc897d89-jpgbm 1/1 Running 0 10s
myapp-v2-85cc897d89-q94g4 1/1 Running 0 10s
修改service_lanlv.yaml 配置文件，修改标签，让其匹配到绿程序（升级之后的程序）
[root@master1 ~]# vim service_lanlv.yaml
apiVersion: v1
kind: Service
metadata:
name: myapp-lan
namespace: blue-green
labels:
app: myapp
spec:
type: NodePort
ports:
- port: 80
nodePort: 30062
name: http
selector:
app: myapp
version: v2
[root@master1 ~]# kubectl apply -f service_lanlv.yaml //更新资源清单文件
[root@master1 ~]# kubectl get svc -n blue-green
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myapp-lan-lv NodePort 10.107.213.1 <none> 80:30062/TCP 9m50s
在浏览器访问http://k8s-master节点ip:30062 显示如下：
实验完成之后，把资源先删除，以免影响后面实验：
[root@master1 ~]# kubectl delete -f blue.yaml
[root@master1 ~]# kubectl delete -f green.yaml
[root@master1 ~]# kubectl delete -f service_lanlv.yaml
10.8 金丝雀发布
10.8.1 金丝雀发布简介
金丝雀发布的由来：17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；当瓦斯含量超过一定限度时，虽然人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为瓦斯检测指标，以便在危险状况下紧急撤离。
金丝雀发布（又称灰度发布、灰度更新）：金丝雀发布一般先发1台，或者一个小比例，例如2%的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试 （国内常称灰度测试）。
简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。 如果金丝测试通过，则把剩余的V1版本全部升级为V2版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。
优点：灵活，策略自定义，可以按照流量或具体的内容进行灰度，出现问题不会影响全网用户。
缺点：没有覆盖到所有的用户导致出现问题不好排查。
10.8.2 在k8s中实现金丝雀发布
打开一个标签1监测更新过程
[root@master1 ~]# kubectl apply -f blue.yaml
[root@master1 ~]# kubectl get pods -l app=myapp -n blue-green -w
NAME READY STATUS RESTARTS AGE
myapp-v1-75d7db5cf7-c7z5d 1/1 Running 0 5s
myapp-v1-75d7db5cf7-km5bg 1/1 Running 0 5s
myapp-v1-75d7db5cf7-p7c8j 1/1 Running 0 5s
打开另一个标签2执行如下操作：
[root@master1 ~]# kubectl set image deployment myapp-v1 myapp=janakiramm/myapp:v2 -n blue-green && kubectl rollout pause deployment myapp-v1 -n blue-green
回到标签1观察，显示如下：
NAME READY STATUS RESTARTS AGE
myapp-v1-67fd9fc9c8-5fd2f 1/1 Running 0 86s
myapp-v1-67fd9fc9c8-92mdr 1/1 Running 0 86s
myapp-v1-75fb478d6c-wddds 0/1 Pending 0 0s
myapp-v1-75fb478d6c-wddds 0/1 Pending 0 0s
myapp-v1-75fb478d6c-wddds 0/1 ContainerCreating 0 0s
myapp-v1-75fb478d6c-wddds 0/1 ContainerCreating 0 1s
myapp-v1-75fb478d6c-wddds 1/1 Running 0 2s
注：上面的解释说明把myapp这个容器的镜像更新到janakiramm/myapp:v2版本 更新镜像之后，创建一个新的pod就立即暂停，这就是我们说的金丝雀发布；如果暂停几个小时之后没有问题，那么取消暂停，就会依次执行后面步骤，把所有pod都升级。
解除暂停，回到标签1继续观察：
打开标签2执行如下：
[root@master1 ~]# kubectl rollout resume deployment myapp-v1 -n blue-green
在标签1可以看到如下一些信息，下面过程是把余下的pod里的容器都更的版本：
NAME READY STATUS RESTARTS AGE
myapp-v1-67fd9fc9c8-5fd2f 1/1 Running 0 86s
myapp-v1-67fd9fc9c8-92mdr 1/1 Running 0 86s
......
myapp-v1-67fd9fc9c8-5fd2f 0/1 Terminating 0 10m
myapp-v1-67fd9fc9c8-92mdr 0/1 Terminating 0 10m
myapp-v1-67fd9fc9c8-92mdr 0/1 Terminating 0 10m
[root@master1 ~]# kubectl get rs -n blue-green
可以看到replicaset控制器有2个了
NAME DESIRED CURRENT READY AGE
myapp-v1-67fd9fc9c8 0 0 0 13m
myapp-v1-75fb478d6c 2 2 2 7m28s
标签：master1,kubectl,控制器,v1,myapp,Deployment,root From： https://www.cnblogs.com/KrillLiszt/p/17007207.html