嗯，可以到k8s官网看下，需要注意下"]

• 如果 Deployment 的当前状态不稳定，。 每次回滚都会更新 Deployment 的修订版本。
•  以应用对 PodTemplateSpec 所作的多项修改， 然后恢复其执行以启动新的上线版本。
•  来判定上线过程是否出现停滞。

在有些情形下，你可能希望 Job 在经历若干次重试之后直接进入失败状态，因为这很 可能意味着遇到了配置错误。 为了实现这点，可以将 .pletions 来设置完成数时，Job 控制器所创建的每个 Pod 使用完全相同的 。 这意味着任务的所有 Pod 都有相同的命令行，都使用相同的镜像和数据卷，甚至连 环境变量都（几乎）相同。 这些模式是让每个 Pod 执行不同工作的几种不同形式。

下表显示的是每种模式下 .pletions 所需要的设置。 其中，W 表示的是工作条目的个数。

指定你自己的 Pod 选择算符

通常，当你创建一个 Job 对象时，你不会设置 .spec.selector。 系统的默认值填充逻辑会在创建 Job 时添加此字段。 它会选择一个不会与任何其他 Job 重叠的选择算符设置。

不过，有些场合下，你可能需要重载这个自动设置的选择算符。 为了实现这点，你可以手动设置 Job 的 spec.selector 字段。

做这个操作时请务必小心。 如果你所设定的标签选择算符并不唯一针对 Job 对应的 Pod 集合，甚或该算符还能匹配 其他无关的 Pod，这些无关的 Job 的 Pod 可能会被删除。 或者当前 Job 会将另外一些 Pod 当作是完成自身工作的 Pods， 又或者两个 Job 之一或者二者同时都拒绝创建 Pod，无法运行至完成状态。 如果所设置的算符不具有唯一性，其他控制器（如 RC 副本控制器）及其所管理的 Pod 集合可能会变得行为不可预测。 Kubernetes 不会在你设置 .spec.selector 时尝试阻止你犯这类错误。

下面是一个示例场景，在这种场景下你可能会使用刚刚讲述的特性。

假定名为 old 的 Job 已经处于运行状态。 你希望已有的 Pod 继续运行，但你希望 Job 接下来要创建的其他 Pod 使用一个不同的 Pod 模版，甚至希望 Job 的名字也发生变化。 你无法更新现有的 Job，因为这些字段都是不可更新的。

当 Pod 运行所在的节点重启或者失败，Pod 会被终止并且不会被重启。 Job 会重新创建新的 Pod 来替代已终止的 Pod。 因为这个原因，我们建议你使用 Job 而不是独立的裸 Pod， 即使你的应用仅需要一个 Pod。

Job 与是彼此互补的。 副本控制器管理的是那些不希望被终止的 Pod （例如，Web 服务器）， Job 管理的是那些希望被终止的 Pod（例如，批处理作业）。

另一种模式是用唯一的 Job 来创建 Pod，而该 Pod 负责启动其他 Pod，因此扮演了一种 后启动 Pod 的控制器的角色。 这种模式的灵活性更高，但是有时候可能会把事情搞得很复杂，很难入门， 并且与 Kubernetes 的集成度很低。

这种模式的实例之一是用 Job 来启动一个运行脚本的 Pod，脚本负责启动 Spark 主控制器（参见 ）， 运行 Spark 驱动，之后完成清理工作。

这种方法的优点之一是整个过程得到了 Job 对象的完成保障， 同时维持了对创建哪些 Pod、如何向其分派工作的完全控制能力，

Kubernetes 垃圾收集器的作用是删除某些曾经拥有属主（Owner）但现在不再拥有属主的对象。

你也可以通过手动设置 ownerReference 的值，来指定属主和附属之间的关系。

根据设计，kubernetes 不允许跨名字空间指定属主。

名字空间范围的附属可以指定集群范围的或者名字空间范围的属主。

名字空间范围的属主必须和该附属处于相同的名字空间。 如果名字空间范围的属主和附属不在相同的名字空间，那么该属主引用就会被认为是缺失的， 并且当附属的所有属主引用都被确认不再存在之后，该附属就会被删除。

集群范围的附属只能指定集群范围的属主。 在 v1.20+ 版本，如果一个集群范围的附属指定了一个名字空间范围类型的属主， 那么该附属就会被认为是拥有一个不可解析的属主引用，并且它不能够被垃圾回收。

在 v1.20+ 版本，如果垃圾收集器检测到无效的跨名字空间的属主引用， 或者一个集群范围的附属指定了一个名字空间范围类型的属主，

控制垃圾收集器删除附属

当你删除对象时，可以指定该对象的附属是否也自动删除。 自动删除附属的行为也称为 级联删除（Cascading Deletion） 。 Kubernetes

如果删除对象时，不自动删除它的附属，这些附属被称作 孤立对象（Orphaned） 。

• 对象仍然可以通过 REST API 可见。

基于属主对象上的删除权限来控制用户设置 blockOwnerDeletion 的值为 True， 这样未经授权的附属不能够阻止属主对象的删除。

在 后台级联删除 模式下，Kubernetes 会立即删除属主对象，之后垃圾收集器 会在后台删除其附属对象。

下面是一个在后台删除附属对象的示例：

下面是一个在前台中删除附属对象的示例：

下面是一个令附属成为孤立对象的示例：

下面是一个例子，使一个 ReplicaSet 的附属对象成为孤立附属：

有关信息请参考 。

TTL 控制器提供了一种 TTL 机制来限制已完成执行的资源对象的生命周期。 TTL 控制器目前只处理 ， 可能以后会扩展以处理将完成执行的其他资源，例如 Pod 和自定义资源。

TTL 控制器假设资源能在执行完成后的 TTL 秒内被清理，也就是当 TTL 过期后。 当 TTL 控制器清理资源时，它将做级联删除操作，即删除资源对象的同时也删除其依赖对象。 注意，当资源被删除时，由该资源的生命周期保证其终结器（Finalizers）等被执行。

• 在资源清单（manifest）中指定此字段，以便 Job 在完成后的某个时间被自动清除。
• 将此字段设置为现有的、已完成的资源，以采用此新功能。
• 在创建资源时使用  动态设置该字段。集群管理员可以使用它对完成的资源强制执行 TTL 策略。
• 使用  在资源完成后动态设置该字段，并根据资源状态、标签等选择不同的 TTL 值。

请注意，在创建资源或已经执行结束后，仍可以修改其 TTL 周期，例如 Job 的 .spec.ttlSecondsAfterFinished 字段。 但是一旦 Job 变为可被删除状态（当其 TTL 已过期时），即使您通过 API 增加其 TTL 时长得到了成功的响应，系统也不保证 Job 将被保留。

由于 TTL 控制器使用存储在 Kubernetes 资源中的时间戳来确定 TTL 是否已过期， 因此该功能对集群中的时间偏差很敏感，这可能导致 TTL 控制器在错误的时间清理资源对象。

在 Kubernetes 中，需要在所有节点上运行 NTP（参见 ） 以避免时间偏差。时钟并不总是如此正确，但差异应该很小。 设置非零 TTL 时请注意避免这种风险。

如果你的控制平面在 Pod 或是裸容器中运行了 kube-controller-manager， 那么为该容器所设置的时区将会决定 Cron Job 的控制器所使用的时区。

为 CronJob 资源创建清单时，请确保所提供的名称是一个合法的 . 名称不能超过 52 个字符。 这是因为 CronJob 控制器将自动在提供的 Job 名称后附加 11 个字符，并且存在一个限制， 即 Job 名称的最大长度不能超过 63 个字符。

CronJobs 对于创建周期性的、反复重复的任务很有用，例如执行数据备份或者发送邮件。 CronJobs 也可以用来计划在指定时间来执行的独立任务，例如计划当集群看起来很空闲时 执行某个 Job。

下面的 CronJob 示例清单会在每分钟打印出当前时间和问候消息：

 一文会为你详细讲解此例。

# ┌───────────── 分钟 (0 - 59)
# │ ┌───────────── 小时 (0 - 23)
# │ │ ┌───────────── 月的某天 (1 - 31)
# │ │ │ ┌───────────── 月份 (1 - 12)
# │ │ │ │ ┌───────────── 周的某天 (0 - 6) （周日到周一；在某些系统上，7 也是星期日）

每年 1 月 1 日的午夜运行一次
每月第一天的午夜运行一次
每周的周日午夜运行一次

例如，下面这行指出必须在每个星期五的午夜以及每个月 13 号的午夜开始任务：

CronJob 根据其计划编排，在每次该执行任务的时候大约会创建一个 Job。 我们之所以说 "大约"，是因为在某些情况下，可能会创建两个 Job，或者不会创建任何 Job。 我们试图使这些情况尽量少发生，但不能完全杜绝。因此，Job 应该是 幂等的。

对于每个 CronJob，CronJob  检查从上一次调度的时间点到现在所错过了调度次数。如果错过的调度次数超过 100 次， 那么它就不会启动这个任务，并记录这个错误:

控制器恰好在与上一个示例相同的时间段（08:29:00 到 10:21:00）终止运行， 则 Job 仍将从 10:22:00 开始。 造成这种情况的原因是控制器现在检查在最近 200 秒（即 3 个错过的调度）中发生了多少次错过的 Job 调度，而不是从现在为止的最后一个调度时间开始。

CronJob 仅负责创建与其调度时间相匹配的 Job，而 Job 又负责管理其代表的 Pod。

• 有关创建和使用 CronJob 的说明及示例规约文件，请参见 。

一个简单的示例是创建一个 ReplicationController 对象来可靠地无限期地运行 Pod 的一个实例。 更复杂的用例是运行一个多副本服务（如 web 服务器）的若干相同副本。

通过下载示例文件并运行以下命令来运行示例任务:

在这里，创建了三个 Pod，但没有一个 Pod 正在运行，这可能是因为正在拉取镜像。 稍后，相同的命令可能会显示：

除了 Pod 所需的字段外，ReplicationController 中的 Pod 模板必须指定适当的标签和适当的重新启动策略。 对于标签，请确保不与其他控制器重叠。参考 。

它不区分它创建或删除的 Pod 和其他人或进程创建或删除的 Pod。 这允许在不影响正在运行的 Pod 的情况下替换 ReplicationController。

如果你的确创建了多个控制器并且其选择算符之间存在重叠，那么你将不得不自己管理删除操作（参考）。

你可以通过设置 .spec.replicas 来指定应该同时运行多少个 Pod。 在任何时候，处于运行状态的 Pod 个数都可能高于或者低于设定值。例如，副本个数刚刚被增加或减少时，或者一个 Pod 处于优雅终止过程中而其替代副本已经提前开始创建时。

一旦原始对象被删除，你可以创建一个新的 ReplicationController 来替换它。 只要新的和旧的 .spec.selector 相同，那么新的控制器将领养旧的 Pod。 但是，它不会做出任何努力使现有的 Pod 匹配新的、不同的 Pod 模板。 如果希望以受控方式更新 Pod 以使用新的 spec，请执行操作。

通过更改 Pod 的标签，可以从 ReplicationController 的目标中删除 Pod。 此技术可用于从服务中删除 Pod 以进行调试、数据恢复等。以这种方式删除的 Pod 将自动替换（假设复制副本的数量也没有更改）。

如上所述，无论你想要继续运行 1 个 Pod 还是 1000 个 Pod，一个 ReplicationController 都将确保存在指定数量的 Pod，即使在节点故障或 Pod 终止(例如，由于另一个控制代理的操作)的情况下也是如此。

如  PR 中所述，建议的方法是使用 1 个副本创建一个新的 ReplicationController， 逐个扩容新的（+1）和缩容旧的（-1）控制器，然后在旧的控制器达到 0 个副本后将其删除。 这一方法能够实现可控的 Pod 集合更新，即使存在意外失效的状况。

理想情况下，滚动更新控制器将考虑应用程序的就绪情况，并确保在任何给定时间都有足够数量的 Pod 有效地提供服务。

这两个 ReplicationController 将需要创建至少具有一个不同标签的 Pod，比如 Pod 主要容器的镜像标签，因为通常是镜像更新触发滚动更新。

滚动更新是在客户端工具  中实现的。访问 以获得更多的具体示例。

除了在滚动更新过程中运行应用程序的多个版本之外，通常还会使用多个版本跟踪来长时间，甚至持续运行多个版本。这些跟踪将根据标签加以区分。

多个 ReplicationController 可以位于一个服务的后面，例如，一部分流量流向旧版本，一部分流量流向新版本。

一个 ReplicationController 永远不会自行终止，但它不会像服务那样长时间存活。 服务可以由多个 ReplicationController 控制的 Pod 组成，并且在服务的生命周期内 （例如，为了执行 Pod 更新而运行服务），可以创建和销毁许多 ReplicationController。 服务本身和它们的客户端都应该忽略负责维护服务 Pod 的

由 ReplicationController 创建的 Pod 是可替换的，语义上是相同的，尽管随着时间的推移，它们的配置可能会变得异构。 这显然适合于多副本的无状态服务器，但是 ReplicationController 也可以用于维护主选、分片和工作池应用程序的可用性。 这样的应用程序应该使用动态的工作分配机制，例如 ， 而不是静态的或者一次性定制每个 Pod 的配置，这被认为是一种反模式。 执行的任何 Pod 定制，例如资源的垂直自动调整大小（例如，CPU 或内存）， 都应该由另一个在线控制器进程执行，这与

ReplicationController 仅确保所需的 Pod 数量与其标签选择算符匹配，并且是可操作的。 目前，它的计数中只排除终止的 Pod。 未来，可能会考虑系统提供的和其他信息， 我们可能会对替换策略添加更多控制， 我们计划发出事件，这些事件可以被外部客户端用来实现任意复杂的替换和/或缩减策略。

ReplicationController 永远被限制在这个狭隘的职责范围内。 它本身既不执行就绪态探测，也不执行活跃性探测。 它不负责执行自动缩放，而是由外部自动缩放器控制（如  中所述），后者负责更改其 replicas 字段值。 我们不会向 ReplicationController 添加调度策略(例如，)。 它也不应该验证所控制的 Pod 是否与当前指定的模板匹配，因为这会阻碍自动调整大小和其他自动化过程。 类似地，完成期限、整理依赖关系、配置扩展和其他特性也属于其他地方。 我们甚至计划考虑批量创建 Pod 的机制（查阅 ）。

ReplicationController 旨在成为可组合的构建基元。 我们希望在它和其他补充原语的基础上构建更高级别的 API 或者工具，以便于将来的用户使用。 kubectl 目前支持的 "macro" 操作（运行、缩放、滚动更新）就是这方面的概念示例。 例如，我们可以想象类似于  的东西管理 ReplicationController、自动定标器、服务、调度策略、金丝雀发布等。

你需要自定义更新编排或根本不需要更新。

与用户直接创建 Pod 的情况不同，ReplicationController 能够替换因某些原因被删除或被终止的 Pod ，例如在节点故障或中断节点维护的情况下，例如内核升级。 因此，我们建议你使用 ReplicationController，即使你的应用程序只需要一个 Pod。 可以将其看作类似于进程管理器，它只管理跨多个节点的多个 Pod ，而不是单个节点上的单个进程。

的生命期与机器的生命期绑定：它们需要在其他 Pod 启动之前在机器上运行， 并且在机器准备重新启动或者关闭时安全地终止。