k8s工作负载管理

　　工作负载即k8s上运行的应用程序，通常由多组容器构成的多组pods实现

为了便于自动化管理工作负载，对不同业务类型的工作负载进行抽象：

　　无状态工作负载：管理的pod集合相互等价，可替换

　　　　deplyment　　replicaSet

　　有状态工作负载：唯一ID，保证顺序性和唯一性，不可替代，可用持久存储保存服务的状态

　　　　statefulSet

　　守护进程工作负载：保证每个节点运行一个的守护进程

　　　　daemonSet

　　批处理工作负载：一次性任务

　　　　job　　cronjob

deplyment

　　实例数控制、多种升级策略、回滚、暂停、恢复

　　　　kubectl rollout undo [--to-revision=x]

　　　　kubectl rollout history

　　滚动升级过程是启动新的replicaSet，并减少历史replicaSet的副本数

　　所有的 Pod 都是 ReplicaSet 创建出来的，而 ReplicaSet 对应的某一个具体的 Deployment.template 版本。

　　deplyment默认保存10个历史版本

　　只有更改模板才会触发版本记录，单纯自动伸缩或手动更改实例数不会触发，暂停过程中，模板更新也不会触发

　　Pod 名字格式：Deployment.name + template-hash + random 字符串

　　deployment.Status 中描述的三个其实是它的 conversion 状态，也就是 Processing、Complete 以及 Failed。

　　

　　Deployment 只负责管理不同版本的 ReplicaSet，由 ReplicaSet 来管理具体的 Pod 副本数，每个 ReplicaSet 对应 Deployment template 的一个版本。

　　Deployment 创建 ReplicaSet，而 ReplicaSet 创建 Pod。他们的 OwnerRef 其实都对应了其控制器的资源。

　　Deployment 控制器，其实是关注 Deployment 和 ReplicaSet 中的 event，收到事件后会加入到队列中。

　　Deployment controller 从队列中取出来之后，它的逻辑会判断 Check Paused，即模板是否更改

　　Deployment 控制器做了更复杂的事情，包含了版本管理，而它把每一个版本下的数量维持工作交给 ReplicaSet 来做。

　　重要spec字段

　　MinReadySeconds：Deployment 会根据 Pod ready 来看 Pod 是否可用，但是如果我们设置了 MinReadySeconds 之后，比如设置为 30 秒，那 Deployment 就一定会等到 Pod ready 超过 30 秒之后才认为 Pod 是 available 的。

　　paused：paused 是标识，Deployment 只做数量维持，不做新的发布

　　progressDeadlineSeconds：前面提到当 Deployment 处于扩容或者发布状态时，它的 condition 会处于一个 processing 的状态，processing 可以设置一个超时时间。如果超过超时时间还处于 processing，那么 controller 将认为这个 Pod 会进入 failed 的状态。

　　Deployment 在 RollingUpdate 中主要提供了两个策略，一个是 MaxUnavailable，另一个是 MaxSurge。

　　　　MaxUnavailable：滚动过程中最多有多少个 Pod 不可用；

　　　　MaxSurge：滚动过程中最多存在多少个 Pod 超过预期 replicas 数量。

statefulSet

　　StatefulSet 中的 Pod 都是有序号的，从 0 开始一直到定义的 replica 数量减一。每个 Pod 都有独立的网络标识：一个 hostname、一块独立的 pvc 以及 pv 存储。这样的话，同一个 StatefulSet 下不同的 Pod，有不同的网络标识、有自己独享的存储盘，这就能很好地满足了绝大部分有状态应用的需求。

　　StatefulSet 中，是由 StatefulSet Controller 来管理下属的 Pod，因此 StatefulSet 通过 Pod 的 label 来标识这个 Pod 所属的版本，这里叫 controller-revision-hash

　　通过ControllerRevision资源，StatefulSet 可以很方便地管理不同版本的 template 模板。

　　如果在 StatefulSet 中定义了 volumeClaimTemplates，StatefulSet 会在创建 Pod 之前，先根据这个模板创建 PVC，并把 PVC 加到 Pod volume 中。

　　StatefulSet 按照顺序创建、删除、更新 Pod，每个 Pod 有唯一的序号。

 　　当前版本的 StatefulSet 只会在 ControllerRevision 和 Pod 中添加 OwnerReference，而不会在 PVC 中添加 OwnerReference。之前的课程中提到过，拥有 OwnerReference 的资源，在管理的这个资源进行删除的默认情况下，会关联级联删除下属资源。因此默认情况下删除 StatefulSet 之后，StatefulSet 创建的 ControllerRevision 和 Pod 都会被删除，但是 PVC 因为没有写入 OwnerReference，PVC 并不会被级联删除。

　　StatefulSet.spec 中有个字段叫 podMangementPolicy 字段，这个字段的可选策略为 OrderedReady 和 Parallel，默认情况下为前者。在 OrderedReady 情况下，扩缩容就严格按照 Order 顺序来执行，必须要等前面的 Pod 状态为 Ready 之后，才能扩容下一个 Pod。在缩容的时候，倒序删除，序号从大到小进行删除。

　　在我们修改了 template，比如修改了镜像之后，Controller 是通过倒序的方式逐一升级 Pod。它的逻辑其实很简单，在升级过程中 Controller 会把序号最大并且符合条件的 Pod 删除掉，那么删除之后在下一次 Controller 在做 reconcile 的时候，它会发现缺少这个序号的 Pod，然后再按照新版本把 Pod 创建出来。

　　 StatefulSetUpdateStrategy 有个 type 字段，这个 type 定义了两个类型：一个是 RollingUpdate；一个是OnDelete。OnDelete 是在删除的时候升级，叫做禁止主动升级。RollingUpdate 其实跟 Deployment 中的升级是有点类似的，就是根据滚动升级的方式来升级。 

　　RollingUpdateStatefulSetSetStrategy 中，可以看到有个字段叫 Partition。这个 Partition 表示滚动升级时，保留旧版本 Pod 的数量。

daemonSet

　　可以设置节点亲和性选择节点部署

　　有两种更新策略：一个是 RollingUpdate，另一个是 OnDelete。

　　　　OnDelete：删除某一个节点对应的 pod，它就会重建，不删除的话它就不会重建

　　管理模式

　　DaemonSet 其实和 Job controller 特别相似，它也是通过 controller 去 watch API Server 的状态，然后及时地添加 pod。唯一不同的是，它会监控节点的状态，节点新加入或者消失的时候会在节点上创建对应的 pod，然后同时根据你配置的一些 affinity 或者 label 去选择对应的节点。

job　

　　restartPolicy 重启策略和 backoffLimit 重试次数限制

　　可以设置 Never、OnFailure、Always 这三种重试策略。在希望 Job 需要重新运行的时候，我们可以用 Never；希望在失败的时候再运行，再重试可以用 OnFailure；或者不论什么情况下都重新运行时 Alway；

Cronjob

　　schedule：schedule 这个字段主要是设置时间格式，它的时间格式和 Linux 的 crontime 是一样的

　　startingDeadlineSeconds：即：每次运行 Job 的时候，它最长可以等多长时间，如果超出，CronJob 就会停止这个 Job

　　concurrencyPolicy：就是说是否允许并行运行。

　　JobsHistoryLimit：每一次 CronJob 运行完之后，它都会遗留上一个 Job 的运行历史、查看时间。，需要限制这个数量