Kubernetes Pod Disruption Budget实用指南

云云众生s

发布于 2024-03-28 13:36:27

1050

发布于 2024-03-28 13:36:27

文章被收录于专栏：云云众生s云云众生s

管理Kubernetes集群在保持一致的可用性和对故障的韧性方面存在困难。虽然使用副本可以确保存在多个应用程序实例，但并不能保证应用程序运行时的不间断。

译自 Kubernetes Pod Disruption Budget: The Practical Guide 2024，作者 Mohamed BEN HASSINE 。

这就是Pod Disruption Budget（Pod中断预算，PDB）变得至关重要的地方。PDB是Kubernetes内的一个功能，通过对应用程序可以处理的中断数量制定规定，有助于维持应用程序的稳定性。

本文深入探讨了PDB的具体内容，包括其定义、如何创建、最佳使用案例以及其重要性的基本原因。

什么是“Pod Disruption（Pod中断）”？

Pod中断指的是当Pod被有意地从节点中删除或驱逐时发生的情况。这可能出于各种原因，包括：

节点维护（如操作系统升级或硬件升级）。
Kubernetes集群升级。
自动缩放。
由于节点资源约束而重新调度Pod。

在Kubernetes中，有两种类型的中断：

自愿中断：这些是可以控制和计划的中断。预计它们将遵守您定义的Pod Disruption Budget（PDB）。
非自愿中断：这些是无法预测或控制的意外中断，例如节点上的硬件故障或内核崩溃。重要的是要注意，这些类型的中断不会遵守PDB设置的约束。

什么是“Pod Disruption Budget”？

现在我们已经了解了Pod中断是什么，让我们深入探讨一下旨在帮助我们管理它的工具。简单来说，Pod Disruption Budget（PDB）使您能够控制应在任何给定时刻可访问的副本数。在为应用程序配置PDB时，您可以指定以下内容之一：

Pod必须始终可用的最小副本数（称为最小可用）。
可用的副本数的最大数量（称为最大不可用）。

在实际操作中，这意味着，例如，如果您的应用程序有5个副本，并且您设置了一个PDB，要求最少可用的副本数为2个，则只要有两个副本正常运行，PDB就不会影响您的应用程序。

但是，如果副本数少于2个，某些Kubernetes操作将被暂停。例如，如果由于缩容过程导致副本少于2个，那么您的集群的缩容将被暂停。

使用“Pod Disruption Budget”的要求？

为了使用Pod Disruption Budget（PDB），要求很简单：

Kubernetes版本：确保您的Kubernetes版本为1.21或更高。
Pod标记：要创建和应用PDB，您需要指定应该生效的Pods。因此，相应地标记您的Pods，以便简单地识别应该应用PDB的Pods。此标记有助于精确应用Pod Disruption Budget。

如何创建Pod Disruption Budget？

我们将讨论创建Pod Disruption Budget（PDB）对象的各种方法。

Kubectl Create

要快速将Pod Disruption Budget（PDB）应用于特定工作负载，请执行以下kubectl命令：

kubectl create poddisruptionbudget my-app-pdb --min-available=1 \
--selector=app=my-super-app

让我们分解一下：

poddisruptionbudget：这是我们要创建的Kubernetes API资源类型，代表“Pod Disruption Budget”资源。或者，您可以使用简称“pdb”。
my-app-pdb：这是专门为应用程序“super-critical-app”创建的PDB资源的名称。
--min-available=1：此标志确保我们的应用程序始终可用的最小副本数为1个，设置中断的阈值。
--selector=app=my-super-app：此标志用于指定应该应用PDB的Pods。在本例中，它指定了PDB适用于具有标签“app=super-critical-app”的Pods。

YAML定义

另一种创建Pod Disruption Budget（PDB）对象的方法是使用YAML文件定义其配置。

让我们看一个在前一节中讨论的相同PDB的示例，特别是利用minAvailable参数。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: my-super-app

执行kubectl apply -f <YAML_FILE>将生成相同的Pod Disruption Budget（PDB）。现在，让我们探讨使用maxUnavailable参数的示例。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  maxUnavailable: 0
  selector:
    matchLabels:
      app: my-super-app

Helm Chart

以下是如何在Helm Chart中定义PDB的示例：

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
 name: "{{ .Release.Name }}-pdb"
spec:
 minAvailable: 2
 selector:
 matchLabels:
 app: "{{ .Release.Name }}"

在此示例中，Pod Disruption Budget（PDB）被配置为在自愿中断期间保持两个标记为app: {{ .Release.Name }}的Pods的最小数量。

当执行可能使应用程序不可用的操作时，Kubernetes努力遵守PDB准则。例如，它将尝试以避免违反PDB的方式将Pods分配给节点。

重要的是要认识到，PDB不能确保可用Pod的数量或百分比保持恒定。在发生意外中断或集群资源不足以在节点故障后调度新的Pod时，可用Pod的计数可能会低于指定的阈值。

将PDB集成到您的Helm Chart中时，确认选择器字段中的标签与您打算保护的Pods的标签对齐至关重要。

验证PDB已创建并应用

让我们首先列出我们的Pod Disruption Budget（PDB）对象。我们期望看到一个，特别是在前面的部分中创建的那一个，名称为“app-pdb”。

$ kubectl get pdb

NAME        MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
my-app-pdb         1              0                      0

目前的配置规定最少1个副本。鉴于我们使用默认设置1个副本，因此最大可允许的不可用性限制为1（任何更多，应用程序将停止运行）。

如何测试Kubernetes PDB？

要真正掌握Pod Disruption Budgets（PDB）的有效性，最具见解的方法是在各种场景下积极测试它，其中其作用是保护应用程序不会少于指定数量的副本。

Kubernetes节点排空

我们将首先执行节点排空，不仅仅是任何节点，而是特别是我们的应用程序副本当前正在运行的节点。节点排空涉及在将节点标记为“cordoned”后重新定位所有Pod，表示该节点上不能再调度新的Pod。

假设我们执行了命令

kubectl get po -o wide | grep -i my-super-app

我们确定节点名称为“teckbootcamps-node”，让我们继续排空该节点。

$ kubectl drain teckbootcamps-node --ignore-daemonsets

node/teckbootcamps-node cordoned

这是一个积极的开始。最初，我们观察到我们的节点已被封闭，表示不会将新的工作负载分配给它。让我们继续检查后续输出以获取更多见解。

evicting pod default/last-app
evicting pod default/my-super-app
evicting pod default/funny-app

有趣。值得注意的是，节点上的所有Pod都被安排进行驱逐。但是，重要的是不要误以为这表明了PDB无法正常工作。

这只是对其预期操作的通知。让我们继续查看接下来发生的事情。

evicting pod default/my-super-app
error when evicting pods/"my-super-app" -n "default" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
evicting pod default/jkog-cc8457d4-pkhzs
error when evicting pods/"my-super-app" -n "default" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

PDB来拯救！ Kubernetes在驱逐目标Pod（我们最近创建的PDB中指定的Pod）时遇到了障碍。

它评估配置的PDB并推断出，疏散此Pod将导致可用的Pod数量从1减少到0，低于minAvailable=1定义的阈值。

Kubernetes节点池升级

让我们在不同的工作流程中测试PDB-具体来说，在Google云平台（GCP）上的GKE集群中升级节点池，并且节点池只有一个节点和最小可用设置为1。通常，在这样的过程中，将节点标记为封闭以防止在其上调度新的工作负载。

随后，应用排空操作以将工作负载转移到具有更新的Kubernetes版本的新节点。在理论上，PDB应该介入，因为此场景意味着将Pod从一个节点驱逐到另一个节点时副本数减少为0。让我们在这种情况下检查其性能。

使用gcloud CLI

gcloud container clusters upgrade CLUSTER_NAME --node-pool=NODE_POOL_NAME --cluster-version VERSION

结果如何？没有升级！好吧，不完全是。最初，您的工作负载不会转移到新节点，实际上仍然作为旧节点上的唯一占用者（假设其他工作负载没有PDB）。但是，请注意您从GCP收到的这条有趣的消息。

Pod Disruption Budget（PDB）是确保应用程序持续运行的最佳解决方案吗？

简而言之，不是。Pod Disruption Budget（PDB）并非是确保应用程序不间断运行的一劳永逸的解决方案。从技术上讲，它并不是绝对可靠的，有时需要额外的方法来保证应用程序的连续和正确运行。让我们探讨一些例子。

考虑一个简单的情景：您有一个名为“my-cool-app”的Pod，有一个副本，并且应用了PDB，其中minAvailable=1，表示应始终有一个运行中的副本，不允许对Pod进行中断。

现在，如果您运行kubectl delete po my-cool-app，您认为会发生什么？如果您的答案是“它会被删除”，那么您是正确的。PDB不会阻止Pod被删除，因为这种直接删除被视为管理员发起的管理操作，而不是由Kubernetes服务自己管理。因此，在管理员直接删除Pod时，PDB不会产生影响。