本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

通过断开网络连接 Kubernetes Pod 进行故障转移

首先，我们将回顾在节点和 Kubernetes 控制平面之间断开网络连接期间影响 Kubernetes 行为的关键概念、组件和设置。EKS 符合上游 Kubernetes 标准，因此此处描述的所有 Kubernetes 概念、组件和设置都适用于 EKS 和 EKS 混合节点部署。

有关网络断开期间上游 Kubernetes 容器故障转移行为的更多背景信息，请参阅上游 Kubernetes 存储库中的 GitHub 问题 #131294 和 #131481。请注意，这些问题在未将更改合并到上游 Kubernetes 的情况下已关闭。

概念

污点和容忍：在 Kubernetes 中，污点和容忍度用于控制 Pod 在节点上的调度。污点由节点生命周期控制器设置，以表明节点不符合调度条件或应驱逐这些节点上的 Pod。当由于网络断开而无法访问节点时，节点生命周期控制器会应用 node.kubernetes。io/unreachable 使用 NoSchedule 效果进行污点，如果满足某些条件则 NoExecute 产生效果。node.kubernetes。io/unreachable 污点对应于 “ NodeCondition 准备就绪未知”。用户可以在中指定应用程序级别对污点的容忍度。 PodSpec

节点租赁：Kubernetes 使用 Lease API 向 Kubernetes API 服务器传输 kubelet 节点心跳信号。对于每个节点，都有一个名称匹配的 Lease 对象。在内部，每个 kubelet 心跳都会更新 Lease 对象的 spec.RenewTime 字段。Kubernetes 控制平面使用该字段的时间戳来确定节点可用性。如果节点与 Kubernetes 控制平面断开连接，则它们无法更新租用的 sep.RenewTime，控制平面会将其解释为 “就绪未知”。 NodeCondition

组件

配置设置

通过断开网络连接 Kubernetes Pod 进行故障转移

此处描述的行为假设 pod 以默认设置作为 Kubernetes 部署运行，并且 EKS 被用作 Kubernetes 提供商。实际行为可能会因您的环境、网络断开的类型、应用程序、依赖关系和集群配置而有所不同。本指南中的内容已使用特定的应用程序、集群配置和插件子集进行了验证。强烈建议在迁移到生产环境之前，在自己的环境和自己的应用程序中测试行为。

当节点和 Kubernetes 控制平面之间出现网络断开连接时，每个断开连接的节点上的 kubelet 无法与 Kubernetes 控制平面通信。因此，在恢复连接之前，kubelet 无法驱逐这些节点上的 pod。这意味着在网络断开之前在这些节点上运行的 Pod 将在断开连接期间继续运行，前提是没有其他故障导致它们关闭。总而言之，在节点与 Kubernetes 控制平面之间的网络断开期间，您可以实现静态稳定性，但是在恢复连接之前，您无法对节点或工作负载执行变更操作。

根据网络断开的性质，有五种主要场景会产生不同的 pod 故障转移行为。在所有场景中，一旦节点重新连接到 Kubernetes 控制平面，集群无需操作员干预即可恢复正常。以下场景根据我们的观察概述了预期结果，但这些结果可能不适用于所有可能的应用程序和集群配置。

场景 1：完整集群中断

预期结果：无法访问的节点上的 Pod 不会被驱逐并继续在这些节点上运行。

集群完全中断意味着集群中的所有节点都与 Kubernetes 控制平面断开连接。在这种情况下，控制平面上的节点生命周期控制器检测到集群中的所有节点都无法访问，并取消任何 Pod 驱逐。

在断开连接Not Ready期间，集群管理员将看到所有节点的状态。Pod 状态不会改变，在断开连接和后续重新连接期间，不会在任何节点上调度新的 Pod。

场景 2：整个区域中断

预期结果：行为取决于受影响的区域是否是群集的唯一区域。

整个区域中断意味着该区域中的所有节点都与 Kubernetes 控制平面断开连接。

Single-zone 群集（或节点缺少topology.kubernetes.io/zone标签的群集）：当受影响的区域是群集的唯一区域时，整个区域的中断等同于整个群集中断（场景 1）。节点生命周期控制器进入 “主干扰模式”，因为每个区域都有零个 Ready 节点，并且取消了所有 pod 驱逐。Pod 继续在无法访问的节点上运行。

Multi-zone 集群：当集群在多个区域中有节点并且一个区域完全关闭时，其余区域仍有就绪节点。在这种情况下，驱逐会正常进行——失效区域中无法访问的节点上的 pod 会在default-unreachable-toleration-seconds（5 分钟）和node-monitor-grace-period（40 秒）过后被驱逐，新的 pod 会被调度到其余区域中运行正常的节点上。有关此行为的更多详细信息，请参阅了解分区中断期间的 pod 驱逐情况。

场景 3：多数区域中断

预期结果：无法访问的节点上的 Pod 不会被驱逐并继续在这些节点上运行。

多数区域中断意味着给定区域中的大多数节点都与 Kubernetes 控制平面断开了连接。Kubernetes 中的区域由具有相同标签的节点定义。topology.kubernetes.io/zone如果集群中未定义任何区域，则大多数中断意味着整个集群中的大多数节点都已断开连接。默认情况下，大多数由节点生命周期控制器定义，在 Kubernetes 和 EK unhealthy-zone-threshold S 中均设置为 55%。由于在 EKS 中设置large-cluster-size-threshold为 100,000，因此如果一个区域中有 55% 或更多的节点无法访问，则 Pod 驱逐将被取消（假设大多数集群远小于 100,000 个节点）。

在断开连接Not Ready期间，集群管理员会看到区域中的大多数节点处于状态，但是 pod 的状态不会改变，也不会在其他节点上重新调度。

请注意，上述行为仅适用于大于三个节点的集群。在三个或更少节点的集群中，计划驱逐无法访问的节点上的 Pod，而新的 pod 则调度在运行正常的节点上。

在测试期间，我们偶尔会观察到，在网络断开期间，Pod 被逐出正好一个无法访问的节点，即使该区域的大多数节点都无法访问。这是一种已知的行为（参见 #131481）：如果节点在达到unhealthy-zone-threshold（55%）unreachable:NoExecute之前受到污染，则一旦超过阈值且驱逐率降低生效，该污点就不会被移除。那个已经被污染的节点上的 Pod 仍然会被逐出去。tolerationSeconds

场景 4：少数族裔区域中断

预期结果：Pod 被逐出无法访问的节点，新的 Pod 被调度到符合条件的可用节点上。

少量中断意味着区域中与 Kubernetes 控制平面断开连接的节点比例较小。如果集群中未定义任何区域，则少数中断意味着整个集群中的少数节点断开连接。如前所述，少数派由节点生命周期控制器的unhealthy-zone-threshold设置定义，默认值为 55%。在这种情况下，如果网络断开的持续时间超过default-unreachable-toleration-seconds（5 分钟）和node-monitor-grace-period（40 秒），并且一个区域中只有不到 55% 的节点无法访问，则新 Pod 会调度在运行正常的节点上，而无法访问的节点上的 pod 会被标记为驱逐。

集群管理员将看到在运行状况良好的节点上创建的新 pod，断开连接的节点上的 pod 将显示为Terminating。请记住，尽管已断开连接的节点上的 Pod 具有Terminating状态，但在节点重新连接到 Kubernetes 控制平面之前，它们不会被完全驱逐。

场景 5：网络中断期间重启节点

预期结果：在节点重新连接到 Kubernetes 控制平面之前，无法访问的节点上的 Pod 才会启动。Pod 故障转移遵循场景 1—3 中描述的逻辑，具体取决于无法访问的节点的数量。

网络中断期间的节点重启意味着节点在断开网络的同时发生了另一个故障（例如电源重启、内存不足事件或其他问题）。如果 kubelet 也已重启，则网络断开连接开始时在该节点上运行的 pod 不会在断开连接期间自动重启。kubelet 在启动时会查询 Kubernetes API 服务器，以了解它应该运行哪些 pod。如果 kubelet 由于网络断开而无法访问 API 服务器，则它无法检索启动 pod 所需的信息。

在这种情况下，不能使用 crictl CLI 等本地故障排除工具手动启动 pod，以此作为 “破碎玻璃” 措施。Kubernetes 通常会移除失效的 pod 并创建新的 pod，而不是重启现有 pod（有关详细信息，请参阅容器 GitHub 存储库中的 #10213）。静态容器是唯一由 kubelet 控制的 Kubernetes 工作负载对象，可以在这些场景中重启。但是，通常不建议使用静态 pod 进行应用程序部署。取而代之的是，在不同的主机上部署多个副本，以确保在同时出现多个故障（例如节点故障以及节点与 Kubernetes 控制平面之间的网络断开）时应用程序的可用性。