Kubernetes 文档 / 概念 / 工作负载 / Pod / 干扰（Disruptions）

Kubernetes 文档 / 概念 / 工作负载 / Pod / 干扰（Disruptions）

此文档从 Kubernetes 官网摘录
中文地址
英文地址

本指南针对的是希望构建高可用性应用的应用所有者，他们有必要了解可能发生在 Pod 上的干扰类型。

文档同样适用于想要执行自动化集群操作（例如升级和自动扩展集群）的集群管理员。

自愿干扰和非自愿干扰

Pod 不会消失，除非有人（用户或控制器）将其销毁，或者出现了不可避免的硬件或软件系统错误。

我们把这些不可避免的情况称为应用的非自愿干扰（Involuntary Disruptions）。例如：

• 节点下层物理机的硬件故障
• 集群管理员错误地删除虚拟机（实例）
• 云提供商或虚拟机管理程序中的故障导致的虚拟机消失
• 内核错误
• 节点由于集群网络隔离从集群中消失
• 由于节点资源不足导致 pod 被驱逐。

我们称其他情况为自愿干扰（Voluntary Disruptions）。 包括由应用所有者发起的操作和由集群管理员发起的操作。 典型的应用所有者的操作包括：

• 删除 Deployment 或其他管理 Pod 的控制器
• 更新了 Deployment 的 Pod 模板导致 Pod 重启
• 直接删除 Pod（例如，因为误操作）

集群管理员操作包括：

• 排空（drain）节点进行修复或升级。
• 从集群中排空节点以缩小集群（了解集群自动扩缩）。
• 从节点中移除一个 Pod，以允许其他 Pod 使用该节点。

处理干扰

以下是减轻非自愿干扰的一些方法：

• 确保 Pod 在请求中给出所需资源。
• 如果需要更高的可用性，请复制应用。 （了解有关运行多副本的无状态 和有状态应用的信息。）
• 为了在运行复制应用时获得更高的可用性，请跨机架（使用 反亲和性） 或跨区域（如果使用多区域集群）扩展应用。

干扰预算

即使你会经常引入自愿性干扰，Kubernetes 提供的功能也能够支持你运行高度可用的应用。

作为一个应用的所有者，你可以为每个应用创建一个 PodDisruptionBudget（PDB）。 PDB 将限制在同一时间因自愿干扰导致的多副本应用中发生宕机的 Pod 数量。 例如，基于票选机制的应用希望确保运行中的副本数永远不会低于票选所需的数量。 Web 前端可能希望确保提供负载的副本数量永远不会低于总数的某个百分比。

集群管理员和托管提供商应该使用遵循 PodDisruptionBudgets 的接口 （通过调用Eviction API）， 而不是直接删除 Pod 或 Deployment。

例如，kubectl drain 命令可以用来标记某个节点即将停止服务。 运行 kubectl drain 命令时，工具会尝试驱逐你所停服的节点上的所有 Pod。 kubectl 代表你所提交的驱逐请求可能会暂时被拒绝， 所以该工具会周期性地重试所有失败的请求， 直到目标节点上的所有的 Pod 都被终止，或者达到配置的超时时间。

集群管理员和托管提供商应该使用遵循 PodDisruptionBudgets 的接口 （通过调用Eviction API）， 而不是直接删除 Pod 或 Deployment。

PDB 指定应用可以容忍的副本数量（相当于应该有多少副本）。 例如，具有 .spec.replicas: 5 的 Deployment 在任何时间都应该有 5 个 Pod。 如果 PDB 允许其在某一时刻有 4 个副本，那么驱逐 API 将允许同一时刻仅有一个（而不是两个）Pod 自愿干扰。

PDB 无法防止非自愿干扰； 但它们确实计入预算。

建议在你的 PodDisruptionBudget 中将 不健康 Pod 驱逐策略 设置为 AlwaysAllow 以支持在节点腾空期间驱逐行为不当的应用程序。 默认行为是等待应用程序 Pod 变得 健康，然后才能继续执行腾空。

PodDisruptionBudget 例子

Pod 干扰状况

启用后，会给 Pod 添加一个 DisruptionTarget 状况， 用来表明该 Pod 因为发生干扰而被删除。 状况中的 reason 字段进一步给出 Pod 终止的原因，如下：

• PreemptionByScheduler
  Pod 将被调度器抢占， 目的是接受优先级更高的新 Pod。 要了解更多的相关信息，请参阅 Pod 优先级和抢占。

• DeletionByTaintManager
  由于 Pod 不能容忍 NoExecute 污点，Pod 将被 Taint Manager（kube-controller-manager 中节点生命周期控制器的一部分）删除； 请参阅基于污点的驱逐。

• EvictionByEvictionAPI
  Pod 已被标记为通过 Kubernetes API 驱逐。

• DeletionByPodGC
  绑定到一个不再存在的 Node 上的 Pod 将被 Pod 垃圾收集删除。

• TerminationByKubelet
  Pod 由于节点压力驱逐或节点体面关闭而被 kubelet 终止。

当 PodDisruptionConditions 特性门控被启用时，在清理 Pod 的同时，如果这些 Pod 处于非终止阶段， 则 Pod 垃圾回收器 (PodGC) 也会将这些 Pod 标记为失效 （另见 Pod 垃圾回收）。

使用 Job（或 CronJob）时，你可能希望将这些 Pod 干扰状况作为 Job Pod 失效策略的一部分。

分离集群所有者和应用所有者角色

通常，将集群管理者和应用所有者视为彼此了解有限的独立角色是很有用的。这种责任分离在下面这些场景下是有意义的：

• 当有许多应用团队共用一个 Kubernetes 集群，并且有自然的专业角色
• 当第三方工具或服务用于集群自动化管理

Pod 干扰预算通过在角色之间提供接口来支持这种分离。

如果你的组织中没有这样的责任分离，则可能不需要使用 Pod 干扰预算。

如何在集群上执行干扰性操作

如果你是集群管理员，并且需要对集群中的所有节点执行干扰操作，例如节点或系统软件升级，则可以使用以下选项

• 接受升级期间的停机时间。
• 故障转移到另一个完整的副本集群。
  • 没有停机时间，但是对于重复的节点和人工协调成本可能是昂贵的。
• 编写可容忍干扰的应用和使用 PDB。
  • 不停机。
  • 最小的资源重复。
  • 允许更多的集群管理自动化。
  • 编写可容忍干扰的应用是棘手的，但对于支持容忍自愿干扰所做的工作，和支持自动扩缩和容忍非 自愿干扰所做工作相比，有大量的重叠