一、Deployment控制器
Deployment对象,顾名思义,是用于部署应用的对象。它使Kubernetes中最常用的一个对象,它为ReplicaSet和Pod的创建提供了一种声明式的定义方法,从而无需像前两篇文章中那样手动创建ReplicaSet和Pod对象(使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性,例如滚动升级和回滚)。
通过Deployment对象,你可以轻松的做到以下事情:
创建ReplicaSet和Pod
滚动升级(不停止旧服务的状态下升级)和回滚应用(将应用回滚到之前的版本)
平滑地扩容和缩容
暂停和继续Deployment
1.1 Deployment 的控制器,实际上控制的是 ReplicaSet 的数目,以及每个 ReplicaSet的属性。而一个应用的版本,对应的正是一个 ReplicaSet;这个版本应用的 Pod数量,则由 ReplicaSet 通过它自己的控制器(ReplicaSet Controller)来保证。
1.2 Deployment具备ReplicaSet的全部功能,同时还增添了部分特性。
- 事件和状态查看:必要时可以查看Deployment对象升级的详细进度和状态。
- 回滚:升级操作完成后发现问题时,支持使用回滚机制将应用返回到前一个或由用户指定的历史记录中的版本上。
- 版本记录:对Deployment对象的每一次操作都予以保存,以供后续可能执行的回滚操作使用。
- 暂停和启动:对于每一次升级,都能够随时暂停和启动。
- 多种自动更新方案:一是Recreate,即重建更新机制,全面停止、删除旧有的Pod后用新版本替代;另一个是RollingUpdate,即滚动升级机制,逐步替换旧有的Pod至新的版本。
1.3 创建Deployment除了控制器类型和名称之外,它与前面ReplicaSet控制器示例中的内容几乎没有什么不同
创建deployment资源,
# cat deployment-example.yaml apiVersion: apps/v1 kind: Deployment metadata: name: deployment-example spec: replicas: 3 selector: matchLabels: app: deploy-demo template: metadata: labels: app: deploy-demo spec: containers: - name: nginx image: nginx ports: - name: http containerPort: 80
由此印证了Deployment借助于ReplicaSet管理Pod资源的机制,于是可以得知,其大部分管理操作与ReplicaSet相同,
[root@k8s-master contorlermanager]# kubectl get pod NAME READY STATUS RESTARTS AGE deployment-example-547f4c8b7d-pckv5 1/1 Running 0 57s deployment-example-547f4c8b7d-vcbsf 1/1 Running 0 57s deployment-example-547f4c8b7d-zt4r4 1/1 Running 0 57s [root@k8s-master contorlermanager]# kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE deployment-example 3/3 3 3 63s
NAME代表Deployment的名字,DESIRED代表这个Deployment期望的副本数量,CURRENT代表当前已经创建了的副本数量,UP-TO-DATE代表已经更新完成的副本数量,AVAILABLE代表对于当前用户可用的副本数量,AGE代表当前Deployment已经运行的时长
1.4 更新策略
Deployment更新时会创建一个新的ReplicaSet,然后将新的ReplicaSet中的Pod慢慢扩容到指定的副本数,将旧的ReplicaSet慢慢缩容到0。因此,更新时总能够确保旧的服务不会停止,这就是滚动更新。
Deployment控制器支持两种更新策略:滚动更新和重新创建。
- 滚动更新是默认的更新策略,它在删除一部分旧版本Pod资源的同时,补充创建一部分新版本的Pod对象进行应用升级。
- 重新创建首先删除现有的Pod对象,而后由控制器基于新模板重新创建出新版本资源对象。
滚动更新时,应用升级期间还要确保可用的Pod对象数量不低于某阈值以确保可以持续处理客户端的服务请求,变动的方式和Pod对象的数量范围将通过spec.strategy.rollingUpdate.maxSurge和spec.strategy.rollingUpdate.maxUnavailable两个属性协同进行定义
- maxSurge:指定升级期间存在的总Pod对象数量最多可超出期望值的个数,其值可以是0或正整数,也可以是一个期望值的百分比;例如,如果期望值为3,当前的属性值为1,则表示Pod对象的总数不能超过4个。
- maxUnavailable:升级期间正常可用的Pod副本数(包括新旧版本)最多不能低于期望数值的个数,其值可以是0或正整数,也可以是一个期望值的百分比;默认值为1,该值意味着如果期望值是3,则升级期间至少要有两个Pod对象处于正常提供服务的状态
为了保存版本升级的历史,需要在创建Deployment对象时于命令中使用“–record”选项。
使用命令临时更新镜像
- 使用192.168.10.110/k8s/myapp:v2镜像文件修改Pod模板中的myapp容器,启动Deployment控制器的滚动更新
$ kubectl set image deployments myapp-deploy myapp=192.168.2.10/k8s/myapp:v2
- 或者我们可以使用 edit 命令来编辑 Deployment,将image从nginx改写成 nginx:1.9.1
kubectl edit deployment/deployment-example
- 访问验证
灰度发布(金色雀发布)
- 待第一批新的Pod资源创建完成后立即暂停更新过程,此时,仅存在一小部分新版本的应用,主体部分还是旧的版本。然后,再根据用户特征精心筛选出小部分用户的请求路由至新版本的Pod应用,并持续观察其是否能稳定地按期望的方式运行。
- 采用首批添加1个Pod资源的方式。将Deployment控制器的maxSurge属性的值设置为1,并将maxUnavailable属性的值设置为0:
$ kubectl patch deployments myapp-deploy -p '{"spec":{"strategy":{"rollingUpdate": {"maxSurge": 1, "maxUnavailable":0}}}}'
rollout pause和resume
kubectl rollout pause会用来停止触发下一次rollout,正在执行的滚动历程是不会停下来的,而是会继续正常的进行滚动,直到完成。等下一次,用户再次触发rollout时,Deployment就不会真的去启动执行滚动更新了,而是等待用户执行了kubectl rollout resume,流程才会真正启动执行。灰度发布、滚动发布和蓝绿发布,**假设replicaSet=10 maxSurge &maxUnavailable不能同时为0 **
类型 描述 maxSurge maxUnavailable 灰度发布 又名金丝雀发布。先极个别更新,通过后再一次全部更新 1或10% 视对服务可用度的需求 滚动发布 (部分更新,投入使用)* 直到全部更新完成 1<x<(具体看更新的粒度) 视对服务可用度的需求 蓝绿发布 新旧版共存,靠切换流量完成更新 10 0
1.5 回滚
将myapp-deploy回滚至此前的版本:$ kubectl rollout undo deployments myapp-deploy
若要回滚到号码为1的revision记录,则使用如下命令即可完成:
$ kubectl rollout undo deployments myapp-deploy --to-revision=1
回滚操作中,其revision记录中的信息会发生变动,回滚操作会被当作一次滚动更新追加进历史记录中,而被回滚的条目则会被删除。
如果此前的滚动更新过程处于“暂停”状态,那么回滚操作就需要先将Pod模板的版本改回到之前的版本,然后“继续”更新,否则,其将一直处于暂停状态而无法回滚。
rollout
命令的更多用法: