kubernetes的Deployment
Deployment
在我们发布容器中的服务时，总共有⼀下⼏种⽅式：
将旧的pod停掉，创建新的pod并发布
创建新的pod，然后将旧的pod停掉true副词
滚动式升级。创建⼀个新的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 t 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 t
image修改pod、rs、rc、deployment、DemonSet、job中的镜像kubectl t image deployment kubia nodejs=luksa/kubia:v2
以上这些⽅式修改完Deployment资源后，会⾃动触发滚动升级
注意：如果Deployment的pod模板引⽤了⼀个configmap/cret，那么更改configmap资源不会触发升级。需要创建⼀个新的configmap 然后需改pod模板引⽤新的configmap。
滚动升级的相关控制
1. 在升级过程中可以控制⼀次替换多少个pod
apiVersion: apps/v1
炸好的鱼块怎么做好吃kind: Deployment
metadata:
name: app
spec:
心理活动的描写lector:
matchLabels:
name: app
strategy:
rollingUpdate:
# 决定了在升级过程中最多允许超出期待副本数的数量，默认为25%
# 如果期待副本数为4，那么运⾏时不会超过5个pod实例
# 如果设置的不是百分数的化，则代表的允许的最⼤超过数量，下⾯这个就是指最⼤超过⼀个
maxSurge: 1
# 决定了在升级过程中，最多允许多少个pod处于不可⽤状态，默认为25%
# 如果期待数量为4，那么可⽤的pod数量最低为3
# 如果设置的不是百分数的化，则代表的允许的最⼤不可⽤数量，下⾯这个就是指最⼤不可⽤数为⼀个
maxUnavailable: 0
2. 暂停滚动升级
将⼀个Deployment创建⼏秒后，暂停该Deployment，这样的话会创建⼀个新的pod，同时旧的pod依然在运⾏。
这就是所谓的⾦丝雀发布，可以⽤来验证新版本的运⾏使⽤情况。验证完毕后可以继续升级或回滚旧版本。
⽬前还⽆法实现在⼀个确定的位置暂时滚动升级以达到⾦丝雀发布，所以上述⽅法还不健全。
可以操作的是可以创建两个不同的deployment，然后通过控制其pod数量来实现⾦丝雀发布
kubectl rollout pau deployment kubia
3. 恢复滚动升级
kubectl rollout resume deployment kubia
因为修改Deployment时会⾃动触发滚动升级，如果不想⽴即升级，可以通过不停的使⽤暂停滚动升级，直到对deployment的修改完毕后，再恢复滚动升级。
阻⽌出错版本的滚动升级
可以通过Deployment的spec.minReadySeconds和就绪探针实现，升级过程中发现新版本故障，⾃动停⽌升级。2元店
minReadySeconds指的是，新创建的pod⾄少要成功运⾏多久之后，才能将其视为可⽤，在这个期间内，deployment不会继续滚动升级，除⾮这个pod已经被视为可⽤。
在升级过程中，pod的就绪探针返回成功后，kubernetes才会视为pod可⽤，⽽在deployment升级过程中只有在minReadySeconds时间内，pod的就绪探针没有返回过失败，才会判断为这个新版本pod发布没有问题，然后继续后⾯的滚动升级动作，否则会阻⽌滚动升级。
可以通过设置Deployment的spec.progressDeadlineSeconds值来定义升级的时间限制，如果在设置时间内没有完成升级，则会停⽌升级动作。
