我有一个部署到Kubernetes的应用程序，它依赖于外部应用程序。有时这两个之间的连接会进入无效状态，这只能通过重新启动我的应用程序来修复。
为了进行自动重启，我配置了一个活跃度探针来验证连接。
这一直运行得很好，然而，我担心如果外部应用程序出现故障(这样连接错误不仅仅是由于pod状态无效)，我的所有pod都会立即重新启动，我的应用程序将完全不可用。我希望它保持运行，这样就可以继续运行不依赖坏服务的功能。
我想知道吊舱中断预算是否会阻止这种情况，因为它限制了吊舱的数量，因为"；"自愿"；中断。然而，K8s的文件并没有说明活性探针的失败是否是一种自愿的干扰。是吗？
我会说，根据文档：
自愿和非自愿中断
直到有人(人或控制器)破坏了吊舱，或者出现了不可避免的硬件或系统软件错误，吊舱才会消失。
我们将这些不可避免的情况称为应用程序的非自愿中断。例如：
- 支持节点的物理机器的硬件故障
- 集群管理员错误删除VM(实例)
- 云提供程序或虚拟机管理程序故障导致虚拟机消失
- 内核死机
- 由于群集网络分区，节点从群集中消失
- 由于节点资源不足而驱逐pod
除了资源不足的情况外，大多数用户都应该熟悉所有这些情况；它们不是Kubernetes特有的。
我们将其他情况称为自愿中断。这些操作包括由应用程序所有者发起的操作和由群集管理员发起的操作。典型的应用程序所有者操作包括：
- 删除部署或管理pod的其他控制器
- 更新部署的pod模板导致重新启动
- 直接删除pod(例如意外)
群集管理员操作包括：
- 排空节点以进行修复或升级
- 从集群中排出节点以缩小集群(了解集群自动缩放)
- 从一个节点中移除一个pod，以允许其他东西安装在该节点上
--Kubernetes.io:Docs:Concepts:Workloads:Pods:Disruptions
所以你的例子完全不同，据我所知，这既不是自愿的，也不是非自愿的干扰
同时查看另一个Kubernetes文档：
吊舱寿命
与单独的应用程序容器一样，Pod被认为是相对短暂的(而不是持久的)实体。Pod会被创建、分配一个唯一的ID(UID)，并被安排到节点，直到终止(根据重新启动策略)或删除。如果某个节点死亡，则计划在超时后删除该节点的Pod。
播客本身并不能自我治愈。如果一个Pod被调度到一个节点，然后该节点发生故障，则该Pod被删除；同样，由于缺乏资源或节点维护，Pod将无法在驱逐中幸存下来。Kubernetes使用了一个更高级的抽象，称为控制器，用于处理管理相对一次性的Pod实例的工作。
--Kubernetes.io:Docs:Concepts:Workloads:Pod:Pod生命周期：Pod生命期
容器探测
kubelet可以选择性地在运行的容器上执行三种探针并对其做出反应(专注于
livenessProbe)：
livenessProbe：指示容器是否正在运行。如果liveness探测失败，kubelet将杀死容器，容器将受到其重新启动策略的约束。如果Container不提供liveness探测，则默认状态为Success--Kubernetes.io:Docs:Concepts:Workloads:Pod:Pod生命周期：容器探测
你应该在什么时候使用活力探针
如果容器中的进程在遇到问题或变得不健康时能够自行崩溃，那么您不一定需要活跃度探测器；kubelet将根据Pod的CCD_ 4自动执行正确的动作。
如果您希望在探测失败时终止并重新启动容器，请指定一个活跃度探测，并指定Always或OnFailure的
restartPolicy。--Kubernetes.io:Docs:Concepts:Workloads:Pod:Pod生命周期：何时应该使用启动探针
根据这些信息，最好创建自定义活动性探针，该探针应考虑内部流程健康检查和外部依赖性(活动性)健康检查。在第一种情况下，容器应该停止/终止进程，这与具有外部依赖关系的第二种情况不同。
回答以下问题：
我想知道吊舱中断预算是否能防止这种情况。
在这种特殊情况下，PDB不会有帮助
我认为，我用额外的资源对此事发表的评论可能会对其他社区成员有用：
- Blog.risingstack.com：为失败设计微服务架构
- Loft.sh：博客：Kubernetes就绪问题示例常见陷阱：外部依赖
- Cloud.google.com：架构：可扩展和有弹性的应用程序：抵御故障的弹性设计
使用PodDisruptionBudget进行测试。Pod仍将在同一时间重新启动。
示例
https://github.com/AlphaWong/PodDisruptionBudgetAndPodProbe
是的。像@Dawid Kruk u应该创建一个自定义脚本，就像下面的一样
# something like this
livenessProbe:
exec:
command:
- /bin/sh
- -c
# generate a random number for sleep
- 'SLEEP_TIME=$(shuf -i 2-40 -n 1);sleep $SLEEP_TIME; curl -L --max-time 5 -f nginx2.default.svc.cluster.local'
initialDelaySeconds: 10
# think about the gap between each call
periodSeconds: 30
# it is required after k8s v1.12
timeoutSeconds: 90
我想知道pod中断预算是否能防止这种情况。
是，它将阻止。
正如您所说，当pod发生故障(或节点故障)时，没有什么能阻止pod变得不可用。然而，某些服务要求最少数量的pod始终保持运行。
可能还有另一种方法(Stateful resource)，但它是可用的最简单的Kubernetes资源之一。
注意：您也可以在minAvailable字段中使用百分比而不是绝对数。例如，您可以声明所有带有app=run-always标签的pod的60%需要始终运行。