目录
一、deployment部署控制器概念
- 在学习rc和rs控制器资源时,这两个资源都是控制pod的副本数量的,但是,他们两个有个缺点,就是在部署新版本pod或者回滚代码的时候,需要先apply资源清单,然后再删除现有pod,通过资源控制,重新拉取新的pod来实现回滚或者迭代升级;
- deployments资源,实际上就是用来专门部署业务代码的控制器,专门用于企业业务代码的升级和回滚;
- deployment部署控制器,实际上控制的是rs副本控制器,如果说rs副本控制器是控制pod的副本数量的,那么deployment就是专门控制rs控制器资源的;
先看一下Deployment、RS、Pod它们三者之间的关系:
二、deployment资源的清单编写
deployment资源与replicaset资源的清单编写方式没什么区别,只是kind的类型换成deployment就可以了,就实现了资源清单的编辑;
bash
[root@k8s1 deploy]# cat deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: dm01
spec:
#控制pod的副本数量
replicas: 3
#指定标签选择器,基于标签匹配pod
selector:
#声明基于标签匹配pod;
matchLabels:
k8s: oslee
#pod的编写,定义pod模板;
template:
metadata:
name: pod01
labels:
k8s: oslee
spec:
containers:
- name: c1
image: harbor.oslee.com/oslee-private/my-nginx:v1
ports:
- containerPort: 80
[root@k8s1 deploy]# kubectl apply -f deploy.yaml
deployment.apps/dm01 created
三、小结
先以查看标签的方式,查看一下pod,可以看到下图中,多出来一个自动生成的标签;
deployment:是用来部署服务的一个资源,是常见的,企业中经常用的资源控制器;
功能
- 管理rs资源,通过rs资源管理pod;
- 它具有上线部署、副本设置、滚动升级、回滚等功能;
- 它也提供了声明式更新,可以使用apply命令进行更新镜像版本之类的能力
使用场景
企业部署迭代应用
原理
通过"标签"管理,实现rs资源的控制,它会在自动创建rs的过程中给rs自动生成一个特有的标签(专属于deployment),当apply更新清单的时候,它会通过标签选定是使用历史的rs还是重新创建rs;
四、deployment实现升级和回滚
1.编辑deployment资源清单(v1版本)
上面已创建好
2.创建service资源用于访问
bash
[root@k8s1 deploy]# cat svc.yaml
apiVersion: v1
kind: Service
metadata:
name: svc01
spec:
type: NodePort
selector:
k8s: oslee
clusterIP: 10.200.200.200
ports:
- port: 99
targetPort: 80
nodePort: 31000
[root@k8s1 deploy]# kubectl apply -f svc.yaml
service/svc01 created
3.修改deploy清单中pod镜像版本为V2
bash
[root@k8s1 deploy]# cat deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: dm01
spec:
#控制pod的副本数量
replicas: 3
#指定标签选择器,基于标签匹配pod
selector:
#声明基于标签匹配pod;
matchLabels:
k8s: oslee
#pod的编写,定义pod模板;
template:
metadata:
name: pod01
labels:
k8s: oslee
spec:
containers:
- name: c1
image: harbor.oslee.com/oslee-private/my-nginx:v2
ports:
- containerPort: 80
[root@k8s1 deploy]# kubectl apply -f deploy.yaml
deployment.apps/dm01 configured
4.小结
- deployment,不需要删除原有的pod,只需要apply重新更新一下资源清单,即可实现产品迭代,同比与rc和rs资源,优势明显;
- deployment资源,在apply升级后,是又重新创建了rs资源,也就是再升级的过程中,有两个rs资源;
- 每修改一次镜像,就创建一个rs资源,我们选择使用哪个镜像,就会将这个镜像创建相应的pod副本数,不用的,就逐渐归零;
5.回滚
bash
# 查看滚动更新状态
kubectl rollout status deployment dm01
#查看历史版本
kubectl rollout history deployment dm01
#查看指定版本的信息
kubectl rollout history deployment/dm01 --revision=2
#回滚到历史版本
kubectl rollout undo deployment/dm01 --to-revision=2
五、deployment的升级策略
什么是升级策略?就是升级时过程的控制策略;
设置升级的策略类型,类型有两种:
- 第一种:Recreate:先停止所有pod,再批量创建新的pod;生产环境不建议使用,因为用户在此时会访问不到服务;
- 第二种:RollingUpdate:滚动更新,即实现部分更新,逐渐替换掉原有的pod,也就是默认的策略;
bash
[root@k8s1 deploy]# cat deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: dm01
spec:
#声明设置升级策略
strategy:
#设置升级的策略类型,类型有两种;
#第一种:Recreate:先停止所有pod,再批量创建新的pod;生产环境不建议使用,因为用户在此时会访问不到服务;
#第二种:RollingUpdate:滚动更新,即实现部分更新,逐渐替换掉原有的pod,也就是默认的策略;
type: RollingUpdate
#如果设置了滚动更新RollingUpdate类型,还需要设置更新的策略;
rollingUpdate:
#在原有pod副本数量的基础上,多启动pod的数量(也就是说,更新过程中同时可以存在2+副本数个pod,新旧版本一起)
maxSurge: 2
#在升级的过程中最大不可访问的pod的数量(也就是说,pod副本数-1的数量可以被访问)
maxUnavailable: 1
replicas: 7
selector:
matchLabels:
k8s: oslee
template:
metadata:
name: pod01
labels:
k8s: oslee
spec:
containers:
- name: c1
image: harbor.oslee.com/oslee-private/my-nginx:v1
ports:
- containerPort: 80
[root@k8s1 deploy]# kubectl apply -f deploy.yaml
deployment.apps/dm01 created
bash
# 监听变化
[root@k8s1 ~]# watch -n 2 kubectl get all
六、蓝绿发布
1.概念
蓝绿发布,就是准备两套代码,不需要停止老版本(不影响上一个版本的用户访问),而是在另一套环境中部署新版本然后进行测试,测试通过后将用户流量切换到新的版本。
- 优点:业务没有终端,升级风险相对较小;
- 缺点:消耗i资源
实现方式:
- 部署当前版本代码
- 部署svc资源
- 部署新版本使用新的deployment名称,新的标签
- 切换svc标签到新的pod中实现业务切换;
2.准备"蓝环境"版本v1
bash
[root@k8s1 deploy]# cat lan.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: dm01
spec:
#控制pod的副本数量
replicas: 3
#指定标签选择器,基于标签匹配pod
selector:
#声明基于标签匹配pod;
matchLabels:
k8s: oslee-lan
#pod的编写,定义pod模板;
template:
metadata:
name: pod01
labels:
k8s: oslee-lan
spec:
containers:
- name: c1
image: harbor.oslee.com/oslee-private/my-nginx:v1
ports:
- containerPort: 80
[root@k8s1 deploy]# kubectl apply -f lan.yaml
deployment.apps/dm01 created
3.编辑svc资源
bash
[root@k8s1 deploy]# cat svc.yaml
apiVersion: v1
kind: Service
metadata:
name: svc01
spec:
type: NodePort
selector:
k8s: oslee-lan
clusterIP: 10.200.200.200
ports:
- port: 99
targetPort: 80
nodePort: 31000
[root@k8s1 deploy]# kubectl apply -f svc.yaml
service/svc01 created
4.蓝环境v1准备完毕,访问测试
5.准备"绿环境"v2
bash
[root@k8s1 deploy]# cat lv.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: dm02
spec:
#控制pod的副本数量
replicas: 3
#指定标签选择器,基于标签匹配pod
selector:
#声明基于标签匹配pod;
matchLabels:
k8s: oslee-lv
#pod的编写,定义pod模板;
template:
metadata:
name: pod01
labels:
k8s: oslee-lv
spec:
containers:
- name: c1
image: harbor.oslee.com/oslee-private/my-nginx:v2
ports:
- containerPort: 80
[root@k8s1 deploy]# kubectl apply -f lv.yaml
deployment.apps/dm02 created
6.切换svc资源的标签,让其指向新版本
bash
[root@k8s1 deploy]# cat svc.yaml
apiVersion: v1
kind: Service
metadata:
name: svc01
spec:
type: NodePort
selector:
# 将lan修改为lv
k8s: oslee-lv
clusterIP: 10.200.200.200
ports:
- port: 99
targetPort: 80
nodePort: 31000
[root@k8s1 deploy]# kubectl apply -f svc.yaml
service/svc01 configured
7.访问测试
七、灰度发布(金丝雀发布)
灰度发布就是让新旧版本,一起上线,旧版本和新版本让用户随机访问到,然后没有业务问题之后,逐渐调高新版本副本数量,逐渐调低旧版本副本数量,从而达到灰度发布;
实现的机制:
- 部署老版本,使用多副本(模拟正式环境)
- 部署svc,匹配标签
- 部署新版本,标签与老版本标签一致(让svc能够访问到,副本从0开始)
- 灰度版本测试没有问题,将恢复版本的副本数量,逐渐调高增加为生产数量;
- 将旧版本逐渐调低至0,此时流量全部跑到了新版本上;
===============================至此,已成艺术==============================