4

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

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

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

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

4

3 回答 3

1

我会说，根据文档：

自愿和非自愿中断

Pod 不会消失，直到有人（人或控制器）破坏它们，或者出现不可避免的硬件或系统软件错误。

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

  • 支持节点的物理机器的硬件故障
  • 集群管理员误删除VM（实例）
  • 云提供商或管理程序故障使 VM 消失
  • 内核恐慌
  • 由于集群网络分区，节点从集群中消失
  • 由于节点 资源不足而驱逐 pod 。

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

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

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

集群管理员操作包括：

  • 排空节点 以进行修复或升级。
  • 从集群中耗尽节点以缩减集群（了解 集群自动缩放 ）。
  • 从节点中删除 pod 以允许其他内容适合该节点。

-- Kubernetes.io：文档：概念：工作负载：Pods：中断

因此，您的示例完全不同，据我所知，这既不是自愿的也不是非自愿的破坏。

还可以查看另一个 Kubernetes 文档：

吊舱寿命

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

Pod 本身不会自我修复。如果一个 Pod 被调度到一个失败的节点上，那么这个 Pod 就会被删除；同样，由于缺乏资源或节点维护，Pod 将无法生存。Kubernetes 使用更高级别的抽象，称为控制器，它处理管理相对一次性的 Pod 实例的工作。

-- Kubernetes.io：文档：概念：工作负载：Pods：Pod 生命周期：Pod 生命周期

容器探针

kubelet 可以选择对正在运行的容器执行三种探测并对其做出反应（专注于 a livenessProbe）：

  • livenessProbe：指示容器是否正在运行。如果 liveness 探测失败，kubelet 会杀死容器，容器会受到其 重启策略的约束。如果 Container 不提供 liveness 探测，则默认状态为 Success。

-- Kubernetes.io：文档：概念：工作负载：Pods：Pod 生命周期：容器探测

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

如果容器中的进程在遇到问题或变得不健康时能够自行崩溃，则不一定需要活性探测；kubelet 会根据 Pod 的 restartPolicy.

如果您希望您的容器在探测失败时被杀死并重新启动，则指定一个活跃 restartPolicy 度探测，并指定 Always 或 OnFailure。

-- Kubernetes.io：文档：概念：工作负载：Pods：Pod 生命周期：何时应该使用启动探针

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

回答以下问题：

我想知道吊舱中断预算是否会阻止这种情况。

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

我认为让评论更加可见，我在这件事上提供了额外的资源，可能对其他社区成员有用：

于 2021-05-13T11:33:18.607 回答
1

使用 PodDisruptionBudget 进行测试。Pod 仍然会同时重启。

例子

https://github.com/AlphaWong/PodDisruptionBudgetAndPodProbe

所以是的。像@Dawid Kruk 你应该创建一个自定义脚本，如下所示

# 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
于 2021-10-28T04:33:04.097 回答
0

我想知道吊舱中断预算是否会阻止这种情况。

是的，它会阻止。

正如您所说，当pod出现故障（或节点故障）时，没有什么可以让 pod 变得不可用。但是，某些服务要求始终保持最少数量的 pod 始终运行。

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

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

于 2021-04-27T08:33:07.747 回答