D21 kubernetes 工作负载资源对象-Deployment{滚动更新、容器健康检查的重要性}
1、滚动更新实现
通过查看Deployment事件来了解具体的升级过程，如下所示:
[root@k8s-master ~]# kubectl describe deployment django-blog -n blog
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 98s deployment-controller Scaled up replica set django-blog-56b8568d85 to 1
Normal ScalingReplicaSet 77s deployment-controller Scaled down replica set django-blog-85c648b474 to 2 from 3
Normal ScalingReplicaSet 77s deployment-controller Scaled up replica set django-blog-56b8568d85 to 2 from 1
Normal ScalingReplicaSet 57s deployment-controller Scaled down replica set django-blog-85c648b474 to 1 from 2
Normal ScalingReplicaSet 57s deployment-controller Scaled up replica set django-blog-56b8568d85 to 3 from 2
Normal ScalingReplicaSet 45s deployment-controller Scaled down replica set django-blog-85c648b474 to 0 from 1
在上述事件中，当创建一个Deployment时，kubernetes会自动创建一个ReplicaSet（django-blog-56b8568d85）来管理pod副本数，并将其pod副本数扩展为3，既第一条记录。此时Deployment 与 ReplicaSet的关系图如下
ReplicaSet（副本集）是Deployment的底层机制，负责维护指定数量的pod副本。通常，ReplicaSet不是直接创建的而是由Deployment自动管理的。
- 查看ReplicaSet对象
[root@k8s-master ~]# kubectl get replicaset -n blog
NAME DESIRED CURRENT READY AGE
django-blog-56b8568d85 3 3 3 11m
django-blog-5fb58fd87f 0 0 0 5d
当触发滚动更新时，kubernetes首先会创建一个新的ReplicaSet(django-blog-56b8568d85)，并将其pod副本数扩展为1；接着将旧ReplicaSet（django-blog-5fb58fd87f）的pod副本数由3缩减为2；然后，将新ReplicaSet的pod副本数由1扩展为2，旧ReplicaSet的pod副本数由2缩减为1；最后将新ReplicaSet的pod副本数由2扩展为3，将旧ReplicaSet的pod副本数由1缩减为0，滚动更新执行完成
在滚动更新过程中，新ReplicaSet的pod副本数逐渐增加，而旧ReplicaSet的pod副本数逐渐减少，以实现平滑的更新过程。在整个过程中，始终保值指定数量的pod运行，以确保应用程序持续提供服务
2、滚动更新策略
- Deployment更新策略的默认配置如下
apiVersion: apps/v1
kind: deployment
metadata:
name: dhango-blog
namespace: blog
spec:
replicas: 3
selector:
matchLabels:
app: django
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
在上述配置中，strategy.rollingUpdate部分定义了滚动更新策略，其中字段含义如下
- maxSurge：在滚动更新期间，超过期望副本数的pod的最大数量，既新版本的pod数量可以超过旧版本的pod数量。该值是一个正整数或期望副本数的百分比，默认值为25%。例如，期望副本数为3，则表示总pod数量不超过4个，既3+25%*x3=3.+0.75=3.75
- maxUnavailable：在滚动更新期间，不可用的pod的最大数量，既旧版本不可用的pod数量。该值是一个正整数或期望副本数的百分比，默认值为25%。例如，如果期望副本数为3，则表示不可用pod数量不超过1个，既3x25%=0.75
- 假设期望副本数为10，则在滚动更新期间启动pod的最大数量不超过12个，不可用的pod的最大数量不超过2个
- strategy.type：用于指定策略类型，默认值为RollingUpdate滚动更新策略。此外，还支持recreate重建，在该策略下，Deployment先停止和删除所有旧版本pod，然后创建新版本pod，这意味着服务会短暂中断。因此，该策略比较适合快速部署和容忍短暂服务中断的场景
因此，当期望副本数比较多时，滚动更新过程会比较慢。这是因为同时停止的pod数量收到maxUnavailable的限制，导致每次只能升级少量的pod。如果希望滚动更新更快完成，可以将maxUnavailable的值设置较高，以允许同时停止更多的pod
需要注意的是，如果将maxUnavailable的值设置过高，name每次停止的pod数量就会过大，这可能会导致服务短暂中断
3、容器健康检查的重要性
在滚动更新过程中，如果新版本的pod由于某种原因无法启动，如拉取镜像失败、容器中主进程启动失败等，kubernetes将会终止更新过程，以防止进一步升级对现有业务造成更大的影响
如果新版本的pod启动成功，即使容器中应用程序仍在启动中，kubernetes也会继续升级，这可能导致部分用户方位异常。在这种情况下，配置容器就绪探针尤为重要，只有在就绪探针成功后，kubernetes才会继续升级。这确保了只有在新版本的pod准备好接受流量之后才会删除响应的旧版本的pod，从而避免在滚动更新中服务的短暂中断
