现在存在三个应用,分别对应一些 Pod,那么我们可以直接管理集群中所有的 Pod 吗?
如果管理所有的 Pod,那么如何保证集群里可用 Pod 数量?如何为所有 Pod 更新镜像版本?更新的过程中,如何保证服务可用性?更新的过程中,发现问题如何快速回滚?
可以通过 Deployment 将三个应用分别规划到不同的 Deployment,每个 Deployment 管理一组相同的应用 Pod,这组 Pod 是相同的一个副本。
Deployment 可以实现以下功能:
Deployment 只管理不同版本的 ReplicaSet,由 ReplicaSet 来管理具体的 Pod 副本数,每个 ReplicaSet 对应 Deployment template 的一个版本。
控制器通过 Informer 中的 Event 做一些 Handler 和 Watch,收到事件后会加入到队列中。而 Deployment controller 从队列中取出来之后,它的逻辑会判断 Check Paused,如果 Paused 设置为 true 的话,就表示这个 Deployment 只会做一个数量上的维持,不会做新的发布,如果为 false 的话,就会做 Rollout。
当 Deployment 分配 ReplicaSet 之后,ReplicaSet 控制器本身也是从 Informer 中 watch 一些事件,这些事件包含了 ReplicaSet 和 Pod 的事件。从队列中取出之后,ReplicaSet controller 的逻辑很简单,就只管理副本数。
Deployment 当前初始版本为 template1,底下有三个 Pod:Pod1、Pod2、Pod3。
这时修改 template 中一个容器的 image,Deployment controller 就会新建一个对应 template2 的 ReplicaSet。创建出来之后 ReplicaSet 会逐渐修改两个 ReplicaSet 的数量,比如逐渐增加 ReplicaSet2 中 replicas 的期望数量,逐渐减少 ReplicaSet1 中的 Pod 数量。
Deployment 在 RollingUpdate 中主要提供了两个策略,一个是 MaxUnavailable,另一个是 MaxSurge。
上文提到,ReplicaSet 为 3 的 Deployment 在发布的时候可能存在一种情况:新版本的 ReplicaSet 和旧版本的 ReplicaSet 都可能有两个 replicas,加在一起就是 4 个,超过了我们期望的数量三个。这是因为我们默认的 MaxUnavailable 和 MaxSurge 都是 25%,默认 Deployment 在发布的过程中,可能有 25% 的 replica 是不可用的,也可能超过 replica 数量 25% 是可用的,最高可以达到 125% 的 replica 数量。
这里其实可以根据用户实际场景来做设置。比如当用户的资源足够,且更注重发布过程中的可用性,可设置 MaxUnavailable 较小、MaxSurge 较大。但如果用户的资源比较紧张,可以设置 MaxSurge 较小,甚至设置为 0,这里要注意的是 MaxSurge 和 MaxUnavailable 不能同时为 0。
@山东·威海 2020.05.19