kubernetes的Deployment
Deployment
在我们发布容器中的服务时,总共有一下几种方式:
- 将旧的pod停掉,创建新的pod并发布
- 创建新的pod,然后将旧的pod停掉
- 滚动式升级。创建一个新的pod,删除一个旧的pod,直到所有的旧pod都被替换
其中最完美的升级方式就是滚动式升级,但是操作命令过于复杂,而kubernetes提供的rolling-update方式也存在着会修改原有pod标签、
kubectl所在服务器故障导致升级中断等风险。而Deployment就是为了完美解决这个问题诞生的。
Deployment创建后,会自动创建一个ReplicaSet,然后由其来创建pod。
Deployment的升级策略
- 滚动更新(RollingUpdate):默认策略,如果我们的服务支持多个版本同时运行,可以选择这个策略。
- Recreate:会一次性删除所有旧版本的pod,然后创建新的pod。如果我们的服务不支持多个版本运行,并且允许服务出现短暂的停用,
可以选择这个策略。
Deployment升级过程:自动创建一个新的ReplicaSet然后慢慢从0开始扩容,旧的ReplicaSet慢慢缩容至0,然后完成滚动升级。升级完成后,
旧版本的ReplicaSet并不会被自动删除,而是会保留下来,方便回滚时使用。默认会保留升级过程中的两个旧版本ReplicaSet
deployment的yaml文件及一些命令
- 创建命令
kubectl create -f deply.yaml --record
--record 命令会记录历史版本号 - 修改deployment的命令:
kubectl patch deployment deploymentName -p
kubectl patch命令会更改Deployment的自由属性,并不会导致pod的更新,因为pod的模板没有被修改。更改Deployment的其他属性也不会
导致滚动升级,例如:副本数或者部署策略 - 修改Deployment的镜像模板:
kubectl set image deployment deploymentName
- 查看Deployment的升级过程:
kubectl rollout status
- 查看Deployment升级过程中的历史版本:
kubectl rollout history deployment kubia
- 回滚Deployment:
kubectl rollout undo deployment kubia
- 回滚Deployment到指定版本:
kubectl rollout undo deployment kubia --to-revision=1
修改 Deployment 或其他资源的不同方式
方法 | 作用 | 例子 |
---|---|---|
kubectl edit | 使用默认编辑器打开资源配置。修改保存并退出编辑器,资源对象会被更新 | kubectl edit deployment kubia |
kubectl patch | 修改单个资源属性 | kubectl patch deployment deploymentName -p json格式的数据 |
kubectl apply | 通过一个完整的yaml或json文件来修改资源,如果文件中定义的资源不存在,会创建一个。文件中对资源的描述必须全面,不能像patch那样 | kubectl apply -f kubia-deploy.yaml |
kubectl replace | 将原有对象替换为yaml/json中定义的新对象。如果原有对象不存在,会报错 | kubectl replace -f kubia-deploy.yaml |
kubectl set image | 修改pod、rs、rc、deployment、DemonSet、job中的镜像 | kubectl set image deployment kubia nodejs=luksa/kubia:v2 |
以上这些方式修改完Deployment资源后,会自动触发滚动升级
注意:如果Deployment的pod模板引用了一个configmap/secret,那么更改configmap资源不会触发升级。需要创建一个新的configmap
然后需改pod模板引用新的configmap。
滚动升级的相关控制
- 在升级过程中可以控制一次替换多少个pod
apiVersion: apps/v1
kind: Deployment
metadata:
name: app
spec:
selector:
matchLabels:
name: app
strategy:
rollingUpdate:
# 决定了在升级过程中最多允许超出期待副本数的数量,默认为25%
# 如果期待副本数为4,那么运行时不会超过5个pod实例
# 如果设置的不是百分数的化,则代表的允许的最大超过数量,下面这个就是指最大超过一个
maxSurge: 1
# 决定了在升级过程中,最多允许多少个pod处于不可用状态,默认为25%
# 如果期待数量为4,那么可用的pod数量最低为3
# 如果设置的不是百分数的化,则代表的允许的最大不可用数量,下面这个就是指最大不可用数为一个
maxUnavailable: 0
- 暂停滚动升级
将一个Deployment创建几秒后,暂停该Deployment,这样的话会创建一个新的pod,同时旧的pod依然在运行。
这就是所谓的金丝雀发布,可以用来验证新版本的运行使用情况。验证完毕后可以继续升级或回滚旧版本。
目前还无法实现在一个确定的位置暂时滚动升级以达到金丝雀发布,所以上述方法还不健全。
可以操作的是可以创建两个不同的deployment,然后通过控制其pod数量来实现金丝雀发布
kubectl rollout pause deployment kubia
- 恢复滚动升级
kubectl rollout resume deployment kubia
因为修改Deployment时会自动触发滚动升级,如果不想立即升级,可以通过不停的使用暂停滚动升级,直到对deployment的修改完毕后,再恢复滚动升级。
阻止出错版本的滚动升级
可以通过Deployment的spec.minReadySeconds和就绪探针实现,升级过程中发现新版本故障,自动停止升级。
minReadySeconds指的是,新创建的pod至少要成功运行多久之后 ,才能将其视为可用,在这个期间内,deployment不会继续滚动升级,除非这个pod已经被视为可用。
在升级过程中,pod的就绪探针返回成功后,kubernetes才会视为pod可用,而在deployment升级过程中只有在minReadySeconds时间内,
pod的就绪探针没有返回过失败,才会判断为这个新版本pod发布没有问题,然后继续后面的滚动升级动作,否则会阻止滚动升级。
可以通过设置Deployment的spec.progressDeadlineSeconds值来定义升级的时间限制,如果在设置时间内没有完成升级,则会停止升级动作。