Kubernetes学习笔记-Deployment：声明式的升级应用（2）20220605

Deployment是一种更高阶资源，用于部署应用程序并以声明的方式升级应用，而不是通过ReplicationController或ReplicaSet进行部署。在使用Deployment时，实际的pod是由Deployment的Replicaset创建和管理的，而不是由Deployment直接创建和管理的。
在升级应用程序时，需要引入一个额外的ReplicationController，并协调两个controller，使他们再根据彼此不断修改，而不会造成干扰，所以需要另一个资源来协调。Deployment资源就是用来负责处理这个问题的（不是Deployment资源本身，而是在kubernetes控制层上运行的控制器进程）
使用Deployment可以更容易地更新应用程序，因为可以直接定义单个Deployment资源所需达到的状态，并让kubernetes处理中间的状态。

1）创建一个deployment
yaml文件
创建Deployment资源
在创建这个deployment之前，请确保删除仍在运行的任何ReplicationController和pod，但是暂时保留kubia service。可以使用- -all选项删除所有的ReplicationController
$kubectl delete rc - -all
可以创建一个Deployment
$kubectl creat -f kubia-deployment-v1.yaml - -record
注意：确保在创建时使用了- -record选项。这个选项会记录历史版本号，在之后的操作中非常有用
展示Deployment滚动过程中的状态
$kubectl rollout status deployment kubia —-查看部署状态

2）升级Deployment
之前讲到使用ReplicationController部署应用，必须通过运行kubectl rolling-update显式的告诉kubernets来执行更新，甚至必须为新的ReplicationController指定名称来替换旧的资源。kubernetes会将所有原来的pos替换为新的pod，并在结束后删除原有的ReplicationController。整个过程中必须保持终端处于打开状态，让kubectl完成升级
Deployment的方式与上述流程相比，只需要修改Deployment资源中定义的pod模版，kubernetes会自动将实际的系统状态收敛为资源中定义的状态，类似于将ReplicationController或ReplicaSet扩容或缩容，升级需要做的就是在部署的pod模版中修改镜像的tag，kubernetes会收敛系统，匹配期望的状态。
不同的Deployment升级策略
默认策略滚动更新（RollingUpdate），另一个策略Recreate，它会一次性删除所有旧版本pod，然后创建新的pod，类似于修改ReplicationController的pod模版，然后删除所有的pod
Recreate策略在删除旧的pod之后才开始创建新pod。如果应用程序不支持多个版本同时对外提供服务，需要在启动新版本之前完全停用旧版本，就使用这种策略，但使用这种策略会导致应用程序出现短暂的不可用
RollingUpdate策略会渐进的删除旧的pod，与此同时创建新pod，使应用程序在整个升级过程中都处于可用状态，并确保其处理请求的能力没有因为升级而有所影响。这就是Deployment默认使用的升级策略。升级过程中pod数量可以在期望副本数的一定区间内浮动，并且其上限和下限是可配置的。如果应用程序能够支持多个版本同时对外提供服务，则推荐使用这个策略来升级应用。
可以通过在Deployment上设置minReadySeconds属性来设置滚动升级速度
$kubectl patch deployment kubia -p ‘｛“spec”：｛“minReadySeconds”：10｝｝’
使用patch命令更改Deployment的自由属性，并不会导致pod的任何更新，因为pod模版并没有被修改。更好其它Deployment的属性，比如所需的副本数或部署策略；也不会触发滚动升级，现有运行中的pos也不会受其影响。
修改Deployment或其它资源的不同方式

Deployment的优点：

• 升级过程是由运行在kubernetes上的一个控制器处理和完成的，而不是kubectl rolling-update命令，它的升级由kubectl客户端执行的，让kubernetes的控制器接管使得整个升级过程变得更加简单可靠

Deployment背后完成整个升级过程和执行kubectl rolling-update命令非常类似。一个新的ReplicaSet会被创建然后慢慢扩容，同时之前版本的ReplicaSet会慢慢缩容至0
与ReplicationController类似，所有新的pod现在由新的ReplicaSet管理，与以前不同的是，旧的ReplicaSet仍然会被保留，而旧的ReplicationController会在滚动升级过程结束后被删除。
因为没有直接创建ReplicaSet，所以不需要关心和维护。所有操作都是在Deployment资源上完成。

3）回滚Deployment
$kubectl rollout undo deployment kubia
回滚到一个指定的Deployment版本
$kubectl rollout undo deployment kubia - -to -revision=1
注意：由Deployment创建的所有ReplicaSet表示完整的修改版本历史。每个ReplicaSet都有特定的版本号来保存Deployment的完整信息，所以不应该手动删除ReplicaSet

4）控制滚动升级速度
maxSurge：Deployment配置中期望的副本数之外，最多允许超出的pod数量。默认25%
maxUnavailable ：决定滚动升级时，相对于期望副本数能够允许有多少pod实例处于不可用状态，默认25%

5）暂停滚动
$kubia rollout pause deployment kubia —-暂停
$kubia rollout resume deployment kubia—恢复

6）阻止出错版本的滚动升级
使用minReadySeconds设置滚动升级速率，避免部署出错版本的应用。指定新创建的pod至少要运行多久之后，才能将其视为可用。在pod可用之前，滚动升级的过程不会继续。
使用minReadySeconds结合容器的就绪探针，避免出错版本的滚动升级。
当新的pod启动时，就绪探针会每隔一秒发起请求（在pod spec中，就绪探针的间隔被设置为1秒）。在就绪探针发起第五个请求的时候会出现失败，因为应用从第5个请求开始一直返回http状态码500
为滚动升级配置deadline，默认情况下，在10分钟内不能完成滚动升级的话，将被视为失败。
判断Deployment滚动失败的超时时间，可以通过设定Deployment spec中的peogressDeadlineSexonds来指定。
取消出错版本的升级滚动
$kubectl rollout undo deployment kubia

小结：
使用ReplicationController管理pod并执行滚动升级
创建Deployment，而不是底层的Replication和ReplicaSet
通过更新Deployment定义的pod模版来更新pod
回滚Deployment到上个版本或历史版本列表中的任意一个历史版本
中止Deployment升级
滚动升级时，在所有pod被替换之前，暂停Deployment滚动升级查看单个新版本的实例状况
通过maxSurge和maxUnavailable属性控制滚动升级速率
使用minReadySeconds和就绪探针自动避免错误版本的升级
在一个单一的yaml文件内使用三个横杠（- - -）作为分隔符定义多个资源
打开kubectl 的详细日志模式，查看背后运行的详细日志