Kubernetes 活跃度探测失败是自愿中断还是非自愿中断？

Question

我有一个应用程序部署到 Kubernetes，它依赖于外部应用程序。有时这两者之间的连接会进入无效状态，这只能通过重新启动我的应用程序来修复。

为了自动重启，我配置了一个活动探测器来验证连接。

这一直工作得很好，但是，我担心如果外部应用程序出现故障（这样连接错误不仅仅是由于无效的 pod 状态），我的所有 pod 将立即重新启动，并且我的应用程序将完全不可用。我希望它继续运行，以便不依赖于不良服务的功能可以继续。

我想知道 pod 中断预算是否会阻止这种情况，因为它限制了由于“自愿”中断而减少的 pod 数量。但是，K8s 文档没有说明活性探测失败是否是自愿中断。是吗？

Answer 1

我想说，根据文档：

<块引用>

自愿和非自愿中断

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

我们将这些不可避免的情况非自愿中断称为应用程序。例如：

• 支持节点的物理机出现硬件故障
• 集群管理员误删除了虚拟机（实例）
• 云提供商或管理程序故障导致虚拟机消失
• 内核崩溃
• 由于集群网络分区，节点从集群中消失
• 由于节点为 out-of-resources 而驱逐 Pod。

除了资源不足的情况，所有这些情况大多数用户应该都很熟悉；它们并非特定于 Kubernetes。

我们称其他情况为自愿中断。这些包括由应用程序所有者发起的操作和由集群管理员发起的操作。典型的应用所有者操作包括：

• 删除管理 pod 的部署或其他控制器
• 更新部署的 pod 模板导致重启
• 直接删除一个 pod（例如意外）

集群管理员操作包括：

• Draining a node 用于维修或升级。
• 从集群中耗尽一个节点以缩小集群规模（了解 Cluster Autoscaling）。
• 从节点中移除 pod 以允许其他内容适合该节点。

-- Kubernetes.io: Docs: Concepts: Workloads: Pods: Disruptions

所以你的例子完全不同，据我所知，这既不是自愿的也不是非自愿的中断。

---

同时查看另一个 Kubernetes 文档：

<块引用>

Pod 生命周期

与单个应用程序容器一样，Pod 被认为是相对短暂（而不是持久）的实体。 Pod 被创建，分配一个唯一的 ID (UID)，并调度到节点，它们会一直保留到终止（根据重启策略）或删除。如果 Node 死亡，则调度到该节点的 Pod 将在超时期限后 scheduled for deletion。

Pod 本身不会自我修复。如果一个 Pod 被调度到一个 node 然后失败了，这个 Pod 会被删除；同样，由于缺乏资源或节点维护，Pod 将无法在驱逐中幸存下来。 Kubernetes 使用更高级别的抽象，称为 controller，用于处理管理相对一次性的 Pod 实例的工作。

-- Kubernetes.io: Docs: Concepts: Workloads: Pods: Pod lifecycle: Pod lifetime

<块引用>

容器探测

kubelet 可以选择对正在运行的容器执行三种探测并做出反应（重点是 livenessProbe）：

• livenessProbe：表示容器是否正在运行。如果活性探测失败，kubelet 会杀死容器，容器会受到其 restart policy 的影响。如果容器不提供活性探测，则默认状态为 Success。

-- Kubernetes.io: Docs: Concepts: Workloads: Pods: Pod lifecycle: Container probes

什么时候应该使用活性探针？

如果容器中的进程在遇到问题或变得不健康时能够自行崩溃，则您不一定需要活性探测； kubelet 将根据 Pod 的 restartPolicy 自动执行正确的操作。

如果您希望容器在探测失败时被终止并重新启动，请指定一个活跃度探测，并将 restartPolicy 指定为 Always 或 OnFailure。

-- Kubernetes.io: Docs: Concepts: Workloads: Pods: Pod lifecycle: When should you use a startup probe

根据这些信息，最好创建自定义活性探测器，它应该考虑内部进程健康检查和外部依赖（活性）健康检查。在第一种情况下，您的容器应该停止/终止您的进程，这与具有外部依赖性的第二种情况不同。

回答以下问题：

<块引用>

我想知道 Pod 中断预算是否可以防止这种情况发生。

在这种特殊情况下，PDB 将无济于事。

---

我认为要提高评论的可见度，我在此问题上提供的其他资源可能对其他社区成员有用：

• Blog.risingstack.com: Designing microservices architecture for failure
• Loft.sh: Blog: Kubernetes readiness probles examples common pitfalls: External depenedencies
• Cloud.google.com: Archiecture: Scalable and resilient apps: Resilience designing to withstand failures

Answer 2

<块引用>

我想知道 Pod 中断预算是否可以防止这种情况发生。

是的，它会阻止。

如您所说，当 pod 出现故障（或节点故障）时，Pod 无法使用。但是，某些服务要求始终保持最少数量的 Pod 始终运行。

可能还有另一种方式 (Stateful resource)，但它是可用的最简单的 Kubernetes 资源之一。

注意：您还可以在 minAvailable 字段中使用百分比而不是绝对数字。例如，您可以声明所有带有 60% 标签的 Pod 中的 app=run-always 需要始终运行。