kubernetes工作负载 kubernetes工作负载有哪些

概述

1、工作负载是在 Kubernetes 上运行的应用程序

2、在 Kubernetes 中，无论负载是由单个组件还是由多个一同工作的组件构成，都可以在一组 Pod 中运行它，在 Kubernetes 中，Pod 代表的是集群上处于运行状态的一组容器的集合

3、为了减轻用户的使用负担，通常不需要用户直接管理每个 Pod，而是使用负载资源来替用户管理一组 Pod，这些负载资源通过配置控制器来确保正确类型的、处于运行状态的 Pod 个数是正确的，与用户所指定的状态相一致

4、Kubernetes 提供若干种内置的工作负载资源

（1）Deployment 和 ReplicaSet （替换原来的资源 ReplicationController）

（2）StatefulSet

（3）DaemonSet

（4）Job 和 CronJob

（5）在庞大的 Kubernetes 生态系统中，还可以找到一些提供额外操作的第三方工作负载相关的资源。 通过使用定制资源定义（CRD）， 你可以添加第三方工作负载资源，以完成原本不是 Kubernetes 核心功能的工作

 

Deployments

1、一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力

2、你负责描述 Deployment 中的目标状态，而 Deployment 控制器（Controller）以受控速率更改实际状态，使其变为期望状态，可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment，并通过新的 Deployment 收养其资源

3、说明：不要管理 Deployment 所拥有的 ReplicaSet

4、典型用例

（1）创建 Deployment 以将 ReplicaSet 上线。ReplicaSet 在后台创建 Pod。检查 ReplicaSet 的上线状态，查看其是否成功

（2）通过更新 Deployment 的 PodTemplateSpec，声明 Pod 的新状态。新的 ReplicaSet 会被创建，Deployment 以受控速率将 Pod 从旧 ReplicaSet 迁移到新 ReplicaSet。每个新的 ReplicaSet 都会更新 Deployment 的修订版本

（3）如果 Deployment 的当前状态不稳定，回滚到较早的 Deployment 版本。每次回滚都会更新 Deployment 的修订版本

（4）扩大 Deployment 规模，以承担更多负载

（5）暂停 Deployment 的上线，以应用对 PodTemplateSpec 所作的多项修改，然后恢复其执行以启动新的上线版本

（6）使用 Deployment 状态来判定上线过程是否出现停滞

（7）清理较旧的不再需要的 ReplicaSet

 

ReplicaSet

1、ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合，因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性

2、ReplicaSet 的工作原理 

（1）ReplicaSet 是通过一组字段来定义的，包括一个用来识别可获得的 Pod 的集合的选择算符、一个用来标明应该维护的副本个数的数值、一个用来指定应该创建新 Pod 以满足副本个数条件时要使用的 Pod 模板等等

（2）每个 ReplicaSet 都通过根据需要创建和删除 Pod 以使得副本个数达到期望值，进而实现其存在价值

（3）当 ReplicaSet 需要创建新的 Pod 时，会使用所提供的 Pod 模板

（4）ReplicaSet 通过 Pod 上的 metadata.ownerReferences 字段连接到附属 Pod，该字段给出当前对象的属主资源。ReplicaSet 所获得的 Pod 都在其 ownerReferences 字段中包含了属主 ReplicaSet 的标识信息。正是通过这一连接，ReplicaSet 知道它所维护的 Pod 集合的状态，并据此计划其操作行为

（5）ReplicaSet 使用其选择算符来辨识要获得的 Pod 集合。如果某个 Pod 没有 OwnerReference 或者其 OwnerReference 不是一个控制器， 且其匹配到某 ReplicaSet 的选择算符，则该 Pod 立即被此 ReplicaSet 获得

3、何时使用 ReplicaSet

（1）ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。然而，Deployment 是一个更高级的概念，它管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能

（2）因此，建议使用 Deployment 而不是直接使用 ReplicaSet， 除非需要自定义更新业务流程或根本不需要更新

（3）这实际上意味着，你可能永远不需要操作 ReplicaSet 对象：而是使用 Deployment，并在 spec 部分定义你的应用

 

StatefulSet

1、StatefulSet 是用来管理有状态应用的工作负载 API 对象

2、StatefulSet 用来管理某 Pod 集合的部署和扩缩，并为这些 Pod 提供持久存储和持久标识符

（1）和 Deployment 类似，StatefulSet 管理基于相同容器规约的一组 Pod

（2）但和 Deployment 不同的是，StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID

（3）这些 Pod 是基于相同的规约来创建的， 但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID

3、如果希望使用存储卷为工作负载提供持久存储，可以使用 StatefulSet 作为解决方案的一部分。尽管 StatefulSet 中的单个 Pod 仍可能出现故障，但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易

4、StatefulSet 需要满足以下一个或多个需求的应用程序

（1）稳定的、唯一的网络标识符

（2）稳定的、持久的存储

（3）有序的、优雅的部署和扩缩

（4）有序的、自动的滚动更新

（5）在上面描述中，“稳定的”意味着 Pod 调度或重调度的整个过程是有持久性的。如果应用程序不需要任何稳定的标识符或有序的部署、删除或扩缩，则应该使用由一组无状态的副本控制器提供的工作负载来部署应用程序，比如 Deployment 或者 ReplicaSet 可能更适用于无状态应用部署需要

5、限制

（1）给定 Pod 的存储必须由 PersistentVolume Provisioner 基于所请求的 storage class 来制备，或者由管理员预先制备

（2）删除或者扩缩 StatefulSet 并不会删除它关联的存储卷。这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值

（3）StatefulSet 当前需要无头服务来负责 Pod 的网络标识。你需要负责创建此服务

（4）当删除一个 StatefulSet 时，该 StatefulSet 不提供任何终止 Pod 的保证。为了实现 StatefulSet 中的 Pod 可以有序且体面地终止，可以在删除之前将 StatefulSet 缩容到 0

（5）在默认 Pod 管理策略（OrderedReady）时使用滚动更新，可能进入需要人工干预才能修复的损坏状态

 

DaemonSet

1、DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本

（1）当有节点加入集群时，也会为他们新增一个 Pod

（2）当有节点从集群移除时，这些 Pod 也会被回收

（3）删除 DaemonSet 将会删除它创建的所有 Pod

2、典型用法

（1）在每个节点上运行集群守护进程

（2）在每个节点上运行日志收集守护进程

（3）在每个节点上运行监控守护进程

3、一种简单的用法是为每种类型的守护进程在所有的节点上都启动一个 DaemonSet

4、一个稍微复杂的用法是为同一种守护进程部署多个 DaemonSet；每个具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求

 

Job

1、Job 会创建一个或者多个 Pod，并将继续重试 Pod 的执行，直到指定数量的 Pod 成功终止

（1）随着 Pod 成功结束，Job 跟踪记录成功完成的 Pod 个数

（2）当数量达到指定的成功个数阈值时，任务（即 Job）结束

2、删除 Job 的操作会清除所创建的全部 Pod

3、挂起 Job 的操作会删除 Job 的所有活跃 Pod，直到 Job 被再次恢复执行

4、一种简单的使用场景下，你会创建一个 Job 对象以便以一种可靠的方式运行某 Pod 直到完成

5、当第一个 Pod 失败或者被删除（比如因为节点硬件失效或者重启）时，Job 对象会启动一个新的 Pod

 

CronJob

1、CronJob 创建基于时隔重复调度的 Job

（1）CronJob 用于执行排期操作，例如备份、生成报告等

（2）一个 CronJob 对象就像 Unix 系统上的 crontab（cron table）文件中的一行，它用 Cron 格式进行编写，并周期性地在给定的调度时间执行 Job

2、CronJob 有所限制，也比较特殊，例如：在某些情况下，单个 CronJob 可以创建多个并发任务

3、当控制平面为 CronJob 创建新的 Job 和（间接）Pod 时，CronJob 的 .metadata.name 是命名这些 Pod 的部分基础

（1）CronJob 的名称必须是一个合法的 DNS 子域值， 但这会对 Pod 的主机名产生意外的结果

（2）为获得最佳兼容性，名称应遵循更严格的 DNS 标签规则

（3）即使名称是一个 DNS 子域，它也不能超过 52 个字符，这是因为 CronJob 控制器将自动在你所提供的 Job 名称后附加 11 个字符，并且存在 Job 名称的最大长度不能超过 63 个字符的限制

 

HorizontalPodAutoscaler

1、在 Kubernetes 中，HorizontalPodAutoscaler 自动更新工作负载资源 （例如 Deployment 或者 StatefulSet），目的是自动扩缩工作负载以满足需求

（1）水平扩缩意味着对增加的负载的响应是部署更多的 Pod，这与“垂直（Vertical）”扩缩不同，对于 Kubernetes， 垂直扩缩意味着将更多资源（例如：内存或 CPU）分配给已经为工作负载运行的 Pod

（2）如果负载减少，并且 Pod 的数量高于配置的最小值，HorizontalPodAutoscaler 会指示工作负载资源（Deployment、StatefulSet 或其他类似资源）缩减

（3）水平 Pod 自动扩缩不适用于无法扩缩的对象（例如：DaemonSet）

2、HorizontalPodAutoscaler 被实现为 Kubernetes API 资源和控制器

（1）资源决定了控制器的行为

（2）在 Kubernetes 控制平面内运行的水平 Pod 自动扩缩控制器，会定期调整其目标（例如：Deployment）的所需规模，以匹配观察到的指标，例如：平均 CPU 利用率、平均内存利用率或指定的任何其他自定义指标

 

ReplicationController

1、现在推荐使用配置 ReplicaSet 的 Deployment 来建立副本管理机制

2、ReplicationController 确保在任何时候都有特定数量的 Pod 副本处于运行状态，即 ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的