​​kubernetes的Deployment​​

​​kubernetes的Deployment​​

​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 或其他资源的不同方式

以上这些方式修改完Deployment资源后，会

自动触发滚动升级

注意：如果Deployment的pod模板引用了一个configmap/secret，那么更改configmap资源不会触发升级。需要创建一个新的configmap

然后需改pod模板引用新的configmap。

滚动升级的相关控制

在升级过程中可以控制一次替换多少个pod

apiVersion: apps/v1kind: Deploymentmetadata: name: appspec: 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

恢复滚动升级

因为修改Deployment时会自动触发滚动升级，如果不想立即升级，可以通过不停的使用暂停滚动升级，直到对deployment的修改完毕后，再恢复滚动升级。

kubectl rollout resume deployment kubia

阻止出错版本的滚动升级

可以通过Deployment的spec.minReadySeconds和就绪探针实现，升级过程中发现新版本故障，自动停止升级。

minReadySeconds指的是，新创建的pod至少要成功运行多久之后 ，才能将其视为可用，在这个期间内，deployment不会继续滚动升级，除非这个pod已经被视为可用。

在升级过程中，pod的就绪探针返回成功后，kubernetes才会视为pod可用，而在deployment升级过程中只有在minReadySeconds时间内，

pod的就绪探针没有返回过失败，才会判断为这个新版本pod发布没有问题，然后继续后面的滚动升级动作，否则会阻止滚动升级。

可以通过设置Deployment的spec.progressDeadlineSeconds值来定义升级的时间限制，如果在设置时间内没有完成升级，则会停止升级动作。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。