roi*_*oim 5 kubernetes livenessprobe
我有一个部署到 Kubernetes 的应用程序，该应用程序依赖于外部应用程序。有时，这两者之间的连接会进入无效状态，只能通过重新启动我的应用程序来修复。
为了自动重新启动，我配置了一个活动探针来验证连接。
这一直工作得很好，但是，我担心如果外部应用程序出现故障（这样连接错误不仅仅是由于无效的 Pod 状态），我的所有 Pod 将立即重新启动，并且我的应用程序将变成完全不可用。我希望它保持运行，以便不依赖于不良服务的功能可以继续。
我想知道 Pod 中断预算是否会阻止这种情况，因为它限制了由于“自愿”中断而减少的 Pod 数量。然而，K8s 文档没有说明活性探测失败是否是自愿中断。他们是吗？
根据文档，我想说：
自愿和非自愿中断
Pod 不会消失，直到有人（人或控制器）销毁它们，或者出现不可避免的硬件或系统软件错误。
我们将这些不可避免的情况称为 应用程序的非自愿中断。例子有：
- 支持节点的物理机的硬件故障
- 集群管理员误删除VM（实例）
- 云提供商或虚拟机管理程序故障导致虚拟机消失
- 内核恐慌
- 由于集群网络分区，节点从集群中消失
- 由于节点资源不足而驱逐 pod 。
除了资源不足的情况外，所有这些情况对于大多数用户来说都应该是熟悉的；它们并不是 Kubernetes 特有的。
我们将其他情况称为自愿中断。其中包括由应用程序所有者发起的操作和由群集管理员发起的操作。典型的应用程序所有者操作包括：
- 删除管理 Pod 的部署或其他控制器
- 更新部署的 Pod 模板导致重启
- 直接删除 Pod（例如意外删除）
集群管理员操作包括：
所以你的例子完全不同，据我所知，这既不是自愿的也不是非自愿的破坏。
另请参阅另一个 Kubernetes 文档：
Pod 生命周期
与单个应用程序容器一样，Pod 被认为是相对短暂（而不是持久）的实体。Pod 被创建，分配一个唯一的 ID ( UID )，并调度到它们保留的节点，直到终止（根据重启策略）或删除。如果节点死亡，调度到该节点的 Pod 会在超时时间后被删除。
Pod 本身不会自我修复。如果某个 Pod 被调度到某个节点，然后该节点出现故障，则该 Pod 会被删除；同样，由于缺乏资源或节点维护，Pod 也无法在驱逐中幸存。Kubernetes 使用更高级别的抽象，称为控制器，它处理管理相对一次性的 Pod 实例的工作。
容器探针
kubelet 可以选择对正在运行的容器执行三种探测并做出反应（重点关注 a
livenessProbe）：
livenessProbe：表示容器是否正在运行。如果活性探测失败，kubelet 将杀死容器，并且容器将遵循其 重启策略。如果容器不提供活性探针，则默认状态为Success。-- Kubernetes.io：文档：概念：工作负载：Pod：Pod 生命周期：容器探针
什么时候应该使用活性探针？
如果容器中的进程在遇到问题或变得不健康时能够自行崩溃，那么您不一定需要活性探针；kubelet 将自动根据 Pod 的 执行正确的操作
restartPolicy。如果您希望在探测失败时终止并重新启动容器，请指定活性探测，并指定
restartPolicyAlways 或 OnFailure。
根据这些信息，最好创建自定义活性探针，该探针应考虑内部进程健康检查和外部依赖性（活性）健康检查。在第一种情况下，您的容器应该停止/终止您的进程，这与具有外部依赖关系的第二种情况不同。
回答以下问题：
我想知道 Pod 中断预算是否可以防止这种情况发生。
在这种特殊情况下，PDB 将无济于事。
我认为，我使用额外资源就此事发表的评论具有更多的可见性，这可能对其他社区成员有用：
| 归档时间： |
|
| 查看次数： |
1180 次 |
| 最近记录： |